From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754713AbYBSL7w (ORCPT ); Tue, 19 Feb 2008 06:59:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751494AbYBSL7o (ORCPT ); Tue, 19 Feb 2008 06:59:44 -0500 Received: from relay2.sgi.com ([192.48.171.30]:58599 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751301AbYBSL7n (ORCPT ); Tue, 19 Feb 2008 06:59:43 -0500 Date: Tue, 19 Feb 2008 05:59:38 -0600 From: Robin Holt To: Nick Piggin Cc: akpm@linux-foundation.org, Andrea Arcangeli , Robin Holt , Avi Kivity , Izik Eidus , kvm-devel@lists.sourceforge.net, Peter Zijlstra , general@lists.openfabrics.org, Steve Wise , Roland Dreier , Kanoj Sarcar , steiner@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com, Christoph Lameter Subject: Re: [patch] my mmu notifiers Message-ID: <20080219115938.GD11391@sgi.com> References: <20080219084357.GA22249@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080219084357.GA22249@wotan.suse.de> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote: > So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers > are rather similar. However I have tried to make a point of minimising the > impact the the core mm/. I don't see why we need to invalidate or flush > anything when changing the pte to be _more_ permissive, and I don't > understand the need for invalidate_begin/invalidate_end pairs at all. > What I have done is basically create it so that the notifiers get called > basically in the same place as the normal TLB flushing is done, and nowhere > else. Because XPMEM needs to be able to sleep during its callout. For that, we need to move this outside of the page table lock and suddenly we need the begin/end pair again. There was considerable discussion about this exact point numerous times. We tried to develop the most inclusive design possible. Our design would even be extendable to IB, assuming they made some very disruptive changes to their MPI and communication libraries. IB would suffer the same problems XPMEM does in that the TLB entries need to be removed on a remote host which is operating completely independently. Thanks, Robin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Holt Subject: Re: [patch] my mmu notifiers Date: Tue, 19 Feb 2008 05:59:38 -0600 Message-ID: <20080219115938.GD11391@sgi.com> References: <20080219084357.GA22249@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: steiner@sgi.com, Andrea Arcangeli , Peter Zijlstra , linux-mm@kvack.org, Kanoj Sarcar , Roland Dreier , Steve Wise , linux-kernel@vger.kernel.org, Avi Kivity , kvm-devel@lists.sourceforge.net, daniel.blueman@quadrics.com, Robin Holt , general@lists.openfabrics.org, akpm@linux-foundation.org, Christoph Lameter To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <20080219084357.GA22249@wotan.suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote: > So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers > are rather similar. However I have tried to make a point of minimising the > impact the the core mm/. I don't see why we need to invalidate or flush > anything when changing the pte to be _more_ permissive, and I don't > understand the need for invalidate_begin/invalidate_end pairs at all. > What I have done is basically create it so that the notifiers get called > basically in the same place as the normal TLB flushing is done, and nowhere > else. Because XPMEM needs to be able to sleep during its callout. For that, we need to move this outside of the page table lock and suddenly we need the begin/end pair again. There was considerable discussion about this exact point numerous times. We tried to develop the most inclusive design possible. Our design would even be extendable to IB, assuming they made some very disruptive changes to their MPI and communication libraries. IB would suffer the same problems XPMEM does in that the TLB entries need to be removed on a remote host which is operating completely independently. Thanks, Robin ------------------------------------------------------------------------- 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 19 Feb 2008 05:59:38 -0600 From: Robin Holt Subject: Re: [patch] my mmu notifiers Message-ID: <20080219115938.GD11391@sgi.com> References: <20080219084357.GA22249@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080219084357.GA22249@wotan.suse.de> Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: akpm@linux-foundation.org, Andrea Arcangeli , Robin Holt , Avi Kivity , Izik Eidus , kvm-devel@lists.sourceforge.net, Peter Zijlstra , general@lists.openfabrics.org, Steve Wise , Roland Dreier , Kanoj Sarcar , steiner@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com, Christoph Lameter List-ID: On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote: > So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers > are rather similar. However I have tried to make a point of minimising the > impact the the core mm/. I don't see why we need to invalidate or flush > anything when changing the pte to be _more_ permissive, and I don't > understand the need for invalidate_begin/invalidate_end pairs at all. > What I have done is basically create it so that the notifiers get called > basically in the same place as the normal TLB flushing is done, and nowhere > else. Because XPMEM needs to be able to sleep during its callout. For that, we need to move this outside of the page table lock and suddenly we need the begin/end pair again. There was considerable discussion about this exact point numerous times. We tried to develop the most inclusive design possible. Our design would even be extendable to IB, assuming they made some very disruptive changes to their MPI and communication libraries. IB would suffer the same problems XPMEM does in that the TLB entries need to be removed on a remote host which is operating completely independently. Thanks, Robin -- 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