[PATCH v3 00/19] mm: Refactor bootmem gigantic hugepage allocation

Muchun Song posted 19 patches 5 days, 16 hours ago
arch/powerpc/mm/book3s64/radix_pgtable.c |   7 +-
arch/powerpc/mm/hugetlbpage.c            |  13 +-
include/linux/hugetlb.h                  |  24 +--
include/linux/mmzone.h                   |   7 -
mm/cma.c                                 |   3 +-
mm/hugetlb.c                             | 259 +++++++++++------------
mm/hugetlb_cma.c                         |  44 ++--
mm/hugetlb_cma.h                         |   8 +-
mm/hugetlb_vmemmap.c                     |  94 ++------
mm/hugetlb_vmemmap.h                     |   5 -
mm/internal.h                            |  14 +-
mm/mm_init.c                             |  88 +++-----
mm/sparse-vmemmap.c                      |  26 ++-
mm/sparse.c                              |  48 +----
14 files changed, 241 insertions(+), 399 deletions(-)
[PATCH v3 00/19] mm: Refactor bootmem gigantic hugepage allocation
Posted by Muchun Song 5 days, 16 hours ago
This series is split out from the earlier larger series "mm: Generalize
HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of
that series as a standalone set of fixes and preparatory cleanups around
bootmem HugeTLB handling, sparse initialization ordering, and related
vmemmap setup.

The first patches fix a few bugs found while reviewing the existing
code, including incorrect bootmem HVO handling, wrong vmemmap
registration arguments, a powerpc compound-vmemmap tracking bug, and
too-late initialization of gigantic bootmem HugeTLB struct pages.

The rest of the series reorders early memory initialization so the
relevant zone state is available before sparse and HugeTLB boot-time
setup runs, then simplifies the remaining bootmem gigantic hugepage
allocation path and removes code made obsolete by that rework.

At a high level:
  - patches [1-4] fix boot-time and arch-specific bugs
  - patches [5-12] reorder and simplify sparse/mm/hugetlb early init
  - patches [13-19] refactor bootmem gigantic hugepage allocation and
    remove obsolete helpers and state

Changes since v2:
  - patch 1: add a comment explaining why shared tail pages must be
    initialized from gather_bootmem_prealloc() before
    hugetlb_vmemmap_init() runs
  - patch 1: update the stale sparse-vmemmap comment to point to
    gather_bootmem_prealloc() as the shared-tail initialization site
  - patch 2: collect Acked-by from Oscar Salvador
  - patch 19: fold __init_page_from_nid() into __init_deferred_page()
    instead of only making it static

[1] https://lore.kernel.org/linux-mm/20260513130542.35604-1-songmuchun@bytedance.com/

Muchun Song (19):
  mm/hugetlb: Fix boot panic with CONFIG_DEBUG_VM and HVO bootmem pages
  mm/hugetlb_vmemmap: Fix __hugetlb_vmemmap_optimize_folios()
  powerpc/mm: Fix wrong addr_pfn tracking in compound vmemmap population
  mm/hugetlb: Initialize gigantic bootmem hugepage struct pages earlier
  mm/mm_init: Simplify deferred_free_pages() migratetype init
  mm/sparse: Panic on memmap and usemap allocation failure
  mm/sparse: Move subsection_map_init() into sparse_init()
  mm/mm_init: Defer sparse_init() until after zone initialization
  mm/mm_init: Defer hugetlb reservation until after zone initialization
  mm/mm_init: Remove set_pageblock_order() call from sparse_init()
  mm/sparse: Move sparse_vmemmap_init_nid_late() into sparse_init_nid()
  mm/hugetlb_cma: Validate hugetlb CMA range by zone at reserve time
  mm/hugetlb: Refactor early boot gigantic hugepage allocation
  mm/hugetlb: Free cross-zone bootmem gigantic pages after allocation
  mm/hugetlb_vmemmap: Move bootmem HVO setup to early init
  mm/hugetlb: Remove obsolete bootmem cross-zone checks
  mm/sparse-vmemmap: Remove sparse_vmemmap_init_nid_late()
  mm/hugetlb: Remove unused bootmem cma field
  mm/mm_init: Fold __init_page_from_nid() into __init_deferred_page()

 arch/powerpc/mm/book3s64/radix_pgtable.c |   7 +-
 arch/powerpc/mm/hugetlbpage.c            |  13 +-
 include/linux/hugetlb.h                  |  24 +--
 include/linux/mmzone.h                   |   7 -
 mm/cma.c                                 |   3 +-
 mm/hugetlb.c                             | 259 +++++++++++------------
 mm/hugetlb_cma.c                         |  44 ++--
 mm/hugetlb_cma.h                         |   8 +-
 mm/hugetlb_vmemmap.c                     |  94 ++------
 mm/hugetlb_vmemmap.h                     |   5 -
 mm/internal.h                            |  14 +-
 mm/mm_init.c                             |  88 +++-----
 mm/sparse-vmemmap.c                      |  26 ++-
 mm/sparse.c                              |  48 +----
 14 files changed, 241 insertions(+), 399 deletions(-)


base-commit: 08484c504b55a98bd100527fbe10a3caf55ff3ff
-- 
2.54.0
Re: [PATCH v3 00/19] mm: Refactor bootmem gigantic hugepage allocation
Posted by Oscar Salvador (SUSE) 5 days, 15 hours ago
On Tue, Jun 02, 2026 at 06:10:20PM +0800, Muchun Song wrote:
> This series is split out from the earlier larger series "mm: Generalize
> HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of
> that series as a standalone set of fixes and preparatory cleanups around
> bootmem HugeTLB handling, sparse initialization ordering, and related
> vmemmap setup.

Thanks Munchun, this split out really helps easing the review.
I think not so many patches from this series scaped review, but I shall
get back ot it later this week.

 

-- 
Oscar Salvador
SUSE Labs
Re: [PATCH v3 00/19] mm: Refactor bootmem gigantic hugepage allocation
Posted by Muchun Song 5 days, 14 hours ago

> On Jun 2, 2026, at 18:34, Oscar Salvador (SUSE) <osalvador@kernel.org> wrote:
> 
> On Tue, Jun 02, 2026 at 06:10:20PM +0800, Muchun Song wrote:
>> This series is split out from the earlier larger series "mm: Generalize
>> HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of
>> that series as a standalone set of fixes and preparatory cleanups around
>> bootmem HugeTLB handling, sparse initialization ordering, and related
>> vmemmap setup.

Hi Oscar,

> 
> Thanks Munchun, this split out really helps easing the review.
> I think not so many patches from this series scaped review, but I shall
> get back ot it later this week.

Sounds good! Thanks for taking the time to review. Looking forward to your
feedback later this week.

Best,
Muchun

> 
> 
> 
> -- 
> Oscar Salvador
> SUSE Labs