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).
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>
---
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
