On Sun, 28 Dec 2025 14:39:30 +0200 Mike Rapoport <[email protected]> wrote:
> 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. Thanks for the diligence - this can't have been the most exciting thing to work on! > 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. I'll add these to mm.git's mm-new branch for some testing. I'll suppress the usual email storm because 41 * 28 is a lot of emails ;)
