[PATCH v2 0/5] mm: hugetlb: add CMA support for PMD-sized pages

[Qi Zheng]

From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>

Hi all,

Allocating PMD-sized HugeTLB pages at runtime can become slow or fail
as physical memory becomes fragmented. Reserving HugeTLB pages at boot
avoids this problem, but keeps unused pages unavailable to ordinary
allocations.

Live upgrades are one example: they need additional HugeTLB pages only
during the upgrade. HugeTLB already supports CMA for gigantic pages,
but allocating a 1 GiB page from CMA may require migrating movable pages
out of a large contiguous range. Pages that cannot be migrated can prevent
the allocation from succeeding.

Extend CMA support to PMD-sized pages so their backing memory can be
reserved at boot while remaining usable for movable allocations until
needed. This relaxes the reservation alignment requirement and reduces
the contiguous range required per allocation.

The series adds an optional @<page-size> suffix to hugetlb_cma and a
separate PMD-sized pool. For example, on x86-64:

        hugetlb_cma=4G hugetlb_cma=1G@2M

This reserves 4G for the default pool and 1G for the PMD-sized pool.
Unsuffixed parameters continue to configure the default pool. Other
gigantic sizes still share that pool, as do gigantic PMD sizes when
no separate PMD pool is reserved. The new size follows the architecture's
PMD size rather than being fixed at 2M.

Non-gigantic PMD allocations try buddy first and fall back to CMA.
Gigantic allocations retain CMA-first behavior at runtime. With
hugetlb_cma_only=1, sizes with a reserved CMA pool remain restricted to CMA.

The preparatory patches introduce two fixed pool slots and pass an
allow_cma flag through the common allocation helpers to prevent recursive
CMA allocation during migration and free HugeTLB folio replacement.

Changes in v2:
 - Replace the order-keyed CMA pool array with two fixed pools for the
   default and PMD sizes. (suggested by Jose A. Perez de Azpillaga)
 - Pass allow_cma through the common fresh HugeTLB allocation helpers,
   removing the separate helper that bypassed CMA.
   (suggested by Jose A. Perez de Azpillaga)
 - Try buddy allocation before CMA for non-gigantic PMD pages, while
   preserving CMA-only policy and CMA-first allocation for gigantic pages.
   (suggested by Jose A. Perez de Azpillaga)
 - Preserve default-pool access for gigantic PMD sizes when no separate
   PMD pool is reserved.
 - Collect Reviewed-by tags
 - Rebase onto next-20261020

v1: https://lore.kernel.org/all/cover.1792136742.git.zhengqi.arch@xxxxxxxxxxxxx/

Thanks,
Qi

Qi Zheng (5):
  mm: hugetlb: add explicit page size to hugetlb_cma
  mm: hugetlb: group CMA pool and reservation state
  mm: hugetlb: track CMA reservations by pool
  mm: hugetlb: avoid recursive CMA allocation during migration
  mm: hugetlb: enable CMA allocation for PMD-sized pages

 .../admin-guide/kernel-parameters.txt         |  40 ++-
 include/linux/hugetlb.h                       |   4 +-
 mm/hugetlb.c                                  |  67 ++--
 mm/hugetlb_cma.c                              | 328 ++++++++++++------
 mm/hugetlb_cma.h                              |  11 +-
 mm/mempolicy.c                                |   2 +-
 mm/migrate.c                                  |   3 +-
 7 files changed, 288 insertions(+), 167 deletions(-)


base-commit: 8f7df005a7564bd7ffa75da9c3085d5b996f1e16
-- 
2.54.0