Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764949AbYCDWUv (ORCPT ); Tue, 4 Mar 2008 17:20:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757315AbYCDWUj (ORCPT ); Tue, 4 Mar 2008 17:20:39 -0500 Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:55114 "EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757274AbYCDWUi (ORCPT ); Tue, 4 Mar 2008 17:20:38 -0500 Date: Tue, 4 Mar 2008 23:20:30 +0100 From: Andrea Arcangeli To: Christoph Lameter Cc: Jack Steiner , Nick Piggin , akpm@linux-foundation.org, Robin Holt , Avi Kivity , kvm-devel@lists.sourceforge.net, Peter Zijlstra , general@lists.openfabrics.org, Steve Wise , Roland Dreier , Kanoj Sarcar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com Subject: Re: [RFC] Notifier for Externally Mapped Memory (EMM) Message-ID: <20080304222030.GB8951@v2.random> References: <20080221144023.GC9427@v2.random> <20080221161028.GA14220@sgi.com> <20080227192610.GF28483@v2.random> <20080302155457.GK8091@v2.random> <20080303213707.GA8091@v2.random> <20080303220502.GA5301@v2.random> <47CC9B57.5050402@qumranet.com> <20080304133020.GC5301@v2.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2180 Lines: 46 On Tue, Mar 04, 2008 at 11:00:31AM -0800, Christoph Lameter wrote: > But as you pointed out before that path is a slow path anyways. Its rarely It's a slow path but I don't see why you think two hooks are better than one, when only one is necessary. I once ripped invalidate_page while working on #v8 but then I reintroduced it because I thought reducing the total number of hooks was beneficial to the core linux VM (even if only a microoptimization, I sure agree about that, but it's trivial to add one hook instead of two hooks there, so a microoptimization was worth it IMHO). Your API is also too restrictive, if we'll happen to need one more method that doesn't take just (start,end) we'll have to cause all drivers to have significant changes instead of one-liners to use whatever new feature. > taken. Having a single eviction callback simplifies design. IMHO the design is actually same and I don't understand why you rewrote it once more time in a less flexibile way (on a style side you're not even using hlist), dropping RCU (not sure how you replace it with), etc.... Your implementation has the same bug you had in your first V1, see how you're not clearing the spte young bits if the pte young bit is set. Once you fix that, your change in the ptep_clear_flush_young path will look remarkably similar to the patch I posted incremental with #v8 to make ->clear_flush_young sleep capable... Converging in a single design is great, but it'd be nice if we could converge into a single implementation, and my last patch doesn't have any bug and I think it's quite nicer too (also including Nick cleanup work) but then I may be biased ;). But as usual I'm entirely satisfied by your brand new EMM Notifier to be merged and all perfecting work done on my MMU notifier patch over the weeks by multiple developers (including you) to be dropped for good, as long as we can enable the new advanced KVM features in 2.6.25. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/