On Thu, Aug 28, 2025 at 12:01:05AM +0200, 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).
Nice! And I see SPARSEMEM_VMEMMAP_ENABLE is selected by the arches which support it, as you say 64-bit (or in other words - modern :) > > This is a preparation for not supporting > > (1) folio sizes that exceed a single memory section > (2) CMA allocations of non-contiguous page ranges Nice. This should simplify things... :) > > 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). > > Acked-by: Zi Yan <z...@nvidia.com> > Acked-by: Mike Rapoport (Microsoft) <r...@kernel.org> > Acked-by: SeongJae Park <s...@kernel.org> > Cc: Huacai Chen <chenhua...@kernel.org> > Cc: WANG Xuerui <ker...@xen0n.name> > Cc: Madhavan Srinivasan <ma...@linux.ibm.com> > Cc: Michael Ellerman <m...@ellerman.id.au> > Cc: Nicholas Piggin <npig...@gmail.com> > Cc: Christophe Leroy <christophe.le...@csgroup.eu> > Cc: Paul Walmsley <paul.walms...@sifive.com> > Cc: Palmer Dabbelt <pal...@dabbelt.com> > Cc: Albert Ou <a...@eecs.berkeley.edu> > Cc: Alexandre Ghiti <a...@ghiti.fr> > Cc: "David S. Miller" <da...@davemloft.net> > Cc: Andreas Larsson <andr...@gaisler.com> > Signed-off-by: David Hildenbrand <da...@redhat.com> LGTM, so: Reviewed-by: Lorenzo Stoakes <lorenzo.stoa...@oracle.com> > --- > mm/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 4108bcd967848..330d0e698ef96 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -439,9 +439,8 @@ config SPARSEMEM_VMEMMAP_ENABLE > bool > > config SPARSEMEM_VMEMMAP > - bool "Sparse Memory virtual memmap" > + def_bool y > depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE > - default y > help > SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise > pfn_to_page and page_to_pfn operations. This is the most > -- > 2.50.1 >
