From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 12 Oct 2017 16:23:19 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171012142319.GA11254@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> Sender: owner-linux-mm@kvack.org To: Dan Williams Cc: linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , linux-api@vger.kernel.org, Dave Chinner , Christoph Hellwig , "J. Bruce Fields" , linux-mm@kvack.org, Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel@vger.kernel.org, Jeff Layton , Linus Torvalds , Andrew Morton List-ID: Sorry for chiming in so late, been extremely busy lately. >>From quickly glacing over what the now finally described use case is (which contradicts the subject btw - it's not about flushing, it's about not removing block mapping under a MR) and the previous comments I think that mmap is simply the wrong kind of interface for this. What we want is support for a new kinds of userspace memory registration in the RDMA code that uses the pnfs export interface, both getting the block (or rather byte in this case) mapping, and also gets the FL_LAYOUT lease for the memory registration. That btw is exactly what I do for the pNFS RDMA layout, just in-kernel. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:38500 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751853AbdJLOXV (ORCPT ); Thu, 12 Oct 2017 10:23:21 -0400 Date: Thu, 12 Oct 2017 16:23:19 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171012142319.GA11254@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Dan Williams Cc: linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , linux-api@vger.kernel.org, Dave Chinner , Christoph Hellwig , "J. Bruce Fields" , linux-mm@kvack.org, Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel@vger.kernel.org, Jeff Layton , Linus Torvalds , Andrew Morton Sorry for chiming in so late, been extremely busy lately. >>From quickly glacing over what the now finally described use case is (which contradicts the subject btw - it's not about flushing, it's about not removing block mapping under a MR) and the previous comments I think that mmap is simply the wrong kind of interface for this. What we want is support for a new kinds of userspace memory registration in the RDMA code that uses the pnfs export interface, both getting the block (or rather byte in this case) mapping, and also gets the FL_LAYOUT lease for the memory registration. That btw is exactly what I do for the pNFS RDMA layout, just in-kernel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Date: Thu, 12 Oct 2017 16:23:19 +0200 Message-ID: <20171012142319.GA11254@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <150776922692.9144.16963640112710410217.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dan Williams Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dave Chinner , Christoph Hellwig , "J. Bruce Fields" , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jeff Layton , Linus Torvalds , Andrew Morton List-Id: linux-api@vger.kernel.org Sorry for chiming in so late, been extremely busy lately. >>From quickly glacing over what the now finally described use case is (which contradicts the subject btw - it's not about flushing, it's about not removing block mapping under a MR) and the previous comments I think that mmap is simply the wrong kind of interface for this. What we want is support for a new kinds of userspace memory registration in the RDMA code that uses the pnfs export interface, both getting the block (or rather byte in this case) mapping, and also gets the FL_LAYOUT lease for the memory registration. That btw is exactly what I do for the pNFS RDMA layout, just in-kernel.