Re: [PATCH] mm/memory: reuse the whole exclusive large folio on a write fault

[Yuan-Hao Hsu <aa9736195201@gmail.com>]

On Sat, 19 Sep 2026 07:48:00 +0800, Barry Song wrote:
> I'm fine with your follow-up work, but I'd appreciate it if you could
> mention the previous work and include the link in your changelog, along
> with an explanation of how you address David's concerns.

Will do in v2.

> I think a major concern is that we may spend too much time scanning
> PTEs to determine whether we can batch them. If we don't support
> CONT-PTE, we may simply scan fewer PTEs; if we do support CONT-PTE, we
> may end up scanning more PTEs. So we need to show that the scanning
> cost is controlled and explain how it is bounded.

The walk stays within the folio, the VMA and the page table, so it
touches at most the PTEs that map this folio in this page table: 16
for a 64K folio, PTRS_PER_PTE (512 with 4K pages) at the most.  Each
PTE is read once by folio_pte_batch_flags(), the same scan fork() and
mprotect() already run over these PTEs.

Measured, that is 14-20 ns per PTE.  For 512 PTEs the fault takes
10 us, 1 us of it the scan, the rest marking the pages exclusive and
writing the PTEs.  Those are PTEs that would otherwise each take a
420 ns fault.  The pattern where the work is wasted, one store per
folio, is the one the description gives the numbers for.

> I also personally feel that both the changelog and the code are too
> long to read. Could we somehow split the changes into smaller pieces
> and describe how each of those concerns is addressed at a finer
> granularity?

Yes, and sorry for the wall of text.  v2 is two patches: 1/2 handles
an aligned block of 16 PTEs, the contpte-sized version David was fine
with in 2024; 2/2 lifts that to the folio.  Each has its own numbers,
the earlier discussion is linked, and the changelogs are cut to what
is needed to judge the change.