From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757174AbYDWNoj (ORCPT ); Wed, 23 Apr 2008 09:44:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752952AbYDWNo3 (ORCPT ); Wed, 23 Apr 2008 09:44:29 -0400 Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:35646 "EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752815AbYDWNo3 (ORCPT ); Wed, 23 Apr 2008 09:44:29 -0400 Date: Wed, 23 Apr 2008 15:44:27 +0200 From: Andrea Arcangeli To: Christoph Lameter Cc: Nick Piggin , Jack Steiner , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Steve Wise , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, Robin Holt , general@lists.openfabrics.org, Hugh Dickins , akpm@linux-foundation.org, Rusty Russell Subject: Re: [PATCH 04 of 12] Moves all mmu notifier methods outside the PT lock (first and not last Message-ID: <20080423134427.GW24536@duo.random> References: <20080422224048.GR24536@duo.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 On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote: > We want a full solution and this kind of patching makes the patches > difficuilt to review because later patches revert earlier ones. I know you rather want to see KVM development stalled for more months than to get a partial solution now that already covers KVM and GRU with the same API that XPMEM will also use later. It's very unfair on your side to pretend to stall other people development if what you need has stronger requirements and can't be merged immediately. This is especially true given it was publically stated that XPMEM never passed all regression tests anyway, so you can't possibly be in such an hurry like we are, we can't progress without this. Infact we can but it would be an huge effort and it would run _slower_ and it would all need to be deleted once mmu notifiers are in. Note that the only patch that you can avoid with your approach is mm_lock-rwsem, given that's software developed and not human developed I don't see a big deal of wasted effort. The main difference is the ordering. Most of the code is orthogonal so there's not much to revert. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: [ofa-general] Re: [PATCH 04 of 12] Moves all mmu notifier methods outside the PT lock (first and not last Date: Wed, 23 Apr 2008 15:44:27 +0200 Message-ID: <20080423134427.GW24536@duo.random> References: <20080422224048.GR24536@duo.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nick Piggin , Rusty Russell , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Jack Steiner , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, Robin Holt , general@lists.openfabrics.org, Hugh Dickins , akpm@linux-foundation.org To: Christoph Lameter Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: general-bounces@lists.openfabrics.org Errors-To: general-bounces@lists.openfabrics.org List-Id: kvm.vger.kernel.org On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote: > We want a full solution and this kind of patching makes the patches > difficuilt to review because later patches revert earlier ones. I know you rather want to see KVM development stalled for more months than to get a partial solution now that already covers KVM and GRU with the same API that XPMEM will also use later. It's very unfair on your side to pretend to stall other people development if what you need has stronger requirements and can't be merged immediately. This is especially true given it was publically stated that XPMEM never passed all regression tests anyway, so you can't possibly be in such an hurry like we are, we can't progress without this. Infact we can but it would be an huge effort and it would run _slower_ and it would all need to be deleted once mmu notifiers are in. Note that the only patch that you can avoid with your approach is mm_lock-rwsem, given that's software developed and not human developed I don't see a big deal of wasted effort. The main difference is the ordering. Most of the code is orthogonal so there's not much to revert. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 23 Apr 2008 15:44:27 +0200 From: Andrea Arcangeli Subject: Re: [PATCH 04 of 12] Moves all mmu notifier methods outside the PT lock (first and not last Message-ID: <20080423134427.GW24536@duo.random> References: <20080422224048.GR24536@duo.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Nick Piggin , Jack Steiner , Peter Zijlstra , kvm-devel@lists.sourceforge.net, Kanoj Sarcar , Roland Dreier , Steve Wise , linux-kernel@vger.kernel.org, Avi Kivity , linux-mm@kvack.org, Robin Holt , general@lists.openfabrics.org, Hugh Dickins , akpm@linux-foundation.org, Rusty Russell List-ID: On Tue, Apr 22, 2008 at 04:14:26PM -0700, Christoph Lameter wrote: > We want a full solution and this kind of patching makes the patches > difficuilt to review because later patches revert earlier ones. I know you rather want to see KVM development stalled for more months than to get a partial solution now that already covers KVM and GRU with the same API that XPMEM will also use later. It's very unfair on your side to pretend to stall other people development if what you need has stronger requirements and can't be merged immediately. This is especially true given it was publically stated that XPMEM never passed all regression tests anyway, so you can't possibly be in such an hurry like we are, we can't progress without this. Infact we can but it would be an huge effort and it would run _slower_ and it would all need to be deleted once mmu notifiers are in. Note that the only patch that you can avoid with your approach is mm_lock-rwsem, given that's software developed and not human developed I don't see a big deal of wasted effort. The main difference is the ordering. Most of the code is orthogonal so there's not much to revert. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org