Re: [PATCH 5/5] mm: hugetlb: enable CMA allocation for PMD-sized pages

[Qi Zheng <qi.zheng@linux.dev>]

Hi Lance,

On 10/20/26 5:16 PM, Lance Yang wrote:
> 
> On Fri, Oct 16, 2026 at 06:07:36PM +0800, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
> [...]
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 218fbaee6f7e5..8c00fd9d0658d 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1362,18 +1362,8 @@ static struct folio *dequeue_hugetlb_folio(struct hstate *h, gfp_t gfp_mask,
>> static struct folio *alloc_gigantic_frozen_folio(int order, gfp_t gfp_mask,
>> 		int nid, nodemask_t *nodemask)
>> {
>> -	struct folio *folio;
>> -
>> -	folio = hugetlb_cma_alloc_frozen_folio(order, gfp_mask, nid, nodemask);
>> -	if (folio)
>> -		return folio;
>> -
>> -	if (hugetlb_cma_exclusive_alloc(order))
>> -		return NULL;
>> -
>> -	folio = (struct folio *)alloc_contig_frozen_pages(1 << order, gfp_mask,
>> -							  nid, nodemask);
>> -	return folio;
>> +	return (struct folio *)alloc_contig_frozen_pages(1 << order, gfp_mask,
>> +							 nid, nodemask);
>> }
>> #else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE || !CONFIG_CONTIG_ALLOC */
>> static struct folio *alloc_gigantic_frozen_folio(int order, gfp_t gfp_mask, int nid,
>> @@ -1849,11 +1839,18 @@ static struct folio *only_alloc_fresh_hugetlb_folio(struct hstate *h,
>> 	if (nid == NUMA_NO_NODE)
>> 		nid = numa_mem_id();
>>
>> -	if (order_is_gigantic(order))
>> -		folio = alloc_gigantic_frozen_folio(order, gfp_mask, nid, nmask);
>> -	else
>> -		folio = alloc_buddy_frozen_folio(order, gfp_mask, nid, nmask,
>> -						 node_alloc_noretry);
>> +	folio = hugetlb_cma_alloc_frozen_folio(order, gfp_mask, nid, nmask);
>> +	if (!folio) {
> 
> Emm ... what about PF_MEMALLOC_PIN here?
> 
> If a FOLL_LONGTERM migration out of CMA needs a fresh hugetlb folio,
> this can allocate another CMA folio as the target.
> 
> With HVO disabled, the old folio is freed back to CMA and can be picked
> again again again.
> 
> I guess we'd keep migrating between CMA folios without ever completing
> the pin ... even if pinnable buddy memory is available, no?

Yes, you are right. A fresh migration target can come from CMA again,
causing repeated migration without completing the pin, even when
pinnable buddy memory is available.

The same missing PF_MEMALLOC_PIN check also affects 1 GiB CMA
allocations, so I had planned to fix it separately.

Thanks,
Qi

> 
> [...]
> 
> Cheers, Lance