Re: Removing ->dirty_folio

[Christoph Hellwig <hch@lst.de>]

On Tue, Aug 25, 2026 at 08:26:56PM +0100, Matthew Wilcox wrote:
> > >     ->page_mkdirty() had been called again for each page in the folio is
> > >     marked as dirty.
> > 
> > This may make COW more complex.
> 
> It's probably wise to be explicit when talking about COW.  Anyone from
> the MM side of the house is probably thinking "but this is only relevant
> for shared writable mmap and we don't do a COW".  You're talking about
> filesystems doing a COW of the on-disc data, not about the MM COWing the
> pagecache page into an anonymous page.

Heh.  There's way too many COWs around (says that one on vacation
all around lower case cows).

> > I'm not sure if we will have a good timing for re-reserving space inside
> > btrfs.
> 
> Why is it hard to do it immediately at writeback time?  I think you're
> in an even less restrictive locking environment than page_mkwrite is
> called in because you're not under any MM locks.  According to
> Documentation/filesystems/locking.rst, ->writepages is called with
> absolutely no locks held.

Re-reserving can fail.  So if we want to be fail-safe we need to do
it ahead of time.  Then again as per my other mail we might only
have to do it for long-term pins where the place of dirtying is
explicitly controlled.

> 
> > Would it be possible for MM/VFS layer to trigger page_mkdirty() instead?
> 
> Actually ... no, because the VFS no longer knows which pages in the
> folio are dirty.  That's information the MM had, and communicated to
> the FS which (if it cares) has stored in its folio->private.  But the
> VFS no longer has access to that information.

All of this is quite a mess.  We'd need to allocate it a head of time
to be safe, but for that the file system would have to manage
multiple overlapping reservations for the same region of the file.
Which I don't think anyone does right now.

For RDMA/HMM we might be able to tell the file system ahead of
time with some rework, but none of these good ideas are going to
work for vmsplice.  So the only option is to grab space from
a reserved pool covering the max writeback size, which can be
refilled when freeing them.  Assuming we can actually free them
an no one took a snapshot permanently pinning the old blocks in
the meantime.