Re: [PATCH 0/5] mm: hugetlb: add CMA support for PMD-sized page

[Muchun Song]

> On Oct 16, 2026, at 18:07, Qi Zheng <qi.zheng@xxxxxxxxx> wrote:
> 
> From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> 
> Hi all,
> 
> Allocating PMD-sized HugeTLB pages at runtime can become slow or fail
> as physical memory becomes fragmented. Reserving HugeTLB pages at boot
> avoids this problem, but keeps unused pages unavailable to ordinary
> allocations.
> 
> Live upgrades are one example: they need additional HugeTLB pages only
> during the upgrade. HugeTLB already supports CMA for gigantic pages,
> but reserving a CMA pool for 1 GiB pages can fail when physical KASLR
> and other early reservations leave too few suitable 1 GiB-aligned
> ranges. At runtime, 1 GiB allocations can also fail when pages cannot
> be migrated out of a suitable contiguous range.

Yes, that's our use case at ByteDance. Allocating a 1GB HugeTLB page from
the CMA pool is more prone to failure than allocating a 2MB one. To improve
the probability of successful allocation, we typically configure the CMA
size to be larger than our actual requirement, keeping a certain margin to
handle cases where temporary kernel operations (such as DMA) prevent successful
migration. For 1G HugeTLB pages, since the margin must be an integer multiple
of 1G, the extra memory configured as headroom is also relatively large,
making it less flexible than 2M pages.

> 
> Extend CMA support to PMD-sized pages so their backing memory can be
> reserved at boot while remaining usable for movable allocations until
> needed. This relaxes the reservation alignment requirement and reduces
> the contiguous range required per allocation.
> 
> The series adds an optional @<page-size> suffix to hugetlb_cma and a
> separate PMD-sized pool. For example, on x86-64:
> 
> hugetlb_cma=4G hugetlb_cma=1G@2M

Different sizes of gigantic pages already share a single HugeTLB CMA pool.
Given that, why not let 2M pages also reuse this same pool? Would that make
the overall code implementation simpler? And if it does make things simpler,
should we go ahead and do it first?

Thanks,
Muchun

> 
> This reserves 4G for the existing gigantic-page pool and 1G for the
> PMD-sized pool. Existing unsuffixed parameters and gigantic-page pool
> sharing are preserved. The new size follows the architecture's PMD
> size rather than being fixed at 2M.
> 
> The preparatory patches introduce per-pool state and prevent recursive
> CMA allocation during migration before enabling PMD-sized allocation.
> 
> Thanks,
> Qi
> 
> Qi Zheng (5):
>  mm: hugetlb: add explicit page size to hugetlb_cma
>  mm: hugetlb: group CMA pool and reservation state
>  mm: hugetlb: track CMA reservations by page order
>  mm: hugetlb: avoid recursive CMA allocation during migration
>  mm: hugetlb: enable CMA allocation for PMD-sized pages
> 
> .../admin-guide/kernel-parameters.txt         |  39 ++-
> include/linux/hugetlb.h                       |   4 +-
> mm/hugetlb.c                                  |  80 +++--
> mm/hugetlb_cma.c                              | 328 ++++++++++++------
> mm/hugetlb_cma.h                              |  11 +-
> mm/mempolicy.c                                |   2 +-
> mm/migrate.c                                  |   3 +-
> 7 files changed, 306 insertions(+), 161 deletions(-)
> 
> 
> base-commit: b810335a0699d1810683796b0e3ffe8827ddfe6c
> -- 
> 2.54.0
>