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

["Jose A. Perez de Azpillaga" <azpijr@gmail.com>]

On 10/19/26 10:43 AM, Muchun Song wrote:
> 
> 
>> 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?

makes sense to me. existing hugetlb_cma= users with WM pages would get
mixed use without asking for it though.

-- 
cheers,
jose a. p-a