From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756182AbYDWSC3 (ORCPT ); Wed, 23 Apr 2008 14:02:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753313AbYDWSCV (ORCPT ); Wed, 23 Apr 2008 14:02:21 -0400 Received: from relay2.sgi.com ([192.48.171.30]:54533 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751144AbYDWSCU (ORCPT ); Wed, 23 Apr 2008 14:02:20 -0400 Date: Wed, 23 Apr 2008 11:02:18 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Andrea Arcangeli 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 In-Reply-To: <20080423134427.GW24536@duo.random> Message-ID: References: <20080422224048.GR24536@duo.random> <20080423134427.GW24536@duo.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Apr 2008, Andrea Arcangeli wrote: > 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. We have had this workaround effort done years ago and have been suffering the ill effects of pinning for years. Had to deal with it again and again so I guess we do not matter? Certainly we have no interest in stalling KVM development.