From: Lance Yang <lance.yang@linux.dev>
To: songmuchun@bytedance.com
Cc: osalvador@suse.de, akpm@linux-foundation.org, rppt@kernel.org,
qi.zheng@linux.dev, lance.yang@linux.dev, jthoughton@google.com,
david@kernel.org, muchun.song@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/12] mm: hugetlb_vmemmap: simplify shared tail page handling
Date: Fri, 23 Oct 2026 10:20:27 +0800 [thread overview]
Message-ID: <20261023022027.25898-1-lance.yang@linux.dev> (raw)
In-Reply-To: <20261020115824.823278-6-songmuchun@bytedance.com>
On Tue, Oct 20, 2026 at 07:58:19PM +0800, Muchun Song wrote:
>The remap walker currently carries a shared tail page selected by its
>caller, even though the optimize and restore callbacks can derive the
>same information from the folio being processed. This adds redundant
>state to the walker and couples its interface to caller-side preparation.
>
>Derive the shared mapping state in the callbacks instead, keeping the
>mapping policy with the PTE being processed and simplifying the remap
>interface.
>
>No functional change intended.
>
>Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>---
> include/linux/vmemmap-optimization.h | 6 +-
> mm/hugetlb_vmemmap.c | 89 ++++++++++++----------------
> mm/mm_init.c | 6 +-
> mm/sparse-vmemmap.c | 5 +-
> 4 files changed, 49 insertions(+), 57 deletions(-)
>
>diff --git a/include/linux/vmemmap-optimization.h b/include/linux/vmemmap-optimization.h
>index 065840f3c241..858311a71b0c 100644
>--- a/include/linux/vmemmap-optimization.h
>+++ b/include/linux/vmemmap-optimization.h
>@@ -91,11 +91,13 @@ static inline struct page *vmemmap_shared_tail_page(unsigned int order,
> }
> #endif /* CONFIG_VMEMMAP_OPTIMIZATION */
>
>-static inline bool vmemmap_optimizable_pfn(unsigned long pfn)
>+static inline bool vmemmap_optimizable_pfn(unsigned long pfn, unsigned int order)
> {
>- const unsigned int order = pfn_to_section_compound_order(pfn);
> const unsigned long nr_pages = 1UL << order;
>
>+ if (!IS_ENABLED(CONFIG_VMEMMAP_OPTIMIZATION))
>+ return false;
>+
> if (!is_power_of_2(sizeof(struct page)))
> return false;
>
>diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>index 18b72d553955..8fac61b7d74a 100644
>--- a/mm/hugetlb_vmemmap.c
>+++ b/mm/hugetlb_vmemmap.c
>@@ -24,22 +24,18 @@
> * struct vmemmap_remap_walk - walk vmemmap page table
> *
> * @remap_pte: called for each lowest-level entry (PTE).
>- * @nr_walked: the number of walked pte.
>- * @vmemmap_tail: the page to be installed as non-first in the vmemmap range
>+ * @nr_walked: the number of PTEs successfully remapped.
> * @vmemmap_pages: the list head of the vmemmap pages that can be freed
> * or is mapped from.
> * @flags: used to modify behavior in vmemmap page table walking
> * operations.
> */
> struct vmemmap_remap_walk {
>- void (*remap_pte)(pte_t *pte, unsigned long addr,
>+ int (*remap_pte)(pte_t *pte, unsigned long addr,
> struct vmemmap_remap_walk *walk);
>-
> unsigned long nr_walked;
>- struct page *vmemmap_tail;
> struct list_head *vmemmap_pages;
>
>-
> /* Skip the TLB flush while updating the vmemmap page tables. */
> #define VMEMMAP_REMAP_NO_TLB_FLUSH BIT(0)
> unsigned long flags;
>@@ -140,12 +136,14 @@ static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr,
> static int vmemmap_pte_entry(pte_t *pte, unsigned long addr,
> unsigned long next, struct mm_walk *walk)
> {
>+ int ret;
> struct vmemmap_remap_walk *vmemmap_walk = walk->private;
>
>- vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
>- vmemmap_walk->nr_walked++;
>+ ret = vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
>+ if (!ret)
>+ vmemmap_walk->nr_walked++;
>
>- return 0;
>+ return ret;
> }
>
> static const struct mm_walk_ops vmemmap_remap_ops = {
>@@ -213,51 +211,51 @@ static struct page *vmemmap_dup_page_from_list(const struct page *src,
> return dst;
> }
>
>-static void vmemmap_optimize_pte(pte_t *pte, unsigned long addr,
>- struct vmemmap_remap_walk *walk)
>+static inline struct page *folio_vmemmap_shared_tail_page(const struct folio *folio)
> {
>- struct page *page = pte_page(ptep_get(pte));
>- pte_t entry;
>-
>- /* Remapping the head page requires r/w */
>- if (unlikely(walk->nr_walked == 0)) {
>- struct page *head;
>+ return vmemmap_shared_tail_page(folio_order(folio), folio_zone(folio));
>+}
>
>- VM_WARN_ON_ONCE(!PageHead((const struct page *)addr));
>+static int vmemmap_optimize_pte(pte_t *pte, unsigned long addr,
>+ struct vmemmap_remap_walk *walk)
>+{
>+ pte_t entry;
>+ struct page *src = pte_page(ptep_get(pte)), *dst;
>+ const struct page *page = (const struct page *)addr;
>+ const struct folio *folio = page_folio(page);
>
>- head = vmemmap_dup_page_from_list(page, walk->vmemmap_pages);
>- entry = mk_pte(head, PAGE_KERNEL);
>+ if (likely(vmemmap_optimizable_pfn(page_to_pfn(page), folio_order(folio)))) {
>+ dst = folio_vmemmap_shared_tail_page(folio);
>+ if (!dst)
>+ return -ENOMEM;
One thing caught my eye here ... shared tail allocation can now fail after
we've already remapped the head.
IIUC, nothing to worry about there, though :) since rollback keeps the
new head mapped and flushes before clearing the optimized flag or freeing
the old backing page.
[...]
Reviewed-by: Lance Yang <lance.yang@linux.dev>
next prev parent reply other threads:[~2026-10-23 2:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 11:52 [PATCH 00/12] mm: Decouple folio-based vmemmap optimization from HugeTLB Muchun Song
2026-10-20 11:52 ` [PATCH 01/12] mm: hugetlb_vmemmap: remove HugeTLB-specific vmemmap optimization macros Muchun Song
2026-10-22 3:43 ` Lance Yang
2026-10-20 11:58 ` [PATCH 02/12] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Muchun Song
2026-10-20 11:58 ` [PATCH 03/12] mm: hugetlb_vmemmap: simplify vmemmap head page handling Muchun Song
2026-10-22 6:24 ` Lance Yang
2026-10-22 6:27 ` Muchun Song
2026-10-22 7:23 ` Lance Yang
2026-10-20 11:58 ` [PATCH 04/12] mm: hugetlb_vmemmap: generalize vmemmap page allocation Muchun Song
2026-10-22 13:54 ` Lance Yang
2026-10-20 11:58 ` [PATCH 05/12] mm: hugetlb_vmemmap: unify writable vmemmap page preparation Muchun Song
2026-10-22 14:13 ` Lance Yang
2026-10-20 11:58 ` [PATCH 06/12] mm: hugetlb_vmemmap: rename vmemmap_remap_pte() to vmemmap_optimize_pte() Muchun Song
2026-10-23 0:55 ` Lance Yang
2026-10-20 11:58 ` [PATCH 07/12] mm: hugetlb_vmemmap: simplify shared tail page handling Muchun Song
2026-10-23 2:20 ` Lance Yang [this message]
2026-10-23 2:32 ` Muchun Song
2026-10-20 11:58 ` [PATCH 08/12] mm: hugetlb_vmemmap: move alloc_vmemmap_page_list() next to its free helper Muchun Song
2026-10-23 2:47 ` Lance Yang
2026-10-20 11:58 ` [PATCH 09/12] mm: hugetlb_vmemmap: make vmemmap optimization folio-oriented Muchun Song
2026-10-23 3:39 ` Lance Yang
2026-10-20 11:58 ` [PATCH 10/12] mm: hugetlb_vmemmap: make vmemmap restoration folio-oriented Muchun Song
2026-10-23 3:46 ` Lance Yang
2026-10-23 3:58 ` Muchun Song
2026-10-20 11:58 ` [PATCH 11/12] mm: hugetlb_vmemmap: unify vmemmap range restoration Muchun Song
2026-10-23 3:53 ` Lance Yang
2026-10-20 11:58 ` [PATCH 12/12] mm: hugetlb_vmemmap: make vmemmap PTE conversion folio-oriented Muchun Song
2026-10-22 3:52 ` [PATCH 02/12] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Lance Yang
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=20261023022027.25898-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jthoughton@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®