[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>
> On Thu, 10 Nov 2011, Jan Beulich wrote:
>> >>> On 10.11.11 at 16:16, Stefano Stabellini
>> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>> > 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
> 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.
Xen-devel mailing list