Igor Mammedov <[email protected]> writes:
> On Thu, 27 Feb 2020 20:07:24 +0100 > Niek Linnenbank <[email protected]> wrote: > >> Hi Richard, >> >> On Thu, Feb 27, 2020 at 1:57 PM Richard Henderson < >> [email protected]> wrote: >> >> > On 2/27/20 4:31 AM, Alex Bennée wrote: >> > >> It does not make sense for a linux-user chroot, running make -jN, on >> > just about >> > >> any host. For linux-user, I could be happy with a modest increase, but >> > >> >> > not all >> > >> the way out to 2GiB. >> > >> >> > >> Discuss. >> > > >> > > Does it matter that much? Surely for small programs the kernel just >> > > never pages in the used portions of the mmap? >> > >> > That's why I used the example of a build under the chroot, because the >> > compiler >> > is not a small program. >> > >> > Consider when the memory *is* used, and N * 2GB implies lots of paging, >> > where >> > the previous N * 32MB did not. >> > >> > I agree that a lower default value probably is safer until we have more >> proof that a larger value does not give any issues. >> >> >> > I'm saying that we should consider a setting more like 128MB or so, since >> > the >> > value cannot be changed from the command-line, or through the environment. >> > >> >> Proposal: can we then introduce a new command line parameter for this? >> Maybe in a new patch? > > linux-user currently uses 32Mb static buffer so it probably fine to > leave it as is or bump it to 128Mb regardless of the 32/64bit host. > > for system emulation, we already have tb-size option to set user > specified buffer size. > > Issue is with system emulation is that it sizes buffer to 1/4 of > ram_size and dependency on ram_size is what we are trying to get > rid of. If we consider unit/acceptance tests as main target/user, > then they mostly use default ram_size value which varies mostly > from 16Mb to 1Gb depending on the board. So used buffer size is > in 4-256Mb range. > Considering that current CI runs fine with max 256Mb buffer, > it might make sense to use it as new heuristic which would not > regress our test infrastructure and might improve performance > for boards where smaller default buffer was used. I've dropped it from 2gb to 1gb for system emulation. For the acceptance tests I doubt we'll even fill the buffer but the mmap memory should overcommit fine. > > >> Since the size of the code generation buffer appears to have an impact on >> performance, >> in my opinion it would make sense to make it configurable by the user. >> >> Regards, >> >> >> > >> > >> > r~ >> > >> > >> -- Alex Bennée
