qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/5] AArch64 TLB performance improvements


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v2 0/5] AArch64 TLB performance improvements
Date: Mon, 04 Aug 2014 11:23:43 +0100

Peter Maydell writes:

> On 1 August 2014 17:06, Peter Maydell <address@hidden> wrote:
>> I'm taking the first two of these into target-arm.next because
>> they're obvious standalone bugfixes. I need to think about the
>> last three a bit more: I dislike just dropping the ARMv5 CPUs
>> from qemu-system-aarch64, it's kind of arbitrary.
>
> So:
>  * there's clearly a big perf win to be had here
>  * this patchset gives us that for 4K pages on AArch64
>  * but it doesn't help for 4K pages on AArch32 (really
>     common)

Well for the AArch32 profile if you ran under qemu-system-aarch64 you
would be OK surely?

>  * and it's not going to be good for 64K pages on AArch64
>    either (which I suspect will not be a rare choice)

Does the kernel already use 64k pages for it's code?

>
> So I think it would be good if we investigated the degree
> of difficulty in improving QEMU's TLB code so it isn't just
> "one TLB entry size with larger pages a bolt-on which we
> hope people don't actually use" first, before we just disable
> all the v5 CPUs.

Given there is likely to be a growth of multiple-page size guests we
probably do want to look at cleaning up the TLB code to handle these
cases gracefully.

Another option we could look at is keeping track of cross-page TB links
and then invalidating them if we need to. We might want to do that based
on heuristics so avoid excessive cleaning up. However you would expect
for example the kernel to sit in it's own set of bigger pages which
never get invalidated where we could happily chain more TBs together.

>
> thanks
> -- PMM

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]