[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: performance regression from c/s 21647:cfba1560054a
>>> On 10.11.11 at 16:22, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > On Thu, 10 Nov 2011, Jan Beulich wrote: >> >>> On 10.11.11 at 16:16, Stefano Stabellini >> >>> <stefano.stabellini@xxxxxxxxxxxxx> >> wrote: >> > On Thu, 10 Nov 2011, Jan Beulich wrote: >> >> >>> On 10.11.11 at 15:59, Stefano Stabellini >> >> >>> <stefano.stabellini@xxxxxxxxxxxxx> >> >> wrote: >> >> > On Thu, 10 Nov 2011, Jan Beulich wrote: >> >> >> It's SLE11 SP1 guests that suffered a regression after a maintenance >> >> >> update (originally shipped with 4.0.0, while that patch got backported >> >> >> later into 4.0.x). >> >> > >> >> > Is SLES11 SP1 using HVMOP_pagetable_dying (see >> >> > arch/x86/xen/mmu.c:xen_hvm_init_mmu_ops)? >> >> >> >> No, it's not. >> > >> > well, it should, not to fix this problem but because it is a significant >> > performance improvement when running on shadow >> >> Well - if you have suggestions on how to do this (a) in 2.6.32.x, (b) >> without turning on CONFIG_XEN, and (c) without massive patching, >> them I'm all for it. > > Can you issue hypercalls? >From the pv drivers yes, from the rest of the kernel not easily. But installing a hook from the pv drivers is pointless afaik, since the paravirt patching would likely have eliminated the call site by that time. > If so, it is just a matter of backporting: > > commit 5915100106b8f14a38053ad6c03a664d208aeaa2 > Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > Date: Thu Jun 17 14:22:52 2010 +0100 > > x86: Call HVMOP_pagetable_dying on exit_mmap. > > When a pagetable is about to be destroyed, we notify Xen so that the > hypervisor can clear the related shadow pagetable. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx> Hmm, I should have been saying CONFIG_PARAVIRT_MMU (we have an extra patch that splits CONFIG_PARATVIRT into sub-pieces) rather than CONFIG_XEN above - the patch relies on pv_mmu_ops, which our SP1 non-Xen kernels don't have enabled (in SP2 we don't have the splitting patch anymore, and we do have CONFIG_PARAVIRT, but as per the above doing this when the pv drivers load is likely too late). Which leaves utilizing mmu_notifier_release() as long as CONFIG_MMU_NOTIFIER is enabled, which fortunately KVM selects for us. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |