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

["Jose A. Perez de Azpillaga" <azpijr@gmail.com>]

On 10/22/26 9:31 AM, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> 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.

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

-- 
cheers,
jose a. p-a