ARM: Add default SPARSEMEM settings
PATCH 1/3 ARM: Add default SPARSEMEM settings
We can still override these settings via mach/memory.h, but let's provide sensible defaults so that SPARSEMEM is available in the multiplatform kernels.
Two platforms currently use SECTION_SIZE_BITS < 28, but are expected to work with 28 (albeit slightly less efficiently if not all banks are populated):
- mach-rpc: uses 26 bits. Based on mach/hardware.h it looks like this platform puts RAM@0x1000_0000 - 0x1fff_ffff, and I/O below 0x1000_0000.
- mach-sa1100: uses 27 bits. mach/memory.h indicates that RAM occupies the entire range of 0xc000_0000 - 0xdfff_ffff.
Several platforms need MAX_PHYSMEM_BITS >= 36 so we'll pick that as the minimum. Anything higher and we'll fail the SECTIONS_WIDTH + NODES_WIDTH + ZONES_WIDTH test in <linux/mm.h>.
--- arch/arm/include/asm/sparsemem.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
arch/arm/include/asm/sparsemem.h +4 -3
@@ -15,10 +15,11 @@* Eg, if you have 2 banks of up to 64MB at 0x80000000, 0x84000000, * then MAX_PHYSMEM_BITS is 32, SECTION_SIZE_BITS is 26. * -* Define these in your mach/memory.h. +* These can be overridden in your mach/memory.h. */ -#if !defined(SECTION_SIZE_BITS ) || !defined(MAX_PHYSMEM_BITS ) -#error Sparsemem is not supported on this platform +#if !defined(MAX_PHYSMEM_BITS ) || !defined(SECTION_SIZE_BITS ) +#define MAX_PHYSMEM_BITS 36 +#define SECTION_SIZE_BITS 28#endif #endif
Signature · 1 line
1.7.9.5
PATCH 2/3 ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting
If ARCH_SPARSEMEM_ENABLE=y and ARCH_{FLATMEM,DISCONTIGMEM}_ENABLE=n, then the logic in mm/Kconfig already makes CONFIG_SPARSEMEM the only choice. This is true for all of the existing ARM users of ARCH_SPARSEMEM_ENABLE.
Forcing ARCH_SPARSEMEM_DEFAULT=y if ARCH_SPARSEMEM_ENABLE=y prevents us from ever defaulting to FLATMEM, so we should remove this setting.
--- arch/arm/Kconfig | 3 --- 1 file changed, 3 deletions(-)
arch/arm/Kconfig +0 -3
@@ -1635,9 +1635,6 @@ config ARCH_HAS_HOLES_MEMORYMODEL config ARCH_SPARSEMEM_ENABLE bool -config ARCH_SPARSEMEM_DEFAULT - def_bool ARCH_SPARSEMEM_ENABLE - config ARCH_SELECT_MEMORY_MODEL def_bool ARCH_SPARSEMEM_ENABLE
Signature · 1 line
1.7.9.5
PATCH 2/3 ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting
Quoted 9 lines · Kevin Cernekee
If ARCH_SPARSEMEM_ENABLE=y and ARCH_{FLATMEM,DISCONTIGMEM}_ENABLE=n, then the logic in mm/Kconfig already makes
CONFIG_SPARSEMEMthe only choice. This is true for all of the existing ARM users ofARCH_SPARSEMEM_ENABLE.Forcing ARCH_SPARSEMEM_DEFAULT=y if ARCH_SPARSEMEM_ENABLE=y prevents us from ever defaulting to FLATMEM, so we should remove this setting.
Signed-off-by Kevin Cernekee <[email protected]>
PATCH 3/3 ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build
In reply to Kevin CernekeeARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of system memory can be located deep in the 36-bit address space. Allow FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains the default.
--- arch/arm/Kconfig | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/Kconfig +5 -0
@@ -821,6 +821,8 @@ config ARCH_MULTI_V7 bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" default y select ARCH_MULTI_V6_V7 + select ARCH_FLATMEM_ENABLE + select ARCH_SPARSEMEM_ENABLE select CPU_V7 select HAVE_SMP
@@ -1632,6 +1634,9 @@ config OABI_COMPAT config ARCH_HAS_HOLES_MEMORYMODEL bool +config ARCH_FLATMEM_ENABLE + bool + config ARCH_SPARSEMEM_ENABLE bool
Signature · 1 line
1.7.9.5
PATCH 3/3 ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build
Quoted 6 lines · Kevin Cernekee
ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of system memory can be located deep in the 36-bit address space. Allow FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains the default.
Signed-off-by Kevin Cernekee <[email protected]>
PATCH 3/3 ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build
Quoted 10 lines · On Friday 31 October 2014 13:12:46 Gregory Fong wrote:
Quoted 6 lines · Kevin Cernekee
ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of system memory can be located deep in the 36-bit address space. Allow FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains the default.
Signed-off-by Kevin Cernekee <[email protected]>Acked-by Gregory Fong <[email protected]>
Looking at the patch now, I see no reason why this should be tied to ARMv7. Are there any problems we'd expect enabling it for all of ARCH_MULTIPLATFORM?
Arnd
PATCH 1/3 ARM: Add default SPARSEMEM settings
In reply to Kevin CernekeeQuoted 12 lines · Kevin Cernekee
We can still override these settings via
mach/memory.h, but let's provide sensible defaults so that SPARSEMEM is available in the multiplatform kernels.Two platforms currently use
SECTION_SIZE_BITS< 28, but are expected to work with 28 (albeit slightly less efficiently if not all banks are populated):- mach-rpc: uses 26 bits. Based on
mach/hardware.hit looks like this platform puts RAM at 0x1000_0000 - 0x1fff_ffff, and I/O below 0x1000_0000.
Quoted 8 lines
- mach-sa1100: uses 27 bits.
mach/memory.hindicates that RAM occupies the entire range of 0xc000_0000 - 0xdfff_ffff.Several platforms need
MAX_PHYSMEM_BITS>= 36 so we'll pick that as the minimum. Anything higher and we'll fail theSECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTHtest in <linux/mm.h>.Signed-off-by Kevin Cernekee <[email protected]>
PATCH 1/3 ARM: Add default SPARSEMEM settings
Quoted 16 lines · On Friday 31 October 2014 13:11:54 Gregory Fong wrote:
Quoted 15 lines · Kevin Cernekee
We can still override these settings via
mach/memory.h, but let's provide sensible defaults so that SPARSEMEM is available in the multiplatform kernels.Two platforms currently use
SECTION_SIZE_BITS< 28, but are expected to work with 28 (albeit slightly less efficiently if not all banks are populated):- mach-rpc: uses 26 bits. Based on
mach/hardware.hit looks like this platform puts RAM at 0x1000_0000 - 0x1fff_ffff, and I/O below 0x1000_0000.- mach-sa1100: uses 27 bits.
mach/memory.hindicates that RAM occupies the entire range of 0xc000_0000 - 0xdfff_ffff.
Quoted 8 lines
Quoted 5 lines
Several platforms need
MAX_PHYSMEM_BITS>= 36 so we'll pick that as the minimum. Anything higher and we'll fail theSECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTHtest in <linux/mm.h>.Signed-off-by Kevin Cernekee <[email protected]>Acked-by Gregory Fong <[email protected]>
I didn't see this patch originally, just saw the reply. The patch looks good, but it's worth noting in the changelog that rpc and sa1100 will never have to use the default, because they cannot be part of a multiplatform kernel, and that is very unlikely to ever change.
Arnd
PATCH 1/3 ARM: Add default SPARSEMEM settings
In reply to Kevin CernekeeQuoted 30 lines · Kevin Cernekee
We can still override these settings via
mach/memory.h, but let's provide sensible defaults so that SPARSEMEM is available in the multiplatform kernels.Two platforms currently use
SECTION_SIZE_BITS< 28, but are expected to work with 28 (albeit slightly less efficiently if not all banks are populated):- mach-rpc: uses 26 bits. Based on
mach/hardware.hit looks like this platform puts RAM at 0x1000_0000 - 0x1fff_ffff, and I/O below 0x1000_0000.- mach-sa1100: uses 27 bits.
mach/memory.hindicates that RAM occupies the entire range of 0xc000_0000 - 0xdfff_ffff.Several platforms need
MAX_PHYSMEM_BITS>= 36 so we'll pick that as the minimum. Anything higher and we'll fail theSECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTHtest in <linux/mm.h>.Signed-off-by Kevin Cernekee <[email protected]>--- arch/arm/include/asm/sparsemem.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)arch/arm/include/asm/sparsemem.h +0
-0@@ -15,10 +15,11 @@* Eg, if you have 2 banks of up to 64MB at 0x80000000, 0x84000000,
arch/arm/include/asm/sparsemem.h line 22
Quoted 10 lines
arch/arm/include/asm/sparsemem.h +4
-3* then MAX_PHYSMEM_BITS is 32, SECTION_SIZE_BITS is 26. * -* Define these in your mach/memory.h. +* These can be overridden in your mach/memory.h. */ -#if !defined(SECTION_SIZE_BITS ) || !defined(MAX_PHYSMEM_BITS ) -#error Sparsemem is not supported on this platform +#if !defined(MAX_PHYSMEM_BITS ) || !defined(SECTION_SIZE_BITS ) +#define MAX_PHYSMEM_BITS 36 +#define SECTION_SIZE_BITS 28
I think this is fine in as far as it goes - this means we end up with 256 entries in the mem_section array which means it occupies one page, which I think is acceptable overhead.
The other thing to be aware of here is the obvious:
#if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS #error Allocator MAX_ORDER exceeds SECTION_SIZE #endif
Which means that with 28 bits of section, that's a maximum allocator order of 16. We appear to allow FORCE_MAX_ZONEORDER to be set up to 64 in the case of shmobile, which doesn't seem like a sensible upper limit - and certainly isn't when sparsemem is enabled.
Given this, I think that FORCE_MAX_ZONEORDER's help, and the dependencies probably could do with some improvement to make the issues more transparent.
Apart from that, I think this patch is fine. It just would've been nice to have seen some analysis of the impact (like the above) of spreading these parameters over everything.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.