qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 4/4] accel/tcg: increase default code gen buffer size for


From: Alex Bennée
Subject: Re: [PATCH v1 4/4] accel/tcg: increase default code gen buffer size for 64 bit
Date: Fri, 28 Feb 2020 19:20:39 +0000
User-agent: mu4e 1.3.8; emacs 27.0.60

Igor Mammedov <address@hidden> writes:

> On Thu, 27 Feb 2020 20:07:24 +0100
> Niek Linnenbank <address@hidden> wrote:
>
>> Hi Richard,
>> 
>> On Thu, Feb 27, 2020 at 1:57 PM Richard Henderson <
>> address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]