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

On Tue, Aug 25, 2026 at 10:04:31AM +0200, David Hildenbrand (Arm) wrote:
> On 8/25/26 07:59, Christoph Hellwig wrote:
> > On Thu, Aug 20, 2026 at 03:10:11PM +0100, Pedro Falcato wrote:
> >>> Why? Write batching from large folios is a win.
> >>
> >> 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.
> > 
> > So don't use mmap to write to storage.  That is always a bad idea for
> > many, many reasons.  We should not work around broken applications that
> > do this, but change them.  It only took about 10 years of bad reputation
> > for MongoDB to finally fix their act, so it should be possible for
> > systemd as well.

That is true. However, I don't think that should stop us from providing
reasonable semantics for those that use mmap.

Fundamentally:
 - For the common, PTE-level case: we get the granularity for free, the
filesystem only needs to be notified accordingly.
 - For the less common, PMD-level case: we already aggressively break these
down on mkwrite faults; I think doing this is the right tradeoff. Screw the TLB
in that case :)

And, frankly, half of the problem (and related to the GUP thread) is that
page_mkwrite is a crap interface... Something like ->write_begin() being
generalised to more than read(2)/write(2) could possibly solve most of these
issues (or a ranged dirty_folio).

> 
> I was in contact with systemd folks (and pulled in Willy and Jan) regarding
> that, and nothing should really block that.

Awesome!

-- 
Pedro