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 <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>