Re: [RFC PATCH 0/5] mm: sub-folio dirty tracking for PTE-mapped mmap writes

[Matthew Wilcox <willy@infradead.org>]

On Mon, Sep 07, 2026 at 11:15:15AM +0100, Kiryl Shutsemau wrote:
> Boris pointed me to Matthew's proposal to remove ->dirty_folio:
> 
> https://lore.kernel.org/all/aoyWln-Gt-yvZQkE@casper.infradead.org

Thanks, Boris ;-)

> I agree that the current ->dirty_folio() makes little sense and that
> dirtying the folio can be bundled into ->page_mkwrite(), as they are
> matched 1-to-1.
> 
> My proposal makes the distinction between making the folio writable and
> making it dirty meaningful. ->page_mkwrite() allocates whatever is needed
> on the filesystem side to track dirty state and drive writeback for the
> *folio*, while ->dirty_folio_range() marks part of the folio dirty.

Why do you think that's a meaningful distinction?  We create a writable
PTE because we've taken a page fault for write.  There's probably a few
naoseconds where the PTE is writable+clean before it becomes
writable+dirty, but even then sometimes we do both pte_mkwrite() and
pte_mkdirty() as an optimisation in the write fault path.

> We can still drop ->dirty_folio(). A filesystem can provide
> ->dirty_folio_range() if it wants fine-grained (sub-folio) dirty
> tracking.
> 
> A separate question is whether we want to avoid installing a writable PMD
> entry for filesystems that want fine-grained dirty tracking. I have a
> patch for this, but it deserves a separate discussion once we agree that we
> want this for PTE-mapped folios first.
> 
> Any feedback?

It's very odd to be optimising for shared-writable-mmap.  This is a
horrid model for I/O.  https://cs.brown.edu/people/acrotty/pubs/p13-crotty.pdf