Re: [PATCH v7 4/5] mm, iomap: let an uncached writer complete its shared pages itself

[Mike Snitzer <snitzer@kernel.org>]

On Wed, Oct 21, 2026 at 06:54:14AM -0400, Jeff Layton wrote:
> 
> 2 comments from Chuck's sashiko on this one:
> 
> [Severity: Low]
> Could filemap_dontcache_edge_complete() in mm/filemap.c avoid missing the
> immediate drop when another task acquires the folio lock between
> folio_unlock() and folio_end_dropbehind()? In that case folio_end_dropbehind()
> fails its folio_trylock() and does not retry; if the folio is already clean,
> there may be no later writeback completion to drop it, so it can remain cached
> until unrelated activity or reclaim.

Yes.  There was no reason to let go of the lock first: the folio is
locked and we are in task context, so v8 drops it with
filemap_end_dropbehind() before the unlock, as folio_end_dropbehind()
does once its trylock succeeds.

> [Severity: Medium]
> Could filemap_dontcache_edge_complete() in mm/filemap.c restrict marking to
> the boundary page when the mapping returns a large folio? iomap_get_folio()
> in fs/iomap/buffered-io.c limits a partial edge request to one page, but the
> mapping's minimum folio order can still cause __filemap_get_folio_mpol() to
> return a multi-page folio, or the lookup can find an existing large folio.
> This helper then marks the entire folio for drop-behind. For example, if a
> caller uses deferred completion on an XFS mapping with a minimum folio order,
> marking one edge can account the whole dirty folio for DONTCACHE writeback or
> invalidate the whole clean, unmapped folio. Could this path handle only the
> page covered by the completed edge?

Also right, and it applied to 3/5 as well: the folio a write finds
uptodate there was marked whole in the same way.  3/5 only creates the
edge as a single page; a lookup can find a larger folio that readahead
or an earlier buffered write left, and dropping it drops everything in
it, including other edges whose second write hasn't come yet, which
then pay the read-back this series is meant to remove.  A folio can't
be dropped in part, so v8 marks a found folio only when it is the
smallest the mapping allows, folio_nr_pages(folio) ==
mapping_min_folio_nrpages(mapping): a single page, or a single block
where the block is larger than a page, which is then the unit two
writes share.  A larger folio is left unmarked, cached until reclaim
as it is without the series.  That is in 3/5's lookup and in both 4/5
helpers.

Looking at that turned up two more places that used the page where the
smallest folio is the unit, both fixed in v8:

- 3/5's iomap change decided that a write covers its first or last page
  only partly by page offset, so on a mapping whose blocks are larger
  than a page a write starting on a page boundary inside a block didn't
  ask for its block as an edge.  It now tests against
  mapping_min_folio_nrbytes().
- NFSD cuts a misaligned end of a direct-mode WRITE on a page boundary
  (80728157d1bd, "NFSD: cut a misaligned direct-mode WRITE at page
  boundaries", in Chuck's nfsd-testing), so there the direct middle and
  a buffered end could share a block.  v8 has a fix for that at the
  front, so the end is cut at the smallest folio as well.

Measured on XFS on an emulated 4Kn NVMe, 4 KiB pages, 32 threads writing
interleaved 47008-byte records, 1 GiB, 4 KiB reads per write from the
device, v7 against v8:

                                                v7        v8
  RWF_DONTCACHE over large folios readahead
    left (pages resident after)          0.94 (6%)  0.0026 (100%)
  RWF_DONTCACHE, 16 KiB blocks              1.62    0.0014
    (12288-byte records)                    2.89    0.0004
  NFS WRITEs through NFSD DIRECT,
    16 KiB blocks                           3.46    0.0016

(v7 in 128 MiB runs, v8 in 1 GiB runs; 16384-byte records, which cover
only whole blocks, read 0 either way.  On 16 KiB blocks one block read
back per write is 4.0 here.)

Thanks,
Mike