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

["Qi Zheng" <zhengqi.arch@bytedance.com>]

On 10/18/26 3:07 AM, Jose A. Perez de Azpillaga wrote:
> On 10/16/26 12:07 PM, 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 without changing the original pool's sharing
>> among other gigantic sizes. On arm64 with 4K base pages, 32M and 1G pages
>> continue to use the default 1G-aligned pool. Unsuffixed arguments and an
>> explicit default size still configure that same pool.
>>
>> PMD requests use only the PMD pool, even when their order is gigantic.
>> Other gigantic requests use only the original pool. Apply this mapping
>> consistently to allocation, CMA-only policy and boot-time accounting.
>>
>> Move CMA allocation into the common fresh HugeTLB allocation path so
>> non-gigantic pages can use CMA. Align reservations to both the selected
>> page size and CMA's minimum alignment, and use a bitmap granularity no
>> larger than the selected order. Keep the original CMA area names and give
>> PMD areas distinct names. Document the syntax and pool selection.
>>
>> Assisted-by: LLM
>> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> [snip]
> 
>> +	folio = hugetlb_cma_alloc_frozen_folio(order, gfp_mask, nid, nmask);
>> +	if (!folio) {
> 
> boot-time hugepages= goes through here too, so hugepages=128 with
> hugetlb_cma=512M@2M already uses half of the pool at boot. would buddy
> first and cma as fallback make more sense for PMD?

That makes sense.

Buddy-first can reduce CMA migration and leave more CMA capacity
for later allocations.

I'll use buddy first and CMA as a fallback for non-gigantic PMD pages,
while keeping hugetlb_cma_only=1 restricted to CMA and preserving the
existing gigantic allocation path.

> 
> [snip]
> 
>> +	if (order != PMD_SHIFT - PAGE_SHIFT && order_is_gigantic(order))
>>   		order = hugetlb_cma_default_order;
> 
> doesn't this take gigantic PMD-order pages out of the default pool even
> when no PMD pool is set? would trying the exact order first and then
> falling back to the default pool work?

Good point. Perhaps we should use the following selector with the two
fixed pools:

static struct hugetlb_cma_pool *hugetlb_cma_pool(unsigned int order)
{
	struct hugetlb_cma_pool *pmd_pool = &hugetlb_cma[HUGETLB_CMA_PMD];

	if (order == PMD_SHIFT - PAGE_SHIFT && pmd_pool->size)
		return pmd_pool;

	if (order_is_gigantic(order))
		return &hugetlb_cma[HUGETLB_CMA_DEFAULT];

	return NULL;
}

> 
> I tested it on qemu and saw no issues, but I'm hesitant about the points
> above. I can give a Tested-by tag on the next version :)

Thanks! I'll send out a v2 as soon as possible.