Re: [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab

[Rik van Riel <riel@surriel.com>]

On Mon, 2026-10-19 at 02:26 +0800, Yuan-Hao Hsu wrote:
> On Mon, 10 Aug 2026 22:51:57 -0400, Rik van Riel wrote:
> > Add follow_pte_batch() and give follow_page_pte_commit() a run
> > length.
> > Each run starts with a full per-PTE resolve, then
> > follow_pte_batch()
> > finds how many more PTEs extend it with a pte_same() scan rather
> > than a
> > re-derivation of each page, and the run is committed with one
> > refcount
> > grab. Runs stop at folio boundaries, so plain base pages are
> > unaffected.
> 
> One side effect worth a sentence in the changelog: with FOLL_TOUCH,
> folio_mark_accessed() now runs once per run instead of once per page.
> On the classic LRU the first call only sets PG_referenced and the
> second one activates the folio, so the old per-page loop activated a
> PTE-mapped large folio from its second page on, and a run now leaves
> it referenced but inactive.
> 
> Measured with one get_user_pages() call over 2 MB of freshly faulted
> 64 kB folios (kprobe on folio_mark_accessed(), flags from
> /proc/kpageflags):
> 
>                        before            after
>   folio_mark_accessed  512 per call      32 per call
>   after 1st call       32 folios active  32 referenced, 0 active
>   after 2nd call       32 active         32 active
> 
> That matches what the other two paths already do (follow_huge_pmd()
> only calls touch_pmd(), GUP-fast only calls folio_set_referenced()),
> so it looks like the right outcome.  It is still a visible change in
> aging for anything that reaches these folios through get_user_pages()
> rather than the fast path.
> 
Nice catch.

You are right that this should be in the changelog!

I'll get that in for v4.


-- 
All Rights Reversed.