Re: KVM swapping with mmu notifiers #v5

[Andrea Arcangeli <andrea-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

On Thu, Jan 31, 2008 at 12:21:34PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> 
> > I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
> > all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
> 
> The GRU not covered? Why would you think that way? mremap is covered 
> because of the callbacks in unmap_region().

I wouldn't be so sure. ptep_clear_flush is called for a reason and you
have zero range_start _before_ the ptep_clear_flush. If you're right
it means ptep_clear_flush there is called for no good reason and it
should be replaced with ptep_get_and_clear and eliminate an
unnecessary tlb flush from the mremap fast path, and a tlb flush that
will cost an huge lot with threads, an IPI for every single PTE in
SMP! So you may be right, but then it means we found a really stupid
spot to optimize in mremap. (I've to say I've already found a silly
thing in the ptep_ that sets the accessed bitflag, pte entries w/o
accessed bit set can't be tlb-cached, this is an hardware thing, so
the tlb flush there on x86 is a total waste of ipis)

> > Being dependent on XPMEM support being merged, to merge KVM/GRU
> > doesn't sound a good idea. My patch provides no overhead with
> > MMU_NOTIFIER=n too. Hope Christoph agrees with my proposal to use #v5
> > as the mmu core and to merge it in mainline with higher priority, to
> > mostly close the discussions on KVM and GRU (optimizations remains
> > possible) and to keep working incrementally on XPMEM and to push it in
> > mainline whenever you verified that it doesn't crash at runtime and
> > that you don't need yet another change of API.
> 
> Please read the comments on your #5. #5 makes wrong assumptions about the 
> nature of pte locks. As a result locking is broken.

You misunderstood the locking, #v5 is obviously safe. If #v5 wasn't
safe, any SMP with >4 cpus would crash already regardless of my changes...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/