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

[David Hildenbrand <david@redhat.com>]

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.

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*.

@Willy, what's your take?

-- 
Cheers

David / dhildenb