Re: [PATCH v4] mm: filemap: retain mapped dropbehind folios

[Barry Song]

On Sun, Aug 30, 2026 at 5:13 PM Wenjie Qi <qwjhust@xxxxxxxxx> wrote:
>
> Yes.  The current path removes the folio from the page cache, so a later
> mmap access can incur both another fault and I/O.  I should have stated
> that explicitly.
>
> For fault-around neighbors, folio_mapped() cannot distinguish the faulting
> page from a speculative neighbor.  This patch takes the conservative policy
> that an installed PTE represents a competing cache user and wins over the
> writer's RWF_DONTCACHE hint.  It can therefore retain a speculative neighbor
> which is never accessed.  Distinguishing those cases seems to require
> fault-around to preserve the faulting folio while not mapping, or later
> dropping, dropbehind neighbors.  I think that should be considered as a
> separate follow-up.

Yes. Maybe we can skip mapping neighbors with the dropbehind flag in
fault-around.

>
> For folio_launder(), filemap_end_dropbehind() holds the folio lock and returns
> if the folio is dirty or under writeback before calling
> folio_unmap_invalidate().  folio_launder() also immediately returns for a
> clean folio.  I do not see how nfs_launder_folio() is reached from this
> completion path unless the locked, unmapped folio can become dirty between
> those checks.  Is there a path I am missing?

You are probably right. I was referring to the bit wait in
nfs_launder_folio(), though I'm not quite sure whether this can
actually happen:
folio_wait_private_2(folio); /* [DEPRECATED] */

I assume we won't wait for `private_2` while the folio is clean. If so,
it should be fine.