From: "Alex Bennée" <alex.bennee@linaro.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Howard Spoelstra" <hsp.cat7@gmail.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org,
"Niek Linnenbank" <nieklinnenbank@gmail.com>,
qemu-arm <qemu-arm@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: Sudden slowdown of ARM emulation in master
Date: Wed, 26 Feb 2020 15:29:16 +0000 [thread overview]
Message-ID: <87blplxt83.fsf@linaro.org> (raw)
In-Reply-To: <20200226154525.5c4c0ac9@redhat.com>
Igor Mammedov <imammedo@redhat.com> writes:
> On Wed, 26 Feb 2020 14:13:11 +0000
> Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Wed, 26 Feb 2020 at 09:19, 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) {
>> >
>> > 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?
>
> *-user call
> tcg_exec_init(0);
> which in in the end results in
> DEFAULT_CODE_GEN_BUFFER_SIZE -> DEFAULT_CODE_GEN_BUFFER_SIZE_1
>
> so for *-user cases we can just always call
> code_gen_alloc(DEFAULT_CODE_GEN_BUFFER_SIZE)
<snip>
I've gone for a variation of that, coming to a mailing list near you
real soon now ;-)
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-devel@nongnu.org,
"Niek Linnenbank" <nieklinnenbank@gmail.com>,
qemu-arm <qemu-arm@nongnu.org>,
"Howard Spoelstra" <hsp.cat7@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: Sudden slowdown of ARM emulation in master
Date: Wed, 26 Feb 2020 15:29:16 +0000 [thread overview]
Message-ID: <87blplxt83.fsf@linaro.org> (raw)
In-Reply-To: <20200226154525.5c4c0ac9@redhat.com>
Igor Mammedov <imammedo@redhat.com> writes:
> On Wed, 26 Feb 2020 14:13:11 +0000
> Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Wed, 26 Feb 2020 at 09:19, 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) {
>> >
>> > 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?
>
> *-user call
> tcg_exec_init(0);
> which in in the end results in
> DEFAULT_CODE_GEN_BUFFER_SIZE -> DEFAULT_CODE_GEN_BUFFER_SIZE_1
>
> so for *-user cases we can just always call
> code_gen_alloc(DEFAULT_CODE_GEN_BUFFER_SIZE)
<snip>
I've gone for a variation of that, coming to a mailing list near you
real soon now ;-)
--
Alex Bennée
next prev parent reply other threads:[~2020-02-26 15:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 23:07 Sudden slowdown of ARM emulation in master Niek Linnenbank
2020-02-26 8:41 ` Peter Maydell
2020-02-26 8:44 ` Philippe Mathieu-Daudé
2020-02-26 8:48 ` Peter Maydell
2020-02-26 8:51 ` Philippe Mathieu-Daudé
2020-02-26 8:45 ` Howard Spoelstra
2020-02-26 9:11 ` Igor Mammedov
2020-02-26 9:19 ` Igor Mammedov
2020-02-26 9:32 ` Howard Spoelstra
2020-02-26 10:14 ` Igor Mammedov
2020-02-26 10:03 ` Peter Maydell
2020-02-26 10:36 ` Mark Cave-Ayland
2020-02-26 14:13 ` Alex Bennée
2020-02-26 14:13 ` Alex Bennée
2020-02-26 14:45 ` Igor Mammedov
2020-02-26 14:45 ` Igor Mammedov
2020-02-26 15:29 ` Alex Bennée [this message]
2020-02-26 15:29 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87blplxt83.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=hsp.cat7@gmail.com \
--cc=imammedo@redhat.com \
--cc=nieklinnenbank@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.