From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <rth@twiddle.net>
Cc: peter.maydell@linaro.org, bobby.prani@gmail.com,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>
Subject: Re: [Qemu-devel] [RFC PATCH] include/exec/cpu-defs.h: try and make SoftMMU page size match target
Date: Mon, 10 Jul 2017 19:28:34 +0100 [thread overview]
Message-ID: <87o9ss9mel.fsf@linaro.org> (raw)
In-Reply-To: <1e34d387-753b-14ff-dcc0-226515ff0124@twiddle.net>
Richard Henderson <rth@twiddle.net> writes:
> On 07/10/2017 04:28 AM, Alex Bennée wrote:
>> While the SoftMMU is not emulating the target MMU of a system there is
>> a relationship between its page size and that of the target. If the
>> target MMU is full featured the functions called to re-fill the
>> entries in the SoftMMU entries start moving up the perf profiles. If
>> we can we should try and prevent too much thrashing around by having
>> the page sizes the same.
>
> What you are changing has absolutely nothing to do with page size.
> Mentioning page sizes just confuses the issue.
>
> What you're changing is the number of entries in the TLB, and the
> mapping between pages and TLB entries. And I'm quite certain that you
> saw a performance increase by increasing the size of the TLB.
You are quite right, I'm going to claim Monday brain on the commit text.
There is some relationship though as the index into the SoftMMU TLB is a
product of the target page number masked by the total number of SoftMMU
TLB entries we have. By increasing the SoftMMU TLB size we reduce the
number of aliased target pages for any given SoftMMU entry.
I guess to have a better understanding of the slow-path fill patterns we
would want to have an idea of which entries are getting re-filled more
often and if there is an even distribution over the TLB?
>
>
>> #define CPU_TLB_BITS \
>> - MIN(8, \
>> + MIN(10, \
>
> You will find this has broken tcg/arm, because the operand to an armv6
> AND (immediate) instruction is only 8 bits.
>
> I will grant you that we could do a better job of configuring this
> across the tcg backends.
>
> It also possibly warrants some work in the tcg/arm backend so that
> armv7 makes use of UBFX so that not-ancient arm is not so constrained.
I think Pranith is going to take this forward with a patch set to expand
the SoftMMU TLB to the maximum supported by whichever the backend can
do.
--
Alex Bennée
prev parent reply other threads:[~2017-07-10 18:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 14:28 [Qemu-devel] [RFC PATCH] include/exec/cpu-defs.h: try and make SoftMMU page size match target Alex Bennée
2017-07-10 14:35 ` Peter Maydell
2017-07-10 15:17 ` Alex Bennée
2017-07-10 15:23 ` Peter Maydell
2017-07-10 16:55 ` Richard Henderson
2017-07-10 18:28 ` Alex Bennée [this message]
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=87o9ss9mel.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=bobby.prani@gmail.com \
--cc=crosthwaite.peter@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).