From: Frank van der Linden <fvdl@google.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alex Shi <alexs@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Andreas Larsson <andreas@gaisler.com>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@kernel.org>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>, Heiko Carstens <hca@linux.ibm.com>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Jonathan Corbet <corbet@lwn.net>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Magnus Lindholm <linmag7@gmail.com>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Hocko <mhocko@suse.com>, Michal Simek <monstr@monstr.eu>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Palmer Dabbelt <palmer@dabbelt.com>,
Pratyush Yadav <pratyush@kernel.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Vasily Gorbik <gor@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
x86@kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-csky@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-doc@vger.kernel.org, linux-hexagon@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linux-um@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
loongarch@lists.linux.dev, sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 00/28] arch, mm: consolidate hugetlb early reservation
Date: Fri, 2 Jan 2026 10:03:49 -0800 [thread overview]
Message-ID: <CAPTztWaZZt_ygCDNaDdW9A_TtT1FNZW6hFzyiq2b6_xxMw38gQ@mail.gmail.com> (raw)
In-Reply-To: <20260102070005.65328-1-rppt@kernel.org>
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
prev parent reply other threads:[~2026-01-02 18:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-02 6:59 Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 01/28] alpha: introduce arch_zone_limits_init() Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 02/28] arc: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 03/28] arm: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 04/28] arm64: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 05/28] csky: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 06/28] hexagon: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 07/28] loongarch: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 08/28] m68k: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 09/28] microblaze: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 10/28] mips: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 11/28] nios2: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 12/28] openrisc: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 13/28] parisc: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 14/28] powerpc: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 15/28] riscv: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 16/28] s390: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 17/28] sh: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 18/28] sparc: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 19/28] um: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 20/28] x86: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 21/28] xtensa: " Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 23/28] arch, mm: consolidate initialization of SPARSE memory model Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 24/28] mips: drop paging_init() Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 25/28] x86: don't reserve hugetlb memory in setup_arch() Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 26/28] mm, arch: consolidate hugetlb CMA reservation Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 27/28] mm/hugetlb: drop hugetlb_cma_check() Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 28/28] Revert "mm/hugetlb: deal with multiple calls to hugetlb_bootmem_alloc" Mike Rapoport
2026-01-02 18:03 ` Frank van der Linden [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPTztWaZZt_ygCDNaDdW9A_TtT1FNZW6hFzyiq2b6_xxMw38gQ@mail.gmail.com \
--to=fvdl@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alexs@kernel.org \
--cc=andreas@gaisler.com \
--cc=bcain@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gor@linux.ibm.com \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=jcmvbkbc@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linmag7@gmail.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=mattst88@gmail.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=palmer@dabbelt.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=rppt@kernel.org \
--cc=shorne@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=vgupta@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox