From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: KVM swapping with mmu notifiers #v5 Date: Fri, 1 Feb 2008 00:32:26 +0100 Message-ID: <20080131233225.GR7185@v2.random> References: <20080131173041.GO7185@v2.random> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Christoph Lameter Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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/