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 [off-list ref]
SUSE Labs, CR

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>