[PATCH 0/3] ARM: Allow SPARSEMEM on multiplatform build

[PATCH 0/3] ARM: Allow SPARSEMEM on multiplatform build

[Gregory Fong]

This is based on the changeset submitted by Kevin Cernekee last September:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286835.html

The changes I have made are:
- update commit messages per review comments from Arnd and Russell
- change to allow FLATMEM or SPARSEMEM on all multiplatform builds, not just
  multi-v7

Gregory Fong (1):
  ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

Kevin Cernekee (2):
  ARM: Add default SPARSEMEM settings
  ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

 arch/arm/Kconfig                 | 8 +++++---
 arch/arm/include/asm/sparsemem.h | 7 ++++---
 2 files changed, 9 insertions(+), 6 deletions(-)

-- 
1.9.1

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

[Gregory Fong]

From: Kevin Cernekee <cernekee@gmail.com>

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.

But Arnd says in that rpc and sa1100 will never have to use the
default since they cannot be part of a multiplatform kernel, and that
is unlikely to change.

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

Some analysis from Russell King at
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298957.html:

  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.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
[gregory.0xf0: added notes from Arnd and Russell]
Signed-off-by: Gregory Fong <gregory.0xf0@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.9.1

[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

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Gregory Fong]

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.

This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
commit message text above.  As Arnd pointed out at [2] there doesn't
seem to be any reason to tie this specifically to ARMv7, so this has
been changed to apply to all multiplatform kernels.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html

Cc: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
---
I don't have any platforms other than armv7 handily set up to test SPARSEMEM,
so any testing would be appreciated.  FLATMEM is still the default so at least
nobody will see anything change unless they deliberately switch.

 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5998b53..21e25bd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -317,6 +317,8 @@ choice
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
 	depends on MMU
+	select ARCH_FLATMEM_ENABLE
+	select ARCH_SPARSEMEM_ENABLE
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT
@@ -1625,6 +1627,9 @@ config OABI_COMPAT
 config ARCH_HAS_HOLES_MEMORYMODEL
 	bool
 
+config ARCH_FLATMEM_ENABLE
+	bool
+
 config ARCH_SPARSEMEM_ENABLE
 	bool
 
-- 
1.9.1

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Arnd Bergmann]

On Thursday 04 June 2015 18:58:38 Gregory Fong 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.
> 
> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
> commit message text above.  As Arnd pointed out at [2] there doesn't
> seem to be any reason to tie this specifically to ARMv7, so this has
> been changed to apply to all multiplatform kernels.
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
> 
> Cc: Kevin Cernekee <cernekee@gmail.com>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> ---
> I don't have any platforms other than armv7 handily set up to test SPARSEMEM,
> so any testing would be appreciated.  FLATMEM is still the default so at least
> nobody will see anything change unless they deliberately switch.
> 

Can you check that realview at least builds with your series? It probably
will, but it's not obvious as there are some tricky bits with the
various realview config options.

	Arnd

[PATCH 3/3] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Gregory Fong]

On Fri, Jun 5, 2015 at 5:26 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 04 June 2015 18:58:38 Gregory Fong 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.
>>
>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
>> commit message text above.  As Arnd pointed out at [2] there doesn't
>> seem to be any reason to tie this specifically to ARMv7, so this has
>> been changed to apply to all multiplatform kernels.
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
>>
>> Cc: Kevin Cernekee <cernekee@gmail.com>
>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
>> ---
>> I don't have any platforms other than armv7 handily set up to test SPARSEMEM,
>> so any testing would be appreciated.  FLATMEM is still the default so at least
>> nobody will see anything change unless they deliberately switch.
>>
>
> Can you check that realview at least builds with your series? It probably
> will, but it's not obvious as there are some tricky bits with the
> various realview config options.

I just checked using realview_defconfig and realview-smp_defconfig,
both built successfully.

Best regards,
Gregory

[PATCH 0/3] ARM: Allow SPARSEMEM on multiplatform build

[Gregory Fong]

On Thu, Jun 4, 2015 at 6:58 PM, Gregory Fong <gregory.0xf0@gmail.com> wrote:
> This is based on the changeset submitted by Kevin Cernekee last September:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286835.html
>
> The changes I have made are:
> - update commit messages per review comments from Arnd and Russell
> - change to allow FLATMEM or SPARSEMEM on all multiplatform builds, not just
>   multi-v7
>
> Gregory Fong (1):
>   ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
>
> Kevin Cernekee (2):
>   ARM: Add default SPARSEMEM settings
>   ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

Russell, should I add these to your patch tracker?

[PATCH 0/3] ARM: Allow SPARSEMEM on multiplatform build

[Stephen Boyd]

On 06/04/2015 06:58 PM, Gregory Fong wrote:
> This is based on the changeset submitted by Kevin Cernekee last September:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286835.html
>
> The changes I have made are:
> - update commit messages per review comments from Arnd and Russell
> - change to allow FLATMEM or SPARSEMEM on all multiplatform builds, not just
>   multi-v7
>
>

Things don't blow up on MSM8960 when switching between flatmem and
sparsemem so feel free to add:

Tested-by: Stephen Boyd <sboyd@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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