From: Mike Snitzer <snitzer@kernel.org>
To: Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>
Cc: linux-nfs@vger.kernel.org, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: [PATCH v5 0/6] mm, iomap, NFSD: stop uncached writes reading back shared pages
Date: Mon, 19 Oct 2026 11:07:19 -0400 [thread overview]
Message-ID: <20261019150725.1507-1-snitzer@kernel.org> (raw)
Hi,
Chuck asked, of v4 7-9, whether those changes belong in NFSD or in mm:
"Seems like you've identified an issue with DONTCACHE itself that
shouldn't be limited to an NFSD-only fix." He was right, and v5 moves
the fix into the page cache.
An uncached (RWF_DONTCACHE) buffered write drops each page it writes
once that page is written back. A page the write covers only partly is
shared with the neighbouring write, and once the first of the two has
been written back the second has to read it back from disk before it
can write its part. This shows without NFS. 32 threads writing
interleaved records to one file on XFS (emulated 4Kn NVMe, 4 KiB pages),
before and after 4/6:
record pwritev2() flags 4 KiB device MiB/s
bytes reads per write
before after before after
47008 RWF_DONTCACHE 0.97 0.000 831 2281
47008 RWF_DONTCACHE|RWF_DSYNC 0.99 0.000 601 1227
6000 RWF_DONTCACHE 0.97 0.000 121 488
6000 RWF_DONTCACHE|RWF_DSYNC 0.99 0.000 90 206
4/6 has the page cache keep such a page for the write that completes
it, and drop it after that. 5/6 lets a writer that syncs its own write,
as NFSD does for a stable WRITE, mark those pages itself once the sync
is done, so they are dropped without extra writeback. 6/6 is what is
left of v4's 9/10: NFSD uses 5/6 and no longer manages any page cache
state of its own.
For NFSD DIRECT, 32 interleaved writers of 47008-byte records, against
v4:
device reads per WRITE MiB/s
each record sent as v4 v5 v4 v5
1 FILE_SYNC WRITE 0.0102 0.0002 379 402
2, one after the other 0.0021 0.0001 217 237
2 at the same time 0.0401 0.0001 212 234
2 UNSTABLE, then COMMIT 0.0944 0.0001 219 248
and a FILE_SYNC WRITE no longer wakes the DONTCACHE writeback kick at
all. The patches' own descriptions carry the details.
How this might land:
- 1/6, tracepoints for how each direct-mode READ and WRITE is serviced,
is NFSD only and does not depend on the rest. Chuck, it can go into
nfsd-testing on its own.
- 2/6 to 5/6 are mm, with small iomap changes and an IOCB flag in 4/6
and 5/6; 6/6 is the NFSD change that uses them. They are Cc'd to
linux-mm and linux-fsdevel. It would help if the mm and iomap
maintainers could review them and, if they are agreeable, ack them for
Chuck to take 2/6 to 6/6 through nfsd-testing, so that further NFSD
direct-mode changes can build on them there.
The series applies to cel/nfsd-testing (b4e06bef3884) and each patch
builds with W=1 with no warnings.
Changes since v4:
- v4 1/10 to 6/10 dropped: Chuck applied them to nfsd-testing.
- v4 10/10, the tracepoints, moved first, as 1/6.
- v4 7/10 and 8/10 swapped, as 3/6 and 2/6.
- New 4/6 and 5/6: the page cache, not NFSD, keeps the shared page.
- 6/6 (was 9/10) retitled "NFSD: drop a shared boundary page only once
both WRITEs have written it" and reduced to calling 5/6's functions.
It folds in "NFSD: mark a shared boundary page only once the other
WRITE has written it", posted in reply to v4 9/10.
- nfsd-io-modes.rst describes the page cache keeping the shared page.
v4: https://lore.kernel.org/linux-nfs/20261015233309.42999-1-snitzer@kernel.org/
v3: https://lore.kernel.org/linux-nfs/20261001045502.48381-1-snitzer@kernel.org/
v2: https://lore.kernel.org/linux-nfs/20260929231329.22018-1-snitzer@kernel.org/
v1: https://lore.kernel.org/linux-nfs/20260929173423.16149-1-snitzer@kernel.org/
Thanks,
Mike
Mike Snitzer (6):
NFSD: add tracing for how direct-mode READ and WRITE are serviced
mm: expose WB_DONTCACHE_DIRTY in bdi debugfs stats
mm: add folio_mark_dropbehind() to mark a folio dropbehind and account it
mm, iomap: keep a partly covered page until an uncached write completes it
mm, iomap: let an uncached writer complete its shared pages itself
NFSD: drop a shared boundary page only once both WRITEs have written it
.../filesystems/nfs/nfsd-io-modes.rst | 55 ++++++-
fs/iomap/buffered-io.c | 16 +-
fs/iomap/trace.h | 3 +-
fs/nfsd/trace.h | 77 +++++++++
fs/nfsd/vfs.c | 146 +++++++++++++++---
fs/nfsd/vfs.h | 9 ++
include/linux/fs.h | 8 +-
include/linux/iomap.h | 1 +
include/linux/pagemap.h | 12 ++
mm/backing-dev.c | 11 ++
mm/filemap.c | 106 ++++++++++++-
11 files changed, 413 insertions(+), 31 deletions(-)
--
2.52.0
next reply other threads:[~2026-10-19 15:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 15:07 Mike Snitzer [this message]
2026-10-19 15:07 ` [PATCH v5 1/6] NFSD: add tracing for how direct-mode READ and WRITE are serviced Mike Snitzer
2026-10-19 15:14 ` Chuck Lever
2026-10-19 17:10 ` Jeff Layton
2026-10-19 18:33 ` Chuck Lever
2026-10-20 3:25 ` [PATCH draft-v6 " Mike Snitzer
2026-10-20 11:07 ` Jeff Layton
2026-10-19 15:07 ` [PATCH v5 2/6] mm: expose WB_DONTCACHE_DIRTY in bdi debugfs stats Mike Snitzer
2026-10-19 16:57 ` Jeff Layton
2026-10-19 15:07 ` [PATCH v5 3/6] mm: add folio_mark_dropbehind() to mark a folio dropbehind and account it Mike Snitzer
2026-10-19 15:07 ` [PATCH v5 4/6] mm, iomap: keep a partly covered page until an uncached write completes it Mike Snitzer
2026-10-19 15:07 ` [PATCH v5 5/6] mm, iomap: let an uncached writer complete its shared pages itself Mike Snitzer
2026-10-19 15:07 ` [PATCH v5 6/6] NFSD: drop a shared boundary page only once both WRITEs have written it Mike Snitzer
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=20261019150725.1507-1-snitzer@kernel.org \
--to=snitzer@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=axboe@kernel.dk \
--cc=cel@kernel.org \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=willy@infradead.org \
/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