From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 45A41202E6152 for ; Mon, 16 Oct 2017 00:18:56 -0700 (PDT) Date: Mon, 16 Oct 2017 09:22:27 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171016072227.GA28270@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20171013163822.GA17411@obsidianresearch.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Jason Gunthorpe Cc: "J. Bruce Fields" , Jan Kara , Andrew Morton , Arnd Bergmann , "linux-nvdimm@lists.01.org" , Linux API , "Darrick J. Wong" , Dave Chinner , linux-xfs@vger.kernel.org, Linux MM , Jeff Layton , Al Viro , Andy Lutomirski , linux-fsdevel , Linus Torvalds , Christoph Hellwig List-ID: On Fri, Oct 13, 2017 at 10:38:22AM -0600, Jason Gunthorpe wrote: > > scheme specific to RDMA which seems like a waste to me when we can > > generically signal an event on the fd for any event that effects any > > of the vma's on the file. The FL_LAYOUT lease impacts the entire file, > > so as far as I can see delaying the notification until MR-init is too > > late, too granular, and too RDMA specific. > > But for RDMA a FD is not what we care about - we want the MR handle so > the app knows which MR needs fixing. Yes. Although the fd for the ibX device might be a good handle to transport that information, unlike the fd for the mapped file. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 16 Oct 2017 09:22:27 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Dan Williams , Christoph Hellwig , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171016072227.GA28270@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171013163822.GA17411@obsidianresearch.com> Sender: owner-linux-mm@kvack.org List-ID: On Fri, Oct 13, 2017 at 10:38:22AM -0600, Jason Gunthorpe wrote: > > scheme specific to RDMA which seems like a waste to me when we can > > generically signal an event on the fd for any event that effects any > > of the vma's on the file. The FL_LAYOUT lease impacts the entire file, > > so as far as I can see delaying the notification until MR-init is too > > late, too granular, and too RDMA specific. > > But for RDMA a FD is not what we care about - we want the MR handle so > the app knows which MR needs fixing. Yes. Although the fd for the ibX device might be a good handle to transport that information, unlike the fd for the mapped file. -- 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]:53440 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbdJPHW3 (ORCPT ); Mon, 16 Oct 2017 03:22:29 -0400 Date: Mon, 16 Oct 2017 09:22:27 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171016072227.GA28270@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171013163822.GA17411@obsidianresearch.com> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Jason Gunthorpe Cc: Dan Williams , Christoph Hellwig , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton On Fri, Oct 13, 2017 at 10:38:22AM -0600, Jason Gunthorpe wrote: > > scheme specific to RDMA which seems like a waste to me when we can > > generically signal an event on the fd for any event that effects any > > of the vma's on the file. The FL_LAYOUT lease impacts the entire file, > > so as far as I can see delaying the notification until MR-init is too > > late, too granular, and too RDMA specific. > > But for RDMA a FD is not what we care about - we want the MR handle so > the app knows which MR needs fixing. Yes. Although the fd for the ibX device might be a good handle to transport that information, unlike the fd for the mapped file. 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: Mon, 16 Oct 2017 09:22:27 +0200 Message-ID: <20171016072227.GA28270@lst.de> References: <150776922692.9144.16963640112710410217.stgit@dwillia2-desk3.amr.corp.intel.com> <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20171013163822.GA17411-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jason Gunthorpe Cc: Dan Williams , Christoph Hellwig , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton List-Id: linux-api@vger.kernel.org On Fri, Oct 13, 2017 at 10:38:22AM -0600, Jason Gunthorpe wrote: > > scheme specific to RDMA which seems like a waste to me when we can > > generically signal an event on the fd for any event that effects any > > of the vma's on the file. The FL_LAYOUT lease impacts the entire file, > > so as far as I can see delaying the notification until MR-init is too > > late, too granular, and too RDMA specific. > > But for RDMA a FD is not what we care about - we want the MR handle so > the app knows which MR needs fixing. Yes. Although the fd for the ibX device might be a good handle to transport that information, unlike the fd for the mapped file.