From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite() Date: Tue, 25 Jul 2017 14:15:22 +0200 Message-ID: <20170725121522.GA13457@lst.de> References: <20170724170616.25810-1-ross.zwisler@linux.intel.com> <20170724170616.25810-2-ross.zwisler@linux.intel.com> <20170724221400.pcq5zvke7w2yfkxi@node.shutemov.name> <20170725080158.GA5374@lst.de> <20170725093508.GA19943@quack2.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Theodore Ts'o , Andrew Morton , "Darrick J. Wong" , Dave Chinner , Jonathan Corbet , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Steven Rostedt , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Ingo Molnar , Andreas Dilger , Alexander Viro , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Kirill A. Shutemov" , linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Christoph Hellwig , Matthew Wilcox , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org To: Jan Kara Return-path: Content-Disposition: inline In-Reply-To: <20170725093508.GA19943-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" List-Id: linux-ext4.vger.kernel.org On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote: > On Tue 25-07-17 10:01:58, Christoph Hellwig wrote: > > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote: > > > I guess it's up to filesystem if it wants to reuse the same spot to write > > > data or not. I think your assumptions works for ext4 and xfs. I wouldn't > > > be that sure for btrfs or other filesystems with CoW support. > > > > Or XFS with reflinks for that matter. Which currently can't be > > combined with DAX, but I had a somewhat working version a few month > > ago. > > But in cases like COW when the block mapping changes, the process > must run unmap_mapping_range() before installing the new PTE so that all > processes mapping this file offset actually refault and see the new > mapping. So this would go through pte_none() case. Am I missing something? Yes, for DAX COW mappings we'd probably need something like this, unlike the pagecache COW handling for which only the underlying block change, but not the page. 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 A9BDE21C91255 for ; Tue, 25 Jul 2017 05:13:22 -0700 (PDT) Date: Tue, 25 Jul 2017 14:15:22 +0200 From: Christoph Hellwig Subject: Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite() Message-ID: <20170725121522.GA13457@lst.de> References: <20170724170616.25810-1-ross.zwisler@linux.intel.com> <20170724170616.25810-2-ross.zwisler@linux.intel.com> <20170724221400.pcq5zvke7w2yfkxi@node.shutemov.name> <20170725080158.GA5374@lst.de> <20170725093508.GA19943@quack2.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170725093508.GA19943@quack2.suse.cz> 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: Jan Kara Cc: Theodore Ts'o , Andrew Morton , "Darrick J. Wong" , Dave Chinner , Jonathan Corbet , linux-kernel@vger.kernel.org, Steven Rostedt , linux-doc@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar , Andreas Dilger , Alexander Viro , linux-fsdevel@vger.kernel.org, "Kirill A. Shutemov" , linux-ext4@vger.kernel.org, Christoph Hellwig , Matthew Wilcox , linux-nvdimm@lists.01.org List-ID: On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote: > On Tue 25-07-17 10:01:58, Christoph Hellwig wrote: > > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote: > > > I guess it's up to filesystem if it wants to reuse the same spot to write > > > data or not. I think your assumptions works for ext4 and xfs. I wouldn't > > > be that sure for btrfs or other filesystems with CoW support. > > > > Or XFS with reflinks for that matter. Which currently can't be > > combined with DAX, but I had a somewhat working version a few month > > ago. > > But in cases like COW when the block mapping changes, the process > must run unmap_mapping_range() before installing the new PTE so that all > processes mapping this file offset actually refault and see the new > mapping. So this would go through pte_none() case. Am I missing something? Yes, for DAX COW mappings we'd probably need something like this, unlike the pagecache COW handling for which only the underlying block change, but not the page. _______________________________________________ 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]:58373 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbdGYMPY (ORCPT ); Tue, 25 Jul 2017 08:15:24 -0400 Date: Tue, 25 Jul 2017 14:15:22 +0200 From: Christoph Hellwig Subject: Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite() Message-ID: <20170725121522.GA13457@lst.de> References: <20170724170616.25810-1-ross.zwisler@linux.intel.com> <20170724170616.25810-2-ross.zwisler@linux.intel.com> <20170724221400.pcq5zvke7w2yfkxi@node.shutemov.name> <20170725080158.GA5374@lst.de> <20170725093508.GA19943@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170725093508.GA19943@quack2.suse.cz> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Jan Kara Cc: Christoph Hellwig , "Kirill A. Shutemov" , Ross Zwisler , Andrew Morton , linux-kernel@vger.kernel.org, "Darrick J. Wong" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Dan Williams , Dave Chinner , Ingo Molnar , Jonathan Corbet , Matthew Wilcox , Steven Rostedt , linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote: > On Tue 25-07-17 10:01:58, Christoph Hellwig wrote: > > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote: > > > I guess it's up to filesystem if it wants to reuse the same spot to write > > > data or not. I think your assumptions works for ext4 and xfs. I wouldn't > > > be that sure for btrfs or other filesystems with CoW support. > > > > Or XFS with reflinks for that matter. Which currently can't be > > combined with DAX, but I had a somewhat working version a few month > > ago. > > But in cases like COW when the block mapping changes, the process > must run unmap_mapping_range() before installing the new PTE so that all > processes mapping this file offset actually refault and see the new > mapping. So this would go through pte_none() case. Am I missing something? Yes, for DAX COW mappings we'd probably need something like this, unlike the pagecache COW handling for which only the underlying block change, but not the page. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 25 Jul 2017 14:15:22 +0200 From: Christoph Hellwig To: Jan Kara Cc: Christoph Hellwig , "Kirill A. Shutemov" , Ross Zwisler , Andrew Morton , linux-kernel@vger.kernel.org, "Darrick J. Wong" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Dan Williams , Dave Chinner , Ingo Molnar , Jonathan Corbet , Matthew Wilcox , Steven Rostedt , linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite() Message-ID: <20170725121522.GA13457@lst.de> References: <20170724170616.25810-1-ross.zwisler@linux.intel.com> <20170724170616.25810-2-ross.zwisler@linux.intel.com> <20170724221400.pcq5zvke7w2yfkxi@node.shutemov.name> <20170725080158.GA5374@lst.de> <20170725093508.GA19943@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170725093508.GA19943@quack2.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote: > On Tue 25-07-17 10:01:58, Christoph Hellwig wrote: > > On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote: > > > I guess it's up to filesystem if it wants to reuse the same spot to write > > > data or not. I think your assumptions works for ext4 and xfs. I wouldn't > > > be that sure for btrfs or other filesystems with CoW support. > > > > Or XFS with reflinks for that matter. Which currently can't be > > combined with DAX, but I had a somewhat working version a few month > > ago. > > But in cases like COW when the block mapping changes, the process > must run unmap_mapping_range() before installing the new PTE so that all > processes mapping this file offset actually refault and see the new > mapping. So this would go through pte_none() case. Am I missing something? Yes, for DAX COW mappings we'd probably need something like this, unlike the pagecache COW handling for which only the underlying block change, but not the page. -- 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