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

[Qi Zheng]

Hi Muchun,

On 10/19/26 2:50 PM, Muchun Song wrote:
> 
> 
>> 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?

Sharing the pool would simplify the implementation. My concern is that
small PMD allocations could fragment the default pool and prevent later
gigantic allocations.

32M allocations can already cause this, but 2M allocations can block
the same number of 1G-aligned ranges with much less allocated memory.

Thanks,
Qi

> 
> 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
>>