From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 8 Feb 2016 11:31:12 -0700 From: Ross Zwisler Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems Message-ID: <20160208183112.GF2343@linux.intel.com> References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Dan Williams Cc: Ross Zwisler , "linux-kernel@vger.kernel.org" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Andrew Morton , Dave Chinner , Jan Kara , Matthew Wilcox , linux-ext4 , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , XFS Developers , jmoyer List-ID: On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > The proposal: make applications explicitly request DAX semantics with > a new MAP_DAX flag and fail if DAX is unavailable. Document that a > successful MAP_DAX request mandates that the application assumes > responsibility for cpu cache management. > Require that all applications that mmap the file agree on MAP_DAX. I think this proposal could run into issues with aliasing. For example, say you have two threads accessing the same region, and one wants to use DAX and the other wants to use the page cache. What happens? If we satisfy both requests, we end up with one user reading and writing to the page cache, while the other is reading and writing directly to the media. They can't see each other's changes, and you get data corruption. If we satisfy the request of whoever asked first, sort of lock the inode into that mode, and then return an error to the second thread because they are asking for the other mode, we have now introduced a new weird failure case where mmaps can randomly fail based on the behavior of other applications. I think this is where you were going with the last line quoted above, but I don't understand how it would work in an acceptable way. It seems like we have to have the decision about whether or not to use DAX made in the same way for all users of the inode so that we don't run into these types of conflicts. > This also solves > the future problem of DAX support on virtually tagged cache > architectures where it is difficult for the kernel to know what alias > addresses need flushing. > > [1]: https://github.com/pmem/nvml -- 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754935AbcBHSbz (ORCPT ); Mon, 8 Feb 2016 13:31:55 -0500 Received: from mga01.intel.com ([192.55.52.88]:38857 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753292AbcBHSbv (ORCPT ); Mon, 8 Feb 2016 13:31:51 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,417,1449561600"; d="scan'208";a="911007210" Date: Mon, 8 Feb 2016 11:31:12 -0700 From: Ross Zwisler To: Dan Williams Cc: Ross Zwisler , "linux-kernel@vger.kernel.org" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Andrew Morton , Dave Chinner , Jan Kara , Matthew Wilcox , linux-ext4 , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , XFS Developers , jmoyer Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems Message-ID: <20160208183112.GF2343@linux.intel.com> Mail-Followup-To: Ross Zwisler , Dan Williams , "linux-kernel@vger.kernel.org" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Andrew Morton , Dave Chinner , Jan Kara , Matthew Wilcox , linux-ext4 , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , XFS Developers , jmoyer References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > The proposal: make applications explicitly request DAX semantics with > a new MAP_DAX flag and fail if DAX is unavailable. Document that a > successful MAP_DAX request mandates that the application assumes > responsibility for cpu cache management. > Require that all applications that mmap the file agree on MAP_DAX. I think this proposal could run into issues with aliasing. For example, say you have two threads accessing the same region, and one wants to use DAX and the other wants to use the page cache. What happens? If we satisfy both requests, we end up with one user reading and writing to the page cache, while the other is reading and writing directly to the media. They can't see each other's changes, and you get data corruption. If we satisfy the request of whoever asked first, sort of lock the inode into that mode, and then return an error to the second thread because they are asking for the other mode, we have now introduced a new weird failure case where mmaps can randomly fail based on the behavior of other applications. I think this is where you were going with the last line quoted above, but I don't understand how it would work in an acceptable way. It seems like we have to have the decision about whether or not to use DAX made in the same way for all users of the inode so that we don't run into these types of conflicts. > This also solves > the future problem of DAX support on virtually tagged cache > architectures where it is difficult for the kernel to know what alias > addresses need flushing. > > [1]: https://github.com/pmem/nvml From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C7FAF7CA2 for ; Mon, 8 Feb 2016 12:31:30 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 43F49AC003 for ; Mon, 8 Feb 2016 10:31:30 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by cuda.sgi.com with ESMTP id IAv8Ku4ga4L2pNle for ; Mon, 08 Feb 2016 10:31:29 -0800 (PST) Date: Mon, 8 Feb 2016 11:31:12 -0700 From: Ross Zwisler Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems Message-ID: <20160208183112.GF2343@linux.intel.com> References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dan Williams Cc: Theodore Ts'o , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , XFS Developers , Linux MM , jmoyer , Andreas Dilger , Alexander Viro , Jan Kara , linux-fsdevel , Matthew Wilcox , Ross Zwisler , linux-ext4 , Andrew Morton On Sun, Feb 07, 2016 at 11:13:51AM -0800, Dan Williams wrote: > The proposal: make applications explicitly request DAX semantics with > a new MAP_DAX flag and fail if DAX is unavailable. Document that a > successful MAP_DAX request mandates that the application assumes > responsibility for cpu cache management. > Require that all applications that mmap the file agree on MAP_DAX. I think this proposal could run into issues with aliasing. For example, say you have two threads accessing the same region, and one wants to use DAX and the other wants to use the page cache. What happens? If we satisfy both requests, we end up with one user reading and writing to the page cache, while the other is reading and writing directly to the media. They can't see each other's changes, and you get data corruption. If we satisfy the request of whoever asked first, sort of lock the inode into that mode, and then return an error to the second thread because they are asking for the other mode, we have now introduced a new weird failure case where mmaps can randomly fail based on the behavior of other applications. I think this is where you were going with the last line quoted above, but I don't understand how it would work in an acceptable way. It seems like we have to have the decision about whether or not to use DAX made in the same way for all users of the inode so that we don't run into these types of conflicts. > This also solves > the future problem of DAX support on virtually tagged cache > architectures where it is difficult for the kernel to know what alias > addresses need flushing. > > [1]: https://github.com/pmem/nvml _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs