mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>, Qi Zheng <qi.zheng@linux.dev>,
	Lance Yang <lance.yang@linux.dev>,
	James Houghton <jthoughton@google.com>,
	David Hildenbrand <david@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Yili Zhang <zhangyili01@baidu.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 00/13] mm: Decouple folio-based vmemmap optimization from HugeTLB
Date: Fri, 6 Nov 2026 19:53:02 -0800	[thread overview]
Message-ID: <20261106195302.fd572ac49e52af9e305cbcef@linux-foundation.org> (raw)
In-Reply-To: <20261107022756.77731-1-songmuchun@bytedance.com>

On Sat,  7 Nov 2026 10:27:43 +0800 Muchun Song <songmuchun@bytedance.com> wrote:

> Hi,
> 
> Section-based vmemmap optimization is implemented in sparse-vmemmap.c,
> while folio-based optimization currently lives in hugetlb_vmemmap.c.
> The latter is tightly coupled to HugeTLB-specific state even though the
> underlying page-table remapping operates on one folio at a time.
> 
> To make these interfaces easier to maintain, the folio-based remapping
> mechanics first need a boundary that is independent of HugeTLB-specific
> state and raw address ranges. This will allow the mechanics to be moved
> into a common vmemmap optimization layer alongside the section-based
> interface.
> 
> This series establishes that boundary through three folio-oriented
> operations, each with a distinct role:
> 
>   - vmemmap_optimize_folio() optimizes the vmemmap backing of a folio;
>   - vmemmap_restore_folio() restores the vmemmap backing of a folio; and
>   - vmemmap_pteify_folio() converts the vmemmap backing of a folio to
>     PTE mappings.
> 
> Together, these operations encapsulate the address-range calculation and
> remapping mechanics for a folio. HugeTLB wrappers retain policy decisions
> such as eligibility, optimized state, batching and TLB flush handling.

Thanks, I've update mm.git's mm-unstable branch to this version.

> v4:
> - Rebase onto mm/mm-new at f735a2c21aa9
> - Split the HVO head-page allocation fix into a standalone prerequisite
>   and retain Yili Zhang as its author
> - Add __GFP_NOWARN and pass caller-selected GFP masks through the
>   generalized allocator and folio-oriented helpers
> - Propagate alloc_vmemmap_page_list() errors directly (suggested by Oscar
>   Salvador)
> - Remove the redundant order check from vmemmap_pteify_folio() (suggested
>   by Oscar Salvador)
> - Collect Reviewed-by tags from Oscar Salvador and Mike Rapoport
> - Collect Tested-by from Andrew Morton

Here's how v4 altered mm.git:


 mm/hugetlb_vmemmap.c |   32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

--- a/mm/hugetlb_vmemmap.c~b
+++ a/mm/hugetlb_vmemmap.c
@@ -198,13 +198,13 @@ static void free_vmemmap_page_list(struc
 }
 
 static int alloc_vmemmap_page_list(struct list_head *head,
-		unsigned int nr_pages, int nid)
+		unsigned int nr_pages, int nid, gfp_t gfp_mask)
 {
-	LIST_HEAD(new_pages);
 	struct page *page, *next;
+	LIST_HEAD(new_pages);
 
 	for (unsigned int i = 0; i < nr_pages; i++) {
-		page = alloc_pages_node(nid, GFP_KERNEL | __GFP_RETRY_MAYFAIL, 0);
+		page = alloc_pages_node(nid, gfp_mask | __GFP_RETRY_MAYFAIL, 0);
 		if (!page)
 			goto free_pages;
 		list_add(&page->lru, &new_pages);
@@ -312,14 +312,11 @@ static inline int vmemmap_restore_range(
  */
 static int vmemmap_pteify_folio(const struct folio *folio, unsigned long flags)
 {
+	unsigned long start = (unsigned long)folio_page(folio, 0);
+	unsigned long end = start + folio_vmemmap_size(folio);
 	struct vmemmap_remap_walk walk = {
 		.flags		= flags,
 	};
-	unsigned long start = (unsigned long)folio_page(folio, 0);
-	unsigned long end = start + folio_vmemmap_size(folio);
-
-	if (!vmemmap_optimizable_order(folio_order(folio)))
-		return -EOPNOTSUPP;
 
 	return vmemmap_remap_range(start, end, &walk);
 }
@@ -341,9 +338,10 @@ static int vmemmap_pteify_folio(const st
 static int vmemmap_optimize_folio(const struct folio *folio,
 		struct list_head *vmemmap_pages, unsigned long flags)
 {
-	int ret, nid = folio_nid(folio);
 	unsigned long start = (unsigned long)folio_page(folio, 0);
 	unsigned long end = start + folio_vmemmap_size(folio);
+	gfp_t gfp_mask = GFP_KERNEL | __GFP_NOWARN;
+	int ret, nid = folio_nid(folio);
 	struct vmemmap_remap_walk walk = {
 		.remap_pte	= vmemmap_optimize_pte,
 		.vmemmap_pages	= vmemmap_pages,
@@ -355,8 +353,10 @@ static int vmemmap_optimize_folio(const
 	if (!vmemmap_optimizable_order(folio_order(folio)))
 		return -EOPNOTSUPP;
 
-	if (alloc_vmemmap_page_list(vmemmap_pages, VMEMMAP_OPTIMIZATION_PAGES, nid))
-		return -ENOMEM;
+	ret = alloc_vmemmap_page_list(vmemmap_pages, VMEMMAP_OPTIMIZATION_PAGES,
+				      nid, gfp_mask);
+	if (ret)
+		return ret;
 
 	ret = vmemmap_remap_range(start, end, &walk);
 	if (!ret || !walk.nr_walked)
@@ -381,14 +381,16 @@ static int vmemmap_optimize_folio(const
  */
 static int vmemmap_restore_folio(const struct folio *folio, unsigned long flags)
 {
-	LIST_HEAD(vmemmap_pages);
-	int nid = folio_nid(folio);
 	unsigned long start = (unsigned long)folio_page(folio, 0);
 	unsigned long end = start + folio_vmemmap_size(folio);
+	int ret, nid = folio_nid(folio);
+	LIST_HEAD(vmemmap_pages);
 
 	start += VMEMMAP_OPTIMIZATION_SIZE;
-	if (alloc_vmemmap_page_list(&vmemmap_pages, (end - start) / PAGE_SIZE, nid))
-		return -ENOMEM;
+	ret = alloc_vmemmap_page_list(&vmemmap_pages, (end - start) / PAGE_SIZE,
+				      nid, GFP_KERNEL);
+	if (ret)
+		return ret;
 
 	return vmemmap_restore_range(start, end, &vmemmap_pages, flags);
 }
_


      parent reply	other threads:[~2026-11-07  3:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07  2:27 Muchun Song
2026-11-07  2:27 ` [PATCH v4 01/13] mm: hugetlb_vmemmap: fix OOM during head page allocation Muchun Song
2026-11-07  2:27 ` [PATCH v4 02/13] mm: hugetlb_vmemmap: remove HugeTLB-specific vmemmap optimization macros Muchun Song
2026-11-07  2:27 ` [PATCH v4 03/13] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Muchun Song
2026-11-07  2:27 ` [PATCH v4 04/13] mm: hugetlb_vmemmap: simplify vmemmap head page handling Muchun Song
2026-11-07  2:27 ` [PATCH v4 05/13] mm: hugetlb_vmemmap: generalize vmemmap page allocation Muchun Song
2026-11-07  2:27 ` [PATCH v4 06/13] mm: hugetlb_vmemmap: unify writable vmemmap page preparation Muchun Song
2026-11-07  2:27 ` [PATCH v4 07/13] mm: hugetlb_vmemmap: rename vmemmap_remap_pte() to vmemmap_optimize_pte() Muchun Song
2026-11-07  2:27 ` [PATCH v4 08/13] mm: hugetlb_vmemmap: simplify shared tail page handling Muchun Song
2026-11-07  2:27 ` [PATCH v4 09/13] mm: hugetlb_vmemmap: move alloc_vmemmap_page_list() next to its free helper Muchun Song
2026-11-07  2:27 ` [PATCH v4 10/13] mm: hugetlb_vmemmap: make vmemmap optimization folio-oriented Muchun Song
2026-11-07  2:27 ` [PATCH v4 11/13] mm: hugetlb_vmemmap: make vmemmap restoration folio-oriented Muchun Song
2026-11-07  2:27 ` [PATCH v4 12/13] mm: hugetlb_vmemmap: unify vmemmap range restoration Muchun Song
2026-11-07  2:27 ` [PATCH v4 13/13] mm: hugetlb_vmemmap: make vmemmap PTE conversion folio-oriented Muchun Song
2026-11-07  3:53 ` Andrew Morton [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=20261106195302.fd572ac49e52af9e305cbcef@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=jthoughton@google.com \
    --cc=kas@kernel.org \
    --cc=lance.yang@linux.dev \
    --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 \
    --cc=zhangyili01@baidu.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®