Re: [PATCH v2 00/28] arch, mm: consolidate hugetlb early reservation

Frank van der Linden
2026-01-02T18:04:05Z

On Thu, Jan 1, 2026 at 11:00 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>
> Hi,
>
> Order in which early memory reservation for hugetlb happens depends on
> architecture, on configuration options and on command line parameters.
>
> Some architectures rely on the core MM to call hugetlb_bootmem_alloc()
> while others call it very early to allow pre-allocation of HVO-style
> vmemmap.
>
> When hugetlb_cma is supported by an architecture it is initialized during
> setup_arch() and then later hugetlb_init code needs to understand did it
> happen or not.
>
> To make everything consistent and unified, both reservation of hugetlb
> memory from bootmem and creation of CMA areas for hugetlb must be called
> from core MM initialization and it would have been a simple change.
> However, HVO-style pre-initialization ordering requirements slightly
> complicate things and for HVO pre-init to work sparse and memory map should
> be initialized after hugetlb reservations.
>
> This required pulling out the call to free_area_init() out of setup_arch()
> path and moving it MM initialization and this is what the first 23 patches
> do.
>
> These changes are deliberately split into per-arch patches that change how
> the zone limits are calculated for each architecture and the patches 22 and
> 23 just remove the calls to free_area_init() and sprase_init() from arch/*.
>
> Patch 24 is a simple cleanup for MIPS.
>
> Patches 25 and 26 actually consolidate hugetlb reservations and patches 27
> and 28 perform some aftermath cleanups.
>
> I tried to trim the distribution list and although it's still quite long
> if you feel that someone was wrongly excluded please add them back.
>
> The changes also available in git:
> https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=hugetlb-init/v2
>
> v2 changes:
> * move the hugetlb and memory map initializaion to mm_core_init_early()
> * add Acks
>
> v1: https://lore.kernel.org/all/20251228124001.3624742-1-rppt@kernel.org
>
> Mike Rapoport (Microsoft) (28):
> alpha: introduce arch_zone_limits_init()
> arc: introduce arch_zone_limits_init()
> arm: introduce arch_zone_limits_init()
> arm64: introduce arch_zone_limits_init()
> csky: introduce arch_zone_limits_init()
> hexagon: introduce arch_zone_limits_init()
> loongarch: introduce arch_zone_limits_init()
> m68k: introduce arch_zone_limits_init()
> microblaze: introduce arch_zone_limits_init()
> mips: introduce arch_zone_limits_init()
> nios2: introduce arch_zone_limits_init()
> openrisc: introduce arch_zone_limits_init()
> parisc: introduce arch_zone_limits_init()
> powerpc: introduce arch_zone_limits_init()
> riscv: introduce arch_zone_limits_init()
> s390: introduce arch_zone_limits_init()
> sh: introduce arch_zone_limits_init()
> sparc: introduce arch_zone_limits_init()
> um: introduce arch_zone_limits_init()
> x86: introduce arch_zone_limits_init()
> xtensa: introduce arch_zone_limits_init()
> arch, mm: consolidate initialization of nodes, zones and memory map
> arch, mm: consolidate initialization of SPARSE memory model
> mips: drop paging_init()
> x86: don't reserve hugetlb memory in setup_arch()
> mm, arch: consolidate hugetlb CMA reservation
> mm/hugetlb: drop hugetlb_cma_check()
> Revert "mm/hugetlb: deal with multiple calls to hugetlb_bootmem_alloc"
>
> .../driver-api/cxl/linux/early-boot.rst | 2 +-
> Documentation/mm/memory-model.rst | 3 --
> .../translations/zh_CN/mm/memory-model.rst | 2 -
> arch/alpha/kernel/setup.c | 1 -
> arch/alpha/mm/init.c | 16 ++++----
> arch/arc/mm/init.c | 37 +++++++++---------
> arch/arm/mm/init.c | 25 ++----------
> arch/arm64/include/asm/hugetlb.h | 2 -
> arch/arm64/mm/hugetlbpage.c | 10 ++---
> arch/arm64/mm/init.c | 39 ++++++++-----------
> arch/csky/kernel/setup.c | 16 ++++----
> arch/hexagon/mm/init.c | 19 +++------
> arch/loongarch/include/asm/pgtable.h | 2 -
> arch/loongarch/kernel/setup.c | 10 -----
> arch/loongarch/mm/init.c | 6 +--
> arch/m68k/mm/init.c | 8 ++--
> arch/m68k/mm/mcfmmu.c | 3 --
> arch/m68k/mm/motorola.c | 6 +--
> arch/m68k/mm/sun3mmu.c | 9 -----
> arch/microblaze/mm/init.c | 22 +++++------
> arch/mips/include/asm/pgalloc.h | 2 -
> arch/mips/include/asm/pgtable.h | 2 +-
> arch/mips/kernel/setup.c | 15 +------
> arch/mips/loongson64/numa.c | 10 ++---
> arch/mips/mm/init.c | 8 +---
> arch/mips/sgi-ip27/ip27-memory.c | 8 +---
> arch/nios2/mm/init.c | 12 +++---
> arch/openrisc/mm/init.c | 10 +----
> arch/parisc/mm/init.c | 11 +-----
> arch/powerpc/include/asm/hugetlb.h | 5 ---
> arch/powerpc/include/asm/setup.h | 4 ++
> arch/powerpc/kernel/setup-common.c | 1 -
> arch/powerpc/mm/hugetlbpage.c | 11 ++----
> arch/powerpc/mm/mem.c | 27 +++++--------
> arch/powerpc/mm/numa.c | 2 -
> arch/riscv/mm/hugetlbpage.c | 8 ++++
> arch/riscv/mm/init.c | 10 +----
> arch/s390/kernel/setup.c | 2 -
> arch/s390/mm/hugetlbpage.c | 8 ++++
> arch/s390/mm/init.c | 13 +++----
> arch/sh/mm/init.c | 12 +++---
> arch/sparc/mm/init_64.c | 17 +++-----
> arch/sparc/mm/srmmu.c | 17 ++++----
> arch/um/kernel/mem.c | 10 ++---
> arch/x86/kernel/setup.c | 5 ---
> arch/x86/mm/hugetlbpage.c | 8 ++++
> arch/x86/mm/init.c | 8 +---
> arch/x86/mm/init_32.c | 2 -
> arch/x86/mm/init_64.c | 4 --
> arch/x86/mm/mm_internal.h | 1 -
> arch/xtensa/mm/init.c | 14 +++----
> include/linux/hugetlb.h | 12 ++----
> include/linux/mm.h | 5 ++-
> include/linux/mmzone.h | 2 -
> init/main.c | 1 +
> mm/hugetlb.c | 13 -------
> mm/hugetlb_cma.c | 33 ++++++++--------
> mm/hugetlb_cma.h | 5 ---
> mm/hugetlb_vmemmap.c | 11 ------
> mm/internal.h | 6 +++
> mm/mm_init.c | 20 ++++++----
> 61 files changed, 219 insertions(+), 394 deletions(-)
>
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> --
> 2.51.0
>

Thanks for this series. When I introduced HVO pre-init, I noticed the
inconsistencies in init order, but shied away from attempting any
general cleanup, as I had only tested pre-init on x86.

With this, it should be possible to enable
ARCH_WANT_HUGETLB_VMEMMAP_PREINIT on architectures that support HVO. I
think that's only riscv and loongarch right now. But that's out of
scope here, though.

- Frank