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

[Qi Zheng]

On 10/22/26 5:05 PM, Jose A. Perez de Azpillaga wrote:
> On 10/22/26 9:31 AM, Qi Zheng wrote:
> > From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> >
> > Allow hugetlb_cma=<capacity>@<page-size> to select the architecture's PMD
> > size in addition to its existing CMA size. PMD pages are 2M on x86-64 and
> > 2M, 32M or 512M on arm64 with 4K, 16K or 64K base pages.
> >
> > Give PMD pages their own pool while preserving the existing sharing among
> > gigantic sizes. Unsuffixed arguments and an explicit default size continue
> > to configure the default pool. Gigantic PMD sizes retain access to that
> > pool when no PMD pool is reserved. Apply this mapping consistently to
> > allocation, CMA-only policy and boot-time accounting.
> >
> > Try buddy allocation first for non-gigantic PMD pages, with CMA as a
> > fallback, to reduce CMA migration and leave CMA capacity for later
> > allocations. Preserve CMA-only policy and CMA-first allocation for
> > gigantic pages.
>
> on v1 you told Lance [1]:
>
> > The same missing PF_MEMALLOC_PIN check also affects 1 GiB CMA
> > allocations, so I had planned to fix it separately.
>
> why did v2 go out before the fix then? 1G CMA pins fail with -ENOMEM
> today, so it's this patch that makes it hang.

This is a pre-existing issue, so I didn't intend for this patchset to
depend on that fix.

However, with PMD size enabled, the problem could indeed become more
severe. I'll send out a fix patch as soon as possible.

Thanks,
Qi

> [1]
> https://lore.kernel.org/all/04c89538-28c8-4d03-92c1-08d854a46ac4@xxxxxxxxx/