summaryrefslogtreecommitdiff
path: root/mm/Kconfig
diff options
context:
space:
mode:
authorBob Picco <bob.picco@hp.com>2005-09-03 15:54:28 -0700
committerLinus Torvalds <torvalds@evo.osdl.org>2005-09-05 00:05:38 -0700
commit3e347261a80b57df792ab9464b5f0ed59add53a8 (patch)
tree047b35e0f9ec82b3beeff882a9af6292a500097c /mm/Kconfig
parent802f192e4a600f7ef84ca25c8b818c8830acef5a (diff)
downloadlinux-3.10-3e347261a80b57df792ab9464b5f0ed59add53a8.tar.gz
linux-3.10-3e347261a80b57df792ab9464b5f0ed59add53a8.tar.bz2
linux-3.10-3e347261a80b57df792ab9464b5f0ed59add53a8.zip
[PATCH] sparsemem extreme implementation
With cleanups from Dave Hansen <haveblue@us.ibm.com> SPARSEMEM_EXTREME makes mem_section a one dimensional array of pointers to mem_sections. This two level layout scheme is able to achieve smaller memory requirements for SPARSEMEM with the tradeoff of an additional shift and load when fetching the memory section. The current SPARSEMEM implementation is a one dimensional array of mem_sections which is the default SPARSEMEM configuration. The patch attempts isolates the implementation details of the physical layout of the sparsemem section array. SPARSEMEM_EXTREME requires bootmem to be functioning at the time of memory_present() calls. This is not always feasible, so architectures which do not need it may allocate everything statically by using SPARSEMEM_STATIC. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Bob Picco <bob.picco@hp.com> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'mm/Kconfig')
-rw-r--r--mm/Kconfig19
1 files changed, 16 insertions, 3 deletions
diff --git a/mm/Kconfig b/mm/Kconfig
index fc644c5c065..4e9937ac352 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -91,10 +91,23 @@ config HAVE_MEMORY_PRESENT
depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
#
+# SPARSEMEM_EXTREME (which is the default) does some bootmem
+# allocations when memory_present() is called. If this can not
+# be done on your architecture, select this option. However,
+# statically allocating the mem_section[] array can potentially
+# consume vast quantities of .bss, so be careful.
+#
+# This option will also potentially produce smaller runtime code
+# with gcc 3.4 and later.
+#
+config SPARSEMEM_STATIC
+ def_bool n
+
+#
# Architectecture platforms which require a two level mem_section in SPARSEMEM
# must select this option. This is usually for architecture platforms with
# an extremely sparse physical address space.
#
-config ARCH_SPARSEMEM_EXTREME
- def_bool n
- depends on SPARSEMEM && 64BIT
+config SPARSEMEM_EXTREME
+ def_bool y
+ depends on SPARSEMEM && !SPARSEMEM_STATIC