Re: [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab
From: Rik van Riel
Date: Sun Oct 18 2026 - 17:04:57 EST
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.