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

[Muchun Song <muchun.song@linux.dev>]

> On Oct 19, 2026, at 15:37, Qi Zheng <zhengqi.arch@bytedance.com> wrote:
> 
> Hi Muchun,
> 
> On 10/19/26 2:50 PM, Muchun Song wrote:
>> 
>> 
>>> On Oct 16, 2026, at 18:07, Qi Zheng <qi.zheng@linux.dev> wrote:
>>> 
>>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>> 
>>> 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.

Yes. However, the premise is that there has to be a mixed-use scenario.
I'm not sure if this kind of mixed usage is a common scenario.

Of course, we don't have much experience to draw on, because on most
architectures there is generally only one kind of gigantic page, and
prior to this, mixed-use scenarios could not arise.

Therefore, I think that before the need arises, a simpler design is
easier to maintain.

Thanks,
Muchun

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