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

[Jan Kara]

On Wed 16-09-26 18:19:29, Matthew Wilcox wrote:
> 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.

Well, learning about write-fault of each page is certainly a simpler model
for filesystems to deal with. What Kirill currently does is that the fs
learns about write-fault of the whole folio (so it prepares space for it)
but then dirtying happens only for some pages (so under the rest of the
folio just remain unwritten extents / delalloc reservations). Filesystems
can accommodate that although it will currently somewhat upset ext4's
delayed allocation reservation system. We will have there unreclaimable
in-memory extents tracking these reservations and on inode eviction we'll
complain they were never used.

What might get ugly with current Kirill's approach is if some simpler
filesystem doesn't have a concept of unwritten extents and delayed
allocation (like old ext2 or vfat) but still allocates blocks in
.page_mkwrite to make sure we don't hit ENOSPC / EDQUOT during writeback.
Then it implicitely relies on current MM behavior of calling .page_mkwrite
only on pages that cannot be evicted without writeback - if the eviction
happens, we've just exposed uninitialized on disk data. In fact this is
what would happen with current ext4 when you turn off delalloc and have old
indirect-block based inode format, except that ext4 is careful enough to
dirty all the buffers underlying the folio (and the folio itself) on its
own so there's no data exposure, we just loose Kirill's optimization.

So overall I don't find unsolvable issues with this but it will certainly
require some tweaking on fs side.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR