From: Muchun Song <songmuchun@bytedance.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Oscar Salvador <osalvador@suse.de>,
Mike Rapoport <rppt@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Muchun Song <muchun.song@linux.dev>,
James Houghton <jthoughton@google.com>,
Lance Yang <lance.yang@linux.dev>, Qi Zheng <qi.zheng@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>
Subject: [PATCH 06/11] mm/hugetlb: initialize all struct pages for bootmem hugepages
Date: Mon, 9 Nov 2026 17:58:01 +0800 [thread overview]
Message-ID: <20261109095807.41547-7-songmuchun@bytedance.com> (raw)
In-Reply-To: <20261109095807.41547-1-songmuchun@bytedance.com>
Boot-time gigantic hugepages currently leave the head struct page to
the generic memmap initialization path while the HugeTLB code
initializes the remaining struct pages itself.
Mark the full hugepage noinit and initialize the head struct page in
hugetlb_folio_init_vmemmap() as well, so the whole compound-page setup
is handled in one place.
This can also reduce memblock metadata overhead when many boot-time
HugeTLB pages are reserved, because physically contiguous hugepages
can be covered by fewer noinit regions.
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
mm/hugetlb.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ff6f837b6df0..d2aaad235458 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3216,15 +3216,7 @@ static bool __init alloc_bootmem_huge_page(struct hstate *h, int nid)
list_add_tail(&m->list, &huge_boot_pages[nid]);
m->flags |= HUGE_BOOTMEM_ZONES_VALID;
hugetlb_vmemmap_optimize_bootmem_page(pfn, huge_page_order(h));
- /*
- * Only initialize the head struct page in memmap_init_reserved_pages,
- * rest of the struct pages will be initialized by the HugeTLB
- * subsystem itself.
- * The head struct page is used to get folio information by the HugeTLB
- * subsystem like zone id and node id.
- */
- memblock_reserved_mark_noinit(__pa((void *)m + PAGE_SIZE),
- huge_page_size(h) - PAGE_SIZE);
+ memblock_reserved_mark_noinit(__pa(m), huge_page_size(h));
}
return true;
@@ -3255,22 +3247,23 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
}
static void __init hugetlb_folio_init_vmemmap(struct folio *folio,
+ unsigned long pfn,
struct hstate *h,
+ enum zone_type zone, int nid,
unsigned long nr_pages)
{
- int ret;
+ struct page *head = &folio->page;
/*
* This is an open-coded prep_compound_page() whereby we avoid
* walking pages twice by initializing/preparing+freezing them in the
* same go.
*/
- __folio_clear_reserved(folio);
+ __init_single_page(head, pfn, zone, nid);
__folio_set_head(folio);
- ret = folio_ref_freeze(folio, 1);
- VM_BUG_ON(!ret);
+ set_page_count(head, 0);
hugetlb_folio_init_tail_vmemmap(folio, h, 1, nr_pages);
- prep_compound_head(&folio->page, huge_page_order(h));
+ prep_compound_head(head, huge_page_order(h));
}
/*
@@ -3328,8 +3321,9 @@ static void __init gather_bootmem_prealloc_node(unsigned long nid)
list_for_each_entry_safe(m, tm, &huge_boot_pages[nid], list) {
struct page *page = virt_to_page(m);
struct folio *folio = (void *)page;
- const unsigned long pfn = folio_pfn(folio);
+ const unsigned long pfn = PHYS_PFN(__pa(m));
const unsigned long nr_pages = pages_per_huge_page(m->hstate);
+ const enum zone_type zone = zone_idx(pfn_to_zone(pfn, nid));
unsigned long nr_struct_pages = nr_pages;
h = m->hstate;
@@ -3342,11 +3336,10 @@ static void __init gather_bootmem_prealloc_node(unsigned long nid)
prev_h = h;
VM_BUG_ON(!hstate_is_gigantic(h));
- WARN_ON(folio_ref_count(folio) != 1);
if (vmemmap_optimizable_order(pfn_to_section_compound_order(pfn)))
nr_struct_pages = VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES;
- hugetlb_folio_init_vmemmap(folio, h, nr_struct_pages);
+ hugetlb_folio_init_vmemmap(folio, pfn, h, zone, nid, nr_struct_pages);
init_new_hugetlb_folio(folio);
if (vmemmap_optimizable_order(pfn_to_section_compound_order(pfn)))
--
2.54.0
next prev parent reply other threads:[~2026-11-09 9:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 9:57 [PATCH 00/11] mm: Unify memmap initialization for compound pages Muchun Song
2026-11-09 9:57 ` [PATCH 01/11] mm/mm_init: verify zones for template-initialized pages Muchun Song
2026-11-09 9:57 ` [PATCH 02/11] mm/mm_init: factor out common struct page initialization Muchun Song
2026-11-09 9:57 ` [PATCH 03/11] mm/mm_init: simplify zone device " Muchun Song
2026-11-09 9:57 ` [PATCH 04/11] mm/mm_init: factor out frozen compound " Muchun Song
2026-11-09 9:58 ` [PATCH 05/11] mm/hugetlb: drop boot-time HVO handling for gigantic folios Muchun Song
2026-11-09 9:58 ` Muchun Song [this message]
2026-11-09 9:58 ` [PATCH 07/11] mm/hugetlb: use common compound page initialization helper Muchun Song
2026-11-09 9:58 ` [PATCH 08/11] mm/mm_init: make __init_single_page() static Muchun Song
2026-11-09 9:58 ` [PATCH 09/11] mm/cma: centralize CMA pageblock initialization Muchun Song
2026-11-09 9:58 ` [PATCH 10/11] mm/cma: localize init_cma_pageblock() to cma.c Muchun Song
2026-11-09 9:58 ` [PATCH 11/11] mm/mm_init: move pageblock migratetype init to memmap helpers Muchun Song
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=20261109095807.41547-7-songmuchun@bytedance.com \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jthoughton@google.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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®