[PATCH 1/3] ARM: Add default SPARSEMEM settings

[PATCH 1/3] ARM: Add default SPARSEMEM settings

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

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
 arch/arm/include/asm/sparsemem.h |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/sparsemem.h b/arch/arm/include/asm/sparsemem.h
index 0009861..73e5e85 100644
--- a/arch/arm/include/asm/sparsemem.h
+++ b/arch/arm/include/asm/sparsemem.h
@@ -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
-- 
1.7.9.5

[PATCH 2/3] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Kevin Cernekee]

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.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
 arch/arm/Kconfig |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 32cbbd5..c3daeaf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
 
-- 
1.7.9.5

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build

[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 <cernekee@gmail.com>
---
 arch/arm/Kconfig |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c3daeaf..db7614e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
 
-- 
1.7.9.5

[PATCH 1/3] ARM: Add default SPARSEMEM settings

[Gregory Fong]

On Thu, Sep 11, 2014 at 7:22 PM, Kevin Cernekee <cernekee@gmail.com> wrote:
> 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 at 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>.
>
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>

Acked-by: Gregory Fong <gregory.0xf0@gmail.com>

[PATCH 2/3] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Gregory Fong]

On Thu, Sep 11, 2014 at 7:22 PM, Kevin Cernekee <cernekee@gmail.com> wrote:
> 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.
>
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>

Acked-by: Gregory Fong <gregory.0xf0@gmail.com>

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build

[Gregory Fong]

On Thu, Sep 11, 2014 at 7:22 PM, Kevin Cernekee <cernekee@gmail.com> wrote:
> 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 <cernekee@gmail.com>

Acked-by: Gregory Fong <gregory.0xf0@gmail.com>

[PATCH 1/3] ARM: Add default SPARSEMEM settings

[Arnd Bergmann]

On Friday 31 October 2014 13:11:54 Gregory Fong wrote:
> On Thu, Sep 11, 2014 at 7:22 PM, Kevin Cernekee <cernekee@gmail.com> wrote:
> > 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 at 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>.
> >
> > Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> 
> Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
> 

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.

Acked-by: Arnd Bergmann <arnd@arndb.de>

	Arnd

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multi-v7 build

[Arnd Bergmann]

On Friday 31 October 2014 13:12:46 Gregory Fong wrote:
> On Thu, Sep 11, 2014 at 7:22 PM, Kevin Cernekee <cernekee@gmail.com> wrote:
> > 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 <cernekee@gmail.com>
> 
> Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
> 

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

[Russell King - ARM Linux]

On Thu, Sep 11, 2014 at 07:22:40PM -0700, Kevin Cernekee wrote:
> 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 at 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>.
> 
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> ---
>  arch/arm/include/asm/sparsemem.h |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/sparsemem.h b/arch/arm/include/asm/sparsemem.h
> index 0009861..73e5e85 100644
> --- a/arch/arm/include/asm/sparsemem.h
> +++ b/arch/arm/include/asm/sparsemem.h
> @@ -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

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.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/3] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Gregory Fong]

From: Kevin Cernekee <cernekee@gmail.com>

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.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
---
 arch/arm/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 45df48b..5998b53 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1628,9 +1628,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
 
-- 
1.9.1

[PATCH 2/3] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Arnd Bergmann]

On Thursday 04 June 2015 18:58:37 Gregory Fong wrote:
> From: Kevin Cernekee <cernekee@gmail.com>
> 
> 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.
> 
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> 

Acked-by: Arnd Bergmann <arnd@arndb.de>

It took me a while to understand the logic, but your patch does
make a lot of sense to me now.

	Arnd