From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [ofa-general] Re: [patch 0/6] MMU Notifiers V6 References: <20080208220616.089936205@sgi.com> <20080208142315.7fe4b95e.akpm@linux-foundation.org> <20080208233636.GG26564@sgi.com> <20080208234302.GH26564@sgi.com> <20080208155641.2258ad2c.akpm@linux-foundation.org> From: Roland Dreier Date: Fri, 08 Feb 2008 16:22:41 -0800 In-Reply-To: (Christoph Lameter's message of "Fri, 8 Feb 2008 16:16:34 -0800 (PST)") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: andrea@qumranet.com, a.p.zijlstra@chello.nl, izike@qumranet.com, steiner@sgi.com, linux-kernel@vger.kernel.org, avi@qumranet.com, linux-mm@kvack.org, daniel.blueman@quadrics.com, Robin Holt , general@lists.openfabrics.org, Andrew Morton , kvm-devel@lists.sourceforge.net List-ID: Of course we can always destroy the memory region but that would break the semantics that applications expect. Basically an application can register some chunk of its memory and get a key that it can pass to a remote peer to let the remote peer operate on its memory via RDMA. And that memory region/key is expected to stay valid until there is an application-level operation to destroy it (or until the app crashes or gets killed, etc). > We could also let the unmapping fail if the driver indicates that the > mapping must stay. That would of course work -- dumb adapters would just always fail, which might be inefficient. -- 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