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

[Barry Song]

On Sun, Aug 30, 2026 at 11:25 AM Wenjie Qi <qwjhust@xxxxxxxxx> wrote:
>
> From: Wenjie Qi <qiwenjie@xxxxxxxxxx>
>
> Fault-around can map ready dropbehind folios without going through the
> normal page-cache lookup that clears dropbehind. A mapping represents a
> competing cached user, but writeback completion can currently unmap that
> folio. A later mmap access must then fault it back in.

Andrew is asking for a visible user-facing impact. I think the current
mainline code might result in an extra fault-in and extra I/O. Maybe we
should highlight this?
On the other hand, my gut feeling is that this patch might only be
50% right, rather than 100% right.
Fault-around might just end up mapping data that will never be accessed
at all (fault-around mappings aren't really fault-mapped), while the user
has explicitly requested "dropbehind", which seems like a strong hint
that they don't need it :-)

>
> Retain mapped folios instead. For a mapped folio,
> folio_unmap_invalidate() can call unmap_mapping_folio(), which takes
> i_mmap_rwsem and may sleep. Retaining the folio also avoids this path when
> folio_end_dropbehind() runs in non-preemptible task context.
>

I'm not quite sure this can be entirely avoided. Somehow,
`folio_launder(mapping, folio)` could also be nasty. For example, NFS
can still be problematic today:

static int nfs_launder_folio(struct folio *folio)
{
        struct inode *inode = folio->mapping->host;
        int ret;

        dfprintk(PAGECACHE, "NFS: launder_folio(%llu, %llu)\n",
                inode->i_ino, folio_pos(folio));

        folio_wait_private_2(folio); /* [DEPRECATED] */
        ret = nfs_wb_folio(inode, folio);
        trace_nfs_launder_folio_done(inode, folio_pos(folio),
                        folio_size(folio), ret);
        return ret;
}

Best Regards
Barry