Re: [PATCH 0/5] mm: hugetlb: add CMA support for PMD-sized page

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

On 10/19/26 8:18 PM, David Hildenbrand (Arm) wrote:
> On 10/19/26 11:17, Jose A. Perez de Azpillaga wrote:
>> On 10/19/26 10:43 AM, Muchun Song wrote:
>>>
>>>
>>>>
>>>>
>>>> wouldn't a shared pool still be sized and aligned for 1G? then the 2M
>>>> headroom stays a multiple of 1G and the 1G-aligned reservation can still
>>>> fail, which is what the series is trying to avoid.
>>>
>>> If we decide to use a shared pool, I think the current alignment strategy
>>> should be adapted as well, it should be changed to align with the minimal
>>> acquirement, like 2M.
>>>
>>> For example, if a user reserves 1G+2M through hugetlb_cma, then the memory
>>> reserved by the pool is also 1G+2M, except that the starting address needs
>>> to be aligned to the largest gigantic page (1G). Therefore, this pool is
>>> suitable for both 1GB and 2MB allocation. The only problem I see with a
>>> shared pool is that it may not support mixed-use scenarios very well.
>>>
>>> What do you think?
>>
>> makes sense to me. existing hugetlb_cma= users with WM pages would get
>> mixed use without asking for it though.
> 
> Yeah, my intuition tells me that having 1 allocation size per CMA area might be
> cleaner.

Agree.

> 
> Assume you allocate 512 2 MiB hugetlb folios. You'd think that you would then be
> able to allocate 1 GiB hugetlb folio less. But that's not guaranteed, as CMA
> might just fallback to other areas fairly easily.
> 
> If someone wants to convert from 1 GiB to 512 x 2MiB, I think the demotion
> interface allows for that.

For this series, I'd like to use a separate CMA pool for the newly
supported PMD-sized pages, while keeping the existing sharing among
gigantic sizes unchanged.

If there are no objections, I'll update v2.

Thanks,
Qi