From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753015AbbKPOli (ORCPT ); Mon, 16 Nov 2015 09:41:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:46573 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbbKPOle (ORCPT ); Mon, 16 Nov 2015 09:41:34 -0500 Date: Mon, 16 Nov 2015 15:41:30 +0100 From: Jan Kara To: Ross Zwisler Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Dan Williams , Dave Chinner , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, x86@kernel.org, xfs@oss.sgi.com, Andrew Morton , Matthew Wilcox , Dave Hansen Subject: Re: [PATCH v2 00/11] DAX fsynx/msync support Message-ID: <20151116144130.GD3443@quack.suse.cz> References: <1447459610-14259-1-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: <1447459610-14259-1-git-send-email-ross.zwisler@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 13-11-15 17:06:39, Ross Zwisler wrote: > This patch series adds support for fsync/msync to DAX. > > Patches 1 through 7 add various utilities that the DAX code will eventually > need, and the DAX code itself is added by patch 8. Patches 9-11 update the > three filesystems that currently support DAX, ext2, ext4 and XFS, to use > the new DAX fsync/msync code. > > These patches build on the recent DAX locking changes from Dave Chinner, > Jan Kara and myself. Dave's changes for XFS and my changes for ext2 have > been merged in the v4.4 window, but Jan's are still unmerged. You can grab > them here: > > http://www.spinics.net/lists/linux-ext4/msg49951.html I had a quick look and the patches look sane to me. I'll try to give them more detailed look later this week. When thinking about the general design I was wondering: When we have this infrastructure to track data potentially lingering in CPU caches, would not it be a performance win to use standard cached stores in dax_io() and mark corresponding pages as dirty in page cache the same way as this patch set does it for mmaped writes? I have no idea how costly are non-temporal stores compared to cached ones and how would this compare to the cost of dirty tracking so this may be just completely bogus... Honza -- Jan Kara SUSE Labs, CR