mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>

  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®