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

-- 
cheers,
jose a. p-a