Re: [PATCH 4/4] mm: hugetlb: allocate frozen pages in alloc_gigantic_folio()

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 2025/9/12 2:56, David Hildenbrand wrote:
> On 11.09.25 11:11, Kefeng Wang wrote:
>>
>>
>> On 2025/9/11 16:25, David Hildenbrand wrote:
>>> On 11.09.25 08:56, Kefeng Wang wrote:
>>>> The alloc_gigantic_folio() allocates a folio by alloc_contig_range()
>>>> with refcount increated and then freeze it, convert to allocate a 
>>>> frozen
>>>> folio directly to remove the atomic operation about folio refcount, 
>>>> also
>>>> saving atomic operation during __update_and_free_hugetlb_folio too.
>>>>
>>>> Rename some functions to make them more self-explanatory,
>>>>
>>>>     folio_alloc_gigantic            -> folio_alloc_frozen_gigantic
>>>>     cma_{alloc,free}_folio          -> cma_{alloc,free}_frozen_folio
>>>>     hugetlb_cma_{alloc,free}_folio  -> hugetlb_cma_{alloc,free}
>>>> _frozen_folio
>>>
>>> Can we just get rid of folio_alloc_frozen_gigantic?
>>>
>>
>> OK, we could kill it.
>>
>>> Further, can we just get rid of cma_{alloc,free}_frozen_folio() as well
>>> and just let hugetlb use alloc_contig_range_frozen() etc?
>>
>> HugeTLB can allocate folio by alloc_contig_frozen_pages() directly, but
>> it could allocate from hugetlb_cma, cma_alloc_folio() need change some
>> cma metadata, so we need to keep it.
> 
> Hm. Assuming we just have cma_alloc_frozen() -- again, probably what 
> cma_alloc() would look like in the future, hugetlb can just construct a 
> folio out of that.

I get your point，firstly, we could convert to use cma_alloc_frozen()
instead of cma_alloc_folio() in hugetlb_cma_alloc_folio().

> 
> Maybe we just want a helper to create a folio out of a given page range?
> 
> And that page range is either obtained through cma_alloc_frozen() or 
> alloc_contig_frozen_pages().
> 
> Just a thought, keeping in mind that these things should probably just 
> work with frozen pages and let allcoating of a memdesc etc. be taken 
> care of someone else.
> 
> I'd be happy if we can remove the GFP_COMPOUND parameter from 
> alloc_contig*.

But not sure about this part,  GFP_COMPOUND for alloc_contig* is
introduced by commit e98337d11bbd "mm/contig_alloc: support __GFP_COMP",
if we still allocate a range of order-0 pages and create a folio
outside, it will slow the large folio allocation.


> 
> @Willy, what's your take?
>