[Xen-devel] Re: performance regression from c/s 21647:cfba1560054a

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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