Re: [PATCH v2 5/5] mm: hugetlb: enable CMA allocation for PMD-sized pages

[Qi Zheng <qi.zheng@linux.dev>]

On 10/22/26 5:05 PM, Jose A. Perez de Azpillaga wrote:
> On 10/22/26 9:31 AM, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>
>> Allow hugetlb_cma=<capacity>@<page-size> to select the architecture's PMD
>> size in addition to its existing CMA size. PMD pages are 2M on x86-64 and
>> 2M, 32M or 512M on arm64 with 4K, 16K or 64K base pages.
>>
>> Give PMD pages their own pool while preserving the existing sharing among
>> gigantic sizes. Unsuffixed arguments and an explicit default size continue
>> to configure the default pool. Gigantic PMD sizes retain access to that
>> pool when no PMD pool is reserved. Apply this mapping consistently to
>> allocation, CMA-only policy and boot-time accounting.
>>
>> Try buddy allocation first for non-gigantic PMD pages, with CMA as a
>> fallback, to reduce CMA migration and leave CMA capacity for later
>> allocations. Preserve CMA-only policy and CMA-first allocation for
>> gigantic pages.
> 
> on v1 you told Lance [1]:
> 
>> The same missing PF_MEMALLOC_PIN check also affects 1 GiB CMA
>> allocations, so I had planned to fix it separately.
> 
> why did v2 go out before the fix then? 1G CMA pins fail with -ENOMEM
> today, so it's this patch that makes it hang.

This is a pre-existing issue, so I didn't intend for this patchset to
depend on that fix.

However, with PMD size enabled, the problem could indeed become more
severe. I'll send out a fix patch as soon as possible.

Thanks,
Qi

> 
> [1]
> https://lore.kernel.org/all/04c89538-28c8-4d03-92c1-08d854a46ac4@linux.dev/
>