Re: Sudden slowdown of ARM emulation in master

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 26 Feb 2020 10:32:38 +0100
Howard Spoelstra <hsp.cat7@gmail.com> wrote:

> On Wed, Feb 26, 2020 at 10:19 AM Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > On Wed, 26 Feb 2020 00:07:55 +0100
> > Niek Linnenbank <nieklinnenbank@gmail.com> wrote:
> >  
> > > Hello Igor and Paolo,  
> >
> > does following hack solves issue?
> >
> > diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> > index a08ab11f65..ab2448c5aa 100644
> > --- a/accel/tcg/translate-all.c
> > +++ b/accel/tcg/translate-all.c
> > @@ -944,7 +944,7 @@ static inline size_t size_code_gen_buffer(size_t
> > tb_size)
> >          /* ??? If we relax the requirement that CONFIG_USER_ONLY use the
> >             static buffer, we could size this on RESERVED_VA, on the text
> >             segment size of the executable, or continue to use the
> > default.  */
> > -        tb_size = (unsigned long)(ram_size / 4);
> > +        tb_size = MAX_CODE_GEN_BUFFER_SIZE;
> >  #endif
> >      }
> >      if (tb_size < MIN_CODE_GEN_BUFFER_SIZE) {
> >
> >  
> 
> Nice, for me, that brings qemu-system-ppc back up to speed. (applied to
> ppc-for-5.0)

thanks for confirming.

My patch a1b18df9a4 'vl.c: move -m parsing after memory backends has been processed'
moved ram_size parsing after accelerator init, but tcg allocates
buffer based on global ram_size and since ram_size is still 0 it
falls back to MIN_CODE_GEN_BUFFER_SIZE (see size_code_gen_buffer)
and if ram_size were too large it would cap buffet at
MAX_CODE_GEN_BUFFER_SIZE.

 *-user doesn't use ram_size, it uses DEFAULT_CODE_GEN_BUFFER_SIZE
and static buffer so it's no affected.

For softmmu it should be possible to postpone buffer allocation
till accel_setup_post(current_machine) time and fetch ram_size
from current machine dropping random access to global variable.
That would put buffer allocation after ram_size is parsed.

Does it look like a feasible approach?

> 
> Best,
> Howard