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

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

> On Oct 19, 2026, at 16:20, Jose A. Perez de Azpillaga <azpijr@gmail.com> wrote:
> 
> On 10/19/26 9:50 AM, Muchun Song wrote:
>> 
>> 
>>> 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.
> 
> wouldn't a shared pool still be sized and aligned for 1G? then the 2M
> headroom stays a multiple of 1G and the 1G-aligned reservation can still
> fail, which is what the series is trying to avoid.

If we decide to use a shared pool, I think the current alignment strategy
should be adapted as well, it should be changed to align with the minimal
acquirement, like 2M.

For example, if a user reserves 1G+2M through hugetlb_cma, then the memory
reserved by the pool is also 1G+2M, except that the starting address needs
to be aligned to the largest gigantic page (1G). Therefore, this pool is
suitable for both 1GB and 2MB allocation. The only problem I see with a
shared pool is that it may not support mixed-use scenarios very well.

What do you think?

Thanks,
Muchun

> 
> -- 
> cheers,
> jose a. p-a