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

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

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?

[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?

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 :)

-- 
cheers,
jose a. p-a