From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Rik van Riel <riel@surriel.com>, linux-kernel@vger.kernel.org
Cc: kernel-team@meta.com, Andrew Morton <akpm@linux-foundation.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 0/8] batch lookups in follow_page_mask()
Date: Wed, 12 Aug 2026 13:41:13 +0200 [thread overview]
Message-ID: <5d91760e-79e6-4bb7-9c41-52d8ab17ee82@kernel.org> (raw)
In-Reply-To: <20260811025157.1632867-1-riel@surriel.com>
On 8/11/26 04:51, Rik van Riel wrote:
> follow_page_mask() walks the page tables one page at a time, even when the
> caller asked for a whole run of contiguous pages. Every page of a large folio
> re-enters the pmd/pud/pte walk and re-takes the page table lock.
>
> This series changes follow_page_mask() to return a page count and a fill an
> array of pages, instead of a single struct page, so a walker can hand back
> more than one page per call.
>
> Patches 1 to 4 are preparation, no functional change:
>
> 1: move __get_user_pages()'s open-coded pages[] fill and cache flush into a
> gup_fill_pages() helper, which the rest of the series reuses.
> 2: convert the follow_page_mask()/follow_p4d_mask()/follow_pud_mask()/
> follow_pmd_mask()/follow_page_pte() call chain to return a long instead of
> a struct page pointer or ERR_PTR(). Every path still handles one page.
> 3: split the "commit to a resolved page" tail of follow_page_pte() into
> follow_page_pte_commit().
> 4: split the "work out which page this PTE maps" half of follow_page_pte()
> into follow_one_pte(), leaving one unlock and one exit.
>
> Patch 5 has the huge page paths store the page and leave the array fill to
> follow_pud_mask()/follow_pmd_mask() after they unlock, so the cache flushes
> happen outside the pud/pmd critical section.
>
> Patch 6 has follow_huge_pud()/follow_huge_pmd() report the huge page's real
> subpage count instead of a separate *page_mask output, and retires *page_mask
> and __get_user_pages()'s try_grab_folio() call and subpage loop.
>
> Patch 7 walks every PTE in a page table in one follow_page_pte() call instead
> of one per page.
>
> Patch 8 adds follow_pte_batch() so a contiguous same-folio run is committed
> with one refcount grab. This is the only patch whose benefit depends on folio
> size; patch 7 alone covers plain base pages.
>
> Patches 7 and 8 carry their own benchmark tables, both measured against the
> base of the series, so the split between the two mechanisms is visible: the
> single-call walk is worth 2.3x on base pages and 2.2x on 64 kB mTHP, and
> refcount batching adds a further 5.9x on the mTHP case.
>
> v3:
> - split up the series into 8 much smaller patches (David & Lorenzo)
> - shorten changelogs where they were too long (Lorenzo)
> - fix FOLL_WRITE folio dirtying by gathering dirty bits from all PTEs
I'll try getting to this soon. As I raised previously, the whole follow_page_*
terminology is just stale, and likely we should just not add new functions that
use this terminology.
I.e., follow_page_pte_commit()
--
Cheers,
David
prev parent reply other threads:[~2026-08-12 11:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 2:51 [RFC PATCH v3 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() Rik van Riel
2026-08-12 11:50 ` David Hildenbrand (Arm)
2026-08-12 13:02 ` Rik van Riel
2026-08-12 13:23 ` David Hildenbrand (Arm)
2026-08-12 16:19 ` Rik van Riel
2026-08-21 17:38 ` Rik van Riel
2026-08-21 22:04 ` John Hubbard
2026-08-11 2:51 ` [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-08-11 2:51 ` [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-08-12 11:41 ` David Hildenbrand (Arm) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d91760e-79e6-4bb7-9c41-52d8ab17ee82@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=riel@surriel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.