From: Jan Kara <jack@suse.cz>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>,
Dave Hansen <dave.hansen@linux.intel.com>,
xfs@oss.sgi.com, Jan Kara <jack@suse.cz>,
Tim Chen <tim.c.chen@linux.intel.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v3 0/5] Rework mtime and ctime updates on mmaped writes
Date: Wed, 4 Sep 2013 16:06:35 +0200 [thread overview]
Message-ID: <20130904140635.GC3996@quack.suse.cz> (raw)
In-Reply-To: <cover.1377193658.git.luto@amacapital.net>
On Thu 22-08-13 17:03:16, Andy Lutomirski wrote:
> 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
As a general note, I think you should CC linux-mm@kvack.org on this
series so that mm guys are more likely to notice it. Since the patches
touch mm you should probably get some opinions from them...
Honza
>
> 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
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-09-04 14:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-23 0:03 [PATCH v3 0/5] Rework mtime and ctime updates on mmaped writes Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 1/7] mm: Track mappings that have been written via ptes Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 2/7] fs: Add inode_update_time_writable Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 3/7] mm: Allow filesystems to defer cmtime updates Andy Lutomirski
2013-09-04 14:57 ` Jan Kara
2013-09-04 17:54 ` Andy Lutomirski
2013-09-04 19:20 ` Jan Kara
2013-09-04 20:05 ` Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 4/7] mm: Scan for dirty ptes and update cmtime on MS_ASYNC Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 5/7] ext4: Defer mmap cmtime updates Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 6/7] btrfs: " Andy Lutomirski
2013-08-23 0:03 ` [PATCH v4 7/7] xfs: " Andy Lutomirski
2013-08-23 1:12 ` [PATCH v3 0/5] Rework mtime and ctime updates on mmaped writes Andy Lutomirski
2013-09-04 14:06 ` Jan Kara [this message]
2013-09-04 15:08 ` Jan Kara
2013-09-04 17:33 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130904140635.GC3996@quack.suse.cz \
--to=jack@suse.cz \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=tim.c.chen@linux.intel.com \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).