Peter Maydell writes: > On 1 August 2014 17:06, Peter Maydell <peter.mayd...@linaro.org> 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
