On 11.10.2012, at 16:52, Marc Zyngier wrote: > On 11/10/12 15:42, Christoffer Dall wrote: >> On Thu, Oct 11, 2012 at 8:54 AM, Alexander Graf <agraf@xxxxxxx> wrote: >>> >>> On 11.10.2012, at 12:37, Peter Maydell wrote: >>> >>>> On 11 October 2012 11:27, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>>>> On 11/10/12 10:55, Alexander Graf wrote >>>>>> On 11.10.2012, at 11:46, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>>>>>> - Our memory bandwidth is reduced by the number of TLB entries we waste >>>>>>> by not using section mappings instead of 4kB pages. Running hackbench on >>>>>>> a guest shows quite a slowdown that should mostly go away if/when >>>>>>> userspace switches to huge pages as backing store. I expect virtio to >>>>>>> suffer from the same problem. >>>>>> >>>>>> That one should be in a completely different ballpark. I'd be very >>>>> surprised if you get more than 10% slowdowns in TLB miss intensive >>>>> workloads. Definitely not as low of a hanging fruit as we see here. >>>> >>>>> The A15 uses separate TLBs for stage-1 and stage-2 translation, which >>>>> means that each random memory access costs us two TLBs, effectively >>>>> reducing the efficiency of the translation hardware by 50%. >>>>> >>>>> Using 2MB sections as the backing store (stage-2) should definitely be a >>>>> quite an improvement. >>>> >>>> Having done a quick google and looked at the QEMU code, I think that >>>> hugepage support should be a purely kernel-side thing: if you add >>>> transparent hugepage support then QEMU will just DTRT without special >>>> config. >>>> >>>> (Alex: does that sound right?) >>> >>> Don't bother with transparent hugepage support for now. Just use -mem-path and a directly mounted hugetlbfs with a page pool. But yes, no changes needed in QEMU at all. All the infrastructure for that is there already. >>> >>> If you need code to look at on how this works, check out >>> >>> http://lxr.free-electrons.com/source/arch/powerpc/kvm/e500_tlb.c?a=powerpc#L498 >>> >>> >> I'm working on this already. > > QEMU or kernel side? QEMU is already done. Nothing arch specific to do there. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
