Re: [PATCH 3/5] mm: hugetlb: track CMA reservations by page order

[Qi Zheng]

Hi Jose,

On 10/18/26 2:41 AM, Jose A. Perez de Azpillaga wrote:
> 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?

Do you mean keeping two fixed pools, like this:

enum {
	HUGETLB_CMA_DEFAULT,
	HUGETLB_CMA_PMD,
	HUGETLB_CMA_POOLS,
};

If so, I agree. That is sufficient for this series and simpler than an
order-keyed array.

Thanks,
Qi