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

[Kiryl Shutsemau]

On Thu, Sep 03, 2026 at 07:29:38PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> 
> A store through a shared file mapping dirties the whole folio. With large
> page cache folios that turns a 4K store into 2M of writeback: one dirty
> bit per folio, and writeback has no way to know which part changed.
> 
> XFS already knows better. iomap tracks dirty state per block and
> iomap_writeback_folio() submits only the dirty ranges, and the buffered
> write path sets just the range it copied. Only the mmap path throws that
> away, because iomap_dirty_folio() covers the whole folio.
> 
> Narrowing the dirtying at page_mkwrite() time does not work on its own:
> set_pte_range() batch-maps a whole folio writable on the first shared
> write fault, so the stores that follow never fault and never reach the
> filesystem.
> 
> So harvest the hardware instead. folio_clear_dirty_for_io() already calls
> folio_mkclean(), whose rmap walk reads pte_dirty() for every entry of the
> folio and throws it away. Those bits are the only record of which parts
> of a large folio were written through a mapping. Collect them there and
> hand the filesystem the runs that were dirty, through a new
> a_ops->dirty_folio_range().

Boris pointed me to Matthew's proposal to remove ->dirty_folio:

https://lore.kernel.org/all/aoyWln-Gt-yvZQkE@xxxxxxxxxxxxxxxxxxxx

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.

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?

> All of this is about PTE-mapped folios. A PMD-mapped folio has a single
> dirty bit for the 2M it maps, so there is nothing finer to harvest, and
> it keeps writing back whole. Keeping shared write faults off PMDs is a
> separate patch and not part of this posting.
> 
> On a 512M file in 2M folios on XFS, storing one byte per folio and
> calling msync() wrote 512M before and writes 1M after, with identical
> minor fault counts.
> 
> Not addressed here:
> 
>  - Dirty accounting stays folio-granular. A 4K store still counts as 2M
>    against dirty_ratio and balance_dirty_pages().
>  - iomap_page_mkwrite() still allocates blocks for the whole folio.
>  - Filesystems without per-block dirty state see no change.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov