Peter Maydell <peter.mayd...@linaro.org> writes:
> On Wed, 26 Feb 2020 at 09:19, 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) {
>
> Cc'ing Richard to ask: does it still make sense for TCG
> to pick a codegen buffer size based on the guest RAM size?
Arguably you would never get more than ram_size * tcg gen overhead of
active TBs at any one point although you can come up with pathological
patterns where only a subset of pages are flushed in and out at a time.
However the backing for the code is mmap'ed anyway so surely the kernel
can work out the kinks here. We will never allocate more than the code
generator can generate jumps for anyway.
Looking at the SoftMMU version of alloc_code_gen_buffer it looks like
everything now falls under the:
# if defined(__PIE__) || defined(__PIC__)
leg so there is a bunch of code to be deleted there. The remaining
question is what to do for linux-user because there is a bit more logic
to deal with some corner cases on the static code generation buffer.
I'd be tempted to rename DEFAULT_CODE_GEN_BUFFER_SIZE to
SMALL_CODE_GEN_BUFFER_SIZE and only bother with a static allocation for
32 bit linux-user hosts. Otherwise why not default to
MAX_CODE_GEN_BUFFER_SIZE on 64 bit systems and let the kernel deal with
it?
> (We should fix the regression anyway, but it surprised me
> slightly to find a config detail of the guest machine being
> used here.)
>
> thanks
> -- PMM
--
Alex Bennée
