On 21 Aug 2025, at 16:06, David Hildenbrand wrote: > In an ideal world, we wouldn't have to deal with SPARSEMEM without > SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is > considered too costly and consequently not supported. > > However, if an architecture does support SPARSEMEM with > SPARSEMEM_VMEMMAP, let's forbid the user to disable VMEMMAP: just > like we already do for arm64, s390 and x86. > > So if SPARSEMEM_VMEMMAP is supported, don't allow to use SPARSEMEM without > SPARSEMEM_VMEMMAP. > > This implies that the option to not use SPARSEMEM_VMEMMAP will now be > gone for loongarch, powerpc, riscv and sparc. All architectures only > enable SPARSEMEM_VMEMMAP with 64bit support, so there should not really > be a big downside to using the VMEMMAP (quite the contrary). > > This is a preparation for not supporting > > (1) folio sizes that exceed a single memory section > (2) CMA allocations of non-contiguous page ranges > > in SPARSEMEM without SPARSEMEM_VMEMMAP configs, whereby we > want to limit possible impact as much as possible (e.g., gigantic hugetlb > page allocations suddenly fails).
Sounds like a good idea. > > Cc: Huacai Chen <[email protected]> > Cc: WANG Xuerui <[email protected]> > Cc: Madhavan Srinivasan <[email protected]> > Cc: Michael Ellerman <[email protected]> > Cc: Nicholas Piggin <[email protected]> > Cc: Christophe Leroy <[email protected]> > Cc: Paul Walmsley <[email protected]> > Cc: Palmer Dabbelt <[email protected]> > Cc: Albert Ou <[email protected]> > Cc: Alexandre Ghiti <[email protected]> > Cc: "David S. Miller" <[email protected]> > Cc: Andreas Larsson <[email protected]> > Signed-off-by: David Hildenbrand <[email protected]> > --- > mm/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Acked-by: Zi Yan <[email protected]> Best Regards, Yan, Zi
