Re: [PATCH v10 0/7] mm, iomap, NFSD: stop uncached writes reading back shared pages

[Mike Snitzer <snitzer@kernel.org>]

[against my better judgement I'm replying, hoping technical discussion
wins out.. usually does]

On Wed, Nov 04, 2026 at 10:17:40AM +0100, Christoph Hellwig wrote:
> On Tue, Nov 03, 2026 at 04:17:47PM -0500, Mike Snitzer wrote:
> > Hi,
> > 
> > An uncached (RWF_DONTCACHE) buffered write drops each folio it writes
> > once the folio is written back.  A folio that the write covers only
> > partly is shared with the neighbouring write.  If it is dropped before
> > the neighbour writes its part, the neighbour reads it back from disk
> > first.  32 threads writing interleaved records to one XFS file, 4 KiB
> > pages, before and after 5/7:
> 
> Very colourful terminology here.  Who is "the neighbour".  How do we
> know a "neighbour" exists and what it wants to do?

"the neighbour" was meant to convey the other write that covers the
rest of a page that another write covers only partly.  For example,
with 4 KiB pages, a write of bytes 0 to 5999 covers bytes 4096 to 5999
of the second page.  A write that starts at byte 6000 covers the rest
of that page.

We do not know that such a write will come, and patch 5/7 does not
assume it.  5/7 looks only at the state of the page:

- If the page is not uptodate, it is not fully written.  5/7 does not
  mark it dropbehind.  It stays in the page cache, like a page from a
  normal buffered write, until a write completes it or reclaim drops
  it.
- If the page is uptodate, it already holds the other part, and this
  write completes it.  5/7 marks it dropbehind, and the writeback that
  cleans it drops it.

So if no other write comes, at most the first and last page of each
write stay cached.  If one comes, writeback drops the page after both
writes, and the second write does not read it from disk.

> In general if the user gave a very clear indication that the data
> should not be cached, it is a bit awkward to second [g]uess that.

RWF_DONTCACHE does not keep data out of the page cache.  It is buffered
IO, so all of the data goes through the page cache.  The flag only asks
the kernel to drop the pages after writeback: "buffered IO that drops
the cache after reading or writing data" (include/uapi/linux/fs.h).  It
is also best effort today: an RWF_DONTCACHE write drops only the pages
that it creates, not the pages that it finds in the cache.

5/7 does not change whether the data goes through the page cache.  It
changes only when the kernel drops a partially written page.  Today the
kernel drops the page before another write might get to it.  That write
must then read the page back from disk into the page cache, to merge its
own bytes.  So the page cache does not hold less: it holds the same page
twice, with a disk read between.  In the cover letter test, that is 0.97
device reads per write, and 831 MiB/s instead of 2281 MiB/s.  The user
asked for less page cache use, not for a read-modify-write of each
misaligned write.

> Especially if the expectations are not very clearly documented.

The 5/7 commit message states it: "An edge whose neighbour never writes,
such as the last page of a file, stays cached until reclaim."  So the
only change to what the user sees is: an RWF_DONTCACHE write can leave
the first and last page of the write in the page cache, if no other
write completes them.  Writeback drops all other pages of the write,
as before.

Mike

ps. I'll reduce the "colourful terminology" in v11 (e.g. drop
"neighbour" jargon) and also address the 2 issues sashiko raised
against v10's 6/7.