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

[Matthew Wilcox]

On Wed, Sep 16, 2026 at 06:09:17PM +0100, Kiryl Shutsemau wrote:
> On Wed, Sep 16, 2026 at 05:27:42PM +0100, Matthew Wilcox wrote:
> > On Mon, Sep 07, 2026 at 11:15:15AM +0100, Kiryl Shutsemau wrote:
> > > 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.
> 
> This is true for the PTE that the fault was for. But we don't necessarily
> want to dirty the other 511 pages at the same time.
> 
> The basic idea is to make the whole folio writable at fault and shift
> dirtying to be per-PTE on write to it.

Hmm.  Is that something that filesystem people want?  I suspect not.
I think they'd prefer to be told when we write-fault on each page.
But let's see if we can gather feedback from FS people.

> > 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
> 
> Sure.
> 
> But not everybody got the memo[1] :P
> 
> I think it worth considering if we want to make large folio adoption
> smoother.
> 
> [1] https://www.reddit.com/r/bcachefs/comments/1vepk4a/comment/p1sn4v1/

Since I'm an idiot, I'm not inclined to be helpful.  But I think my
proposal does fix this; we call page_mkwrite() for each page fault and
then the filesystem knows which pages are actually dirty without having
to be told under the PTL when they can't reserve space.