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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
