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

[Qi Zheng]

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@xxxxxxxxxxxxx>
> [...]
> > 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