Re: [PATCH 3/5] mm: hugetlb: track CMA reservations by page order
From: Jose A. Perez de Azpillaga
Date: Sat Oct 17 2026 - 15:16:11 EST
On 10/16/26 12:07 PM, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
>
> Prepare for a separate CMA pool for PMD-sized HugeTLB pages by organizing
> CMA areas and reservation parameters into pools identified by page order.
>
> Select the corresponding pool for allocation, CMA-only checks and
> boot-time allocation decisions. Release folios through the CMA area that
> owns their physical memory, including after demotion.
>
> Record each pool's successfully reserved capacity. Remove
> hugetlb_cma_validate_params(), since the per-pool CMA-only check already
> handles missing or empty pools.
>
> Continue accepting only the architecture's existing CMA page size and
> preserve the default pool's use by all gigantic sizes. PMD-sized pool
> support will be added in a subsequent patch.
>
> Assisted-by: LLM
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
[snip]
> +static struct hugetlb_cma_pool hugetlb_cma[HUGE_MAX_HSTATE] __ro_after_init;
> +static struct hugetlb_cma_config hugetlb_cma_config[HUGE_MAX_HSTATE] __initdata;
> +static unsigned int hugetlb_cma_nr __ro_after_init;
the commit message prepares for one more pool, the PMD one, and
hugetlb_cma_pool() folds every gigantic order into the default pool.
would a fixed pair work instead of an order-keyed array?
--
cheers,
jose a. p-a