Re: [RFC] KVM MMU: improve large munmap efficiency

[Avi Kivity <avi@redhat.com>]

On 01/27/2012 01:24 AM, Eric Northup wrote:
> Flush the shadow MMU instead of iterating over each host VA when doing
> a large invalidate range callback.
>
> The previous code is O(N) in the number of virtual pages being
> invalidated, while holding both the MMU spinlock and the mmap_sem.
> Large unmaps can cause significant delay, during which the process is
> unkillable.  Worse, all page allocation could be delayed if there's
> enough memory pressure that mmu_shrink gets called.
>
> Signed-off-by: Eric Northup <digitaleric@google.com>
>
> ---
>
> We have seen delays of over 30 seconds doing a large (128GB) unmap.
>
> It'd be nicer to check if the amount of work to be done by the entire
> flush is less than the work to be done iterating over each HVA page,
> but that information isn't currently available to the arch-
> independent part of KVM.
>
> Better ideas would be most welcome ;-)
>
>
> Tested by attaching a debugger to a running qemu w/kvm and running
> "call munmap(0, 1UL << 46)".
>

How about computing the intersection of (start, end) with the hva ranges
in kvm->memslots?

If there is no intersection, you exit immediately.

It's still possible for the work to drop the intersection to be larger
than dropping the entire shadow, but it's unlikely.

-- 
error compiling committee.c: too many arguments to function