Writes via mmap currently update mtime and ctime in ->page_mkwrite. This hurts both throughput and latency. In workloads that dirty a large number of mmapped pages, ->page_mkwrite can be hot and file_update_time is slow and scales poorly. Updating timestamps can also sleep, which hurts latency for real-time workloads. This is also a correctness issue. SuS says: The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED and PROT_WRITE, will be marked for update at some point in the interval between a write reference to the mapped region and the next call to msync() with MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is no such call, these fields may be marked for update at any time after a write reference if the underlying file is modified as a result. Currently, if the same mmapped page is written twice, the timestamp may not be update at all after the second write, whereas SuS (and anything using timestamps to invalidate caches, backup data, etc.) would expect the timestamp to eventually be updated. This patchset attempts to fix both issues at once. It adds a new address_space flag AS_CMTIME that is set atomically whenever the system transfers a pte dirty bit to a struct page backed by the address_space. This can happen with various locks held and when low on memory. Later on, a_ops.update_cmtime_deferred is called to tell the FS to update cmtime due to a previous mmapped write. The core changes have no effect on unmodified filesystems. To opt in, a filesystem should implement .update_cmtime_deferred (most likely by using generic_update_cmtime_deferred) and must call either mapping_flush_cmtime or mapping_test_clear_cmtime in .writepages. Filesystems should avoid updating timestamps in ->page_mkwrite. The reason that this is not completely automatic is that filesystems without backing stores do not really fit in to this model. Eventually, someone can add support. I've converted ext4, xfs, and btrfs. Converting most other filesystems should be straightforward. I wrote an xfstest for this. ext4, xfs, and btrfs pass. It's here: https://github.com/amluto/xfstests/commit/5fbb72ac799cc44a9c4c6d3919f00a479202c899 This series is pullable from: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mmap_mtime/patch_v4 Changes from v3: - The new address space op is now called update_cmtime_deferred. Callers take care of protection from fs freezing and checking AS_CMTIME. I fixed a deadlock in the freezer interaction. - Block plugs should be handled better. - Fixed an infinite loop in msync(MS_ASYNC). - Converted xfs and btrfs. - Misc minor cleanups. - Fixed a corner case: reclaim or migration could have cleaned all pages without updating cmtime. Changes from v2: - The core code now interacts with filesystems only through address_space ops, so there should be fewer layering issues. - MS_ASYNC is handled correctly. Changes from v1: - inode_update_time_writable now locks against the fs freezer. - Minor cleanups. - Major changelog improvements. Andy Lutomirski (7): mm: Track mappings that have been written via ptes fs: Add inode_update_time_writable mm: Allow filesystems to defer cmtime updates mm: Scan for dirty ptes and update cmtime on MS_ASYNC ext4: Defer mmap cmtime updates btrfs: Defer mmap cmtime updates xfs: Defer mmap cmtime updates fs/btrfs/extent_io.c | 1 + fs/btrfs/inode.c | 32 +++++++++--------- fs/buffer.c | 7 ---- fs/ext4/inode.c | 11 +++++-- fs/inode.c | 64 +++++++++++++++++++++++++++--------- fs/xfs/xfs_aops.c | 1 + include/linux/fs.h | 9 +++++ include/linux/pagemap.h | 22 +++++++++++++ include/linux/writeback.h | 1 + mm/memory.c | 7 +++- mm/migrate.c | 2 ++ mm/mmap.c | 6 +++- mm/msync.c | 84 ++++++++++++++++++++++++++++++++++++++++------- mm/page-writeback.c | 53 +++++++++++++++++++++++++++++- mm/rmap.c | 27 +++++++++++++-- mm/vmscan.c | 1 + 16 files changed, 272 insertions(+), 56 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html