Re: [PATCH] mm/huge_memory: transfer the pmd dirty bit to the folio on zap

On Fri, Aug 21, 2026 at 12:53:34AM +0800, Lance Yang wrote:
> 
> >For some context: we were discussing (off-list) the recent report that
> >systemd-journald had horrible write amplification, worsed quite a bit
> >by large folios. At the moment, there is quite a lot of write amplification,
> >but _only_ on mmap writes (if you look at the write(2) paths, you'll see
> >write_begin and write_end which tactically only dirty what you actually wrote
> >to, block-wise in the BHs or iomap IFS). This doesn't need to be true.
> >
> >What we conjured up was the following: since WP faults always happen on PTEs,
> >you can simply dirty the block(s) corresponding to that particular PTE (which
> >naturally points to a page inside the folio, whether it is large or not, doesn't
> >matter). That way, you can avoid fully dirtying the folio's blocks. This is
> >something that ATM isn't done by any filesystem, but it really should.
> >
> >Obviously this whole idea is thwarted if we keep writable shared file folios
> >PMD-mapped - you can't get meaningful write notifications apart from "someone
> >wrote to this folio", which isn't particularly useful once folios get 2M+ large.
> >So PMD-mapping on a shared-write fault is antithetical to getting useful,
> >granular write notifications to filesystems.
> 
> Just checking I got it right ... for a PMD-order file folio:
> 
> read-only mapping  -> PMD-mapped
> writable mapping   -> PTE-mapped
> 
> Then ->page_mkwrite() could dirty only blocks corresponding to faulting
> PTE, avoiding whole-folio write amplification.

Yes. To be clear, when I said "mapping" I meant "page table (PTE/PMD) entry".
So something like an mmap(PROT_WRITE, MAP_SHARED) could have PMD-mapped folios,
until you actually wrote to them (otherwise they're wp'd and huge-PMD-mapped).

-- 
Pedro