[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] include/exec/cpu-defs.h: try and make SoftM
Re: [Qemu-devel] [RFC PATCH] include/exec/cpu-defs.h: try and make SoftMMU page size match target
Mon, 10 Jul 2017 19:28:34 +0100
mu4e 0.9.19; emacs 220.127.116.11
Richard Henderson <address@hidden> 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