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);
}
_
prev 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®