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 B10E82095E537 for ; Tue, 26 Sep 2017 07:30:47 -0700 (PDT) Date: Tue, 26 Sep 2017 16:33:58 +0200 From: Christoph Hellwig Subject: Re: [PATCH 3/7] xfs: protect S_DAX transitions in XFS read path Message-ID: <20170926143357.GA18758@lst.de> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-4-ross.zwisler@linux.intel.com> <20170926063234.GA6870@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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: Dan Williams Cc: Jeff Layton , Jan Kara , Andrew Morton , "Darrick J. Wong" , "linux-nvdimm@lists.01.org" , Dave Chinner , "linux-kernel@vger.kernel.org" , "J. Bruce Fields" , Linux MM , linux-fsdevel , linux-xfs@vger.kernel.org, Christoph Hellwig List-ID: On Tue, Sep 26, 2017 at 06:59:37AM -0700, Dan Williams wrote: > > I think you probably want an IOCB_DAX flag to check IS_DAX once and > > then stick to it, similar to what we do for direct I/O. > > I wonder if this works better with a reference count mechanism > per-file so that we don't need a hold a lock over the whole > transition. Similar to request_queue reference counting, when DAX is > being turned off we block new references and drain the in-flight ones. Maybe. But that assumes we want to be stuck in a perpetual binary DAX on/off state on a given file. Which makes not only for an awkward interface (inode or mount flag), but also might be fundamentally the wrong thing to do for some media where you'd happily read directly from it but rather buffer writes in DRAM. _______________________________________________ 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: Received: from verein.lst.de ([213.95.11.211]:58878 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936827AbdIZOd7 (ORCPT ); Tue, 26 Sep 2017 10:33:59 -0400 Date: Tue, 26 Sep 2017 16:33:58 +0200 From: Christoph Hellwig Subject: Re: [PATCH 3/7] xfs: protect S_DAX transitions in XFS read path Message-ID: <20170926143357.GA18758@lst.de> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-4-ross.zwisler@linux.intel.com> <20170926063234.GA6870@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Dan Williams Cc: Christoph Hellwig , Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , "Darrick J. Wong" , "J. Bruce Fields" , Dave Chinner , Jan Kara , Jeff Layton , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org On Tue, Sep 26, 2017 at 06:59:37AM -0700, Dan Williams wrote: > > I think you probably want an IOCB_DAX flag to check IS_DAX once and > > then stick to it, similar to what we do for direct I/O. > > I wonder if this works better with a reference count mechanism > per-file so that we don't need a hold a lock over the whole > transition. Similar to request_queue reference counting, when DAX is > being turned off we block new references and drain the in-flight ones. Maybe. But that assumes we want to be stuck in a perpetual binary DAX on/off state on a given file. Which makes not only for an awkward interface (inode or mount flag), but also might be fundamentally the wrong thing to do for some media where you'd happily read directly from it but rather buffer writes in DRAM. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 26 Sep 2017 16:33:58 +0200 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , "Darrick J. Wong" , "J. Bruce Fields" , Dave Chinner , Jan Kara , Jeff Layton , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org Subject: Re: [PATCH 3/7] xfs: protect S_DAX transitions in XFS read path Message-ID: <20170926143357.GA18758@lst.de> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-4-ross.zwisler@linux.intel.com> <20170926063234.GA6870@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: On Tue, Sep 26, 2017 at 06:59:37AM -0700, Dan Williams wrote: > > I think you probably want an IOCB_DAX flag to check IS_DAX once and > > then stick to it, similar to what we do for direct I/O. > > I wonder if this works better with a reference count mechanism > per-file so that we don't need a hold a lock over the whole > transition. Similar to request_queue reference counting, when DAX is > being turned off we block new references and drain the in-flight ones. Maybe. But that assumes we want to be stuck in a perpetual binary DAX on/off state on a given file. Which makes not only for an awkward interface (inode or mount flag), but also might be fundamentally the wrong thing to do for some media where you'd happily read directly from it but rather buffer writes in DRAM. -- 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