On Wed, 26 Feb 2020 10:32:38 +0100
Howard Spoelstra <hsp.c...@gmail.com> wrote:
> On Wed, Feb 26, 2020 at 10:19 AM Igor Mammedov <imamm...@redhat.com> wrote:
>
> > On Wed, 26 Feb 2020 00:07:55 +0100
> > Niek Linnenbank <nieklinnenb...@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
