[PATCH 0/2] Allow either FLATMEM or SPARSEMEM on the multiplatform build

[PATCH 0/2] Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Florian Fainelli]

Hi all,

This patch series somehow got lost back in 2015, and while looking at
the various patches that we are carrying in our BRCMSTB downstream
kernel those two patches should have made it upstream.

It does not seem to me that much has changed since their original
submissions back in 2015:

https://lkml.org/lkml/2015/6/4/755

where only the first patch made it to Russell's patch tracker.

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

Kevin Cernekee (1):
  ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

 arch/arm/Kconfig | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Florian Fainelli]

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.

Link: https://lkml.org/lkml/2015/6/4/757
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 66a04f6f4775..5986277296c3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1518,9 +1518,6 @@ config ARCH_HAS_HOLES_MEMORYMODEL
 config ARCH_SPARSEMEM_ENABLE
 	bool
 
-config ARCH_SPARSEMEM_DEFAULT
-	def_bool ARCH_SPARSEMEM_ENABLE
-
 config HAVE_ARCH_PFN_VALID
 	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Mike Rapoport]

On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
> 
> Link: https://lkml.org/lkml/2015/6/4/757
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> Signed-off-by: Doug Berger <opendmb@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>

> ---
>  arch/arm/Kconfig | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 66a04f6f4775..5986277296c3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1518,9 +1518,6 @@ config ARCH_HAS_HOLES_MEMORYMODEL
>  config ARCH_SPARSEMEM_ENABLE
>  	bool
>  
> -config ARCH_SPARSEMEM_DEFAULT
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -
>  config HAVE_ARCH_PFN_VALID
>  	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>  
> -- 
> 2.17.1
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Russell King - ARM Linux admin]

On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.

No explanation why that is desirable.

> -config ARCH_SPARSEMEM_DEFAULT
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -

What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
which is exactly what we want for the non-multiplatform boards that
select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
because that is what the platform requires.

For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
0x1c000000.  These correspond with the two memory slots - the first two
for the first slot, and the second two for the second slot.  Each slot
has two banks.  The size of each memory bank depends on the size of the
module.

Flatmem is completely unable to work with this setup if all banks are
populated, and the first bank does not contain enough memory to allocate
the struct page array.  So, sparsemem is the only option there.

Hence, for these platforms, we want sparsemem and only sparsemem, not
flatmem.

So, this patch which makes it possible to select flatmem is completely
out of the question for these platforms.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Florian Fainelli]

On 5/7/2020 3:30 AM, Russell King - ARM Linux admin wrote:
> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
> 
> No explanation why that is desirable.

This was explained in the original submission out of which only the
first patch landed upstream:

https://lkml.org/lkml/2015/6/4/756

> 
>> -config ARCH_SPARSEMEM_DEFAULT
>> -	def_bool ARCH_SPARSEMEM_ENABLE
>> -
> 
> What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
> which is exactly what we want for the non-multiplatform boards that
> select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
> because that is what the platform requires.
> 
> For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
> four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
> 0x1c000000.  These correspond with the two memory slots - the first two
> for the first slot, and the second two for the second slot.  Each slot
> has two banks.  The size of each memory bank depends on the size of the
> module.
> 
> Flatmem is completely unable to work with this setup if all banks are
> populated, and the first bank does not contain enough memory to allocate
> the struct page array.  So, sparsemem is the only option there.
> 
> Hence, for these platforms, we want sparsemem and only sparsemem, not
> flatmem.
> 
> So, this patch which makes it possible to select flatmem is completely
> out of the question for these platforms.

OK.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Russell King - ARM Linux admin]

On Thu, May 07, 2020 at 10:25:16AM -0700, Florian Fainelli wrote:
> 
> 
> On 5/7/2020 3:30 AM, Russell King - ARM Linux admin wrote:
> > On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
> > 
> > No explanation why that is desirable.
> 
> This was explained in the original submission out of which only the
> first patch landed upstream:
> 
> https://lkml.org/lkml/2015/6/4/756

Sorry, I don't see where.  The message you link to is for patch 1.
I'd say that the reason only the first patch landed is because that's
all I was happy with.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Florian Fainelli]

On 5/7/2020 11:50 AM, Russell King - ARM Linux admin wrote:
> On Thu, May 07, 2020 at 10:25:16AM -0700, Florian Fainelli wrote:
>>
>>
>> On 5/7/2020 3:30 AM, Russell King - ARM Linux admin wrote:
>>> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
>>>
>>> No explanation why that is desirable.
>>
>> This was explained in the original submission out of which only the
>> first patch landed upstream:
>>
>> https://lkml.org/lkml/2015/6/4/756
> 
> Sorry, I don't see where.  The message you link to is for patch 1.
> I'd say that the reason only the first patch landed is because that's
> all I was happy with.

I misunderstood you as to why the whole patch series, but now understand
you meant specifically this patch, let me try to dig up some of the
history of this and see if I can provide a justification, else, it
should be dropped.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] arm: use SPARSMEM_STATIC when SPARSEMEM is enabled (Was: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting)

[Mike Rapoport]

On Thu, May 07, 2020 at 11:30:39AM +0100, Russell King - ARM Linux admin wrote:
> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
> 
> No explanation why that is desirable.
> 
> > -config ARCH_SPARSEMEM_DEFAULT
> > -	def_bool ARCH_SPARSEMEM_ENABLE
> > -
> 
> What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
> which is exactly what we want for the non-multiplatform boards that
> select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
> because that is what the platform requires.
>
> For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
> four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
> 0x1c000000.  These correspond with the two memory slots - the first two
> for the first slot, and the second two for the second slot.  Each slot
> has two banks.  The size of each memory bank depends on the size of the
> module.

Out of curiosity I've run 

	make ARCH=arm rpc_defconfig
	grep SPARSEMEM .config

and I was surprised to find out that it has

	CONFIG_SPARSEMEM_EXTREME=y

Which would waste several kilibytes of memory for nothing.
Here is the fix:

From 7097c114226b5b1b2fc6bb605bf0d7eae601cc7f Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Thu, 7 May 2020 22:39:12 +0300
Subject: [PATCH] arm: use SPARSMEM_STATIC when SPARSEMEM is enabled

The commit 3e347261a80b5 ("[PATCH] sparsemem extreme implementation")
made SPARSMEM_EXTREME the default option for configurations that enable
SPARSEMEM.

For ARM systems with handful of memory banks SPARSEMEM_EXTREME is an
overkill.

Ensure that SPARSMEM_STATIC is enabled in the configurations that use
SPARSEMEM.

Fixes: 3e347261a80b5 ("[PATCH] sparsemem extreme implementation")
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 66a04f6f4775..c88a48d622fc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1517,6 +1517,7 @@ config ARCH_HAS_HOLES_MEMORYMODEL
 
 config ARCH_SPARSEMEM_ENABLE
 	bool
+	select SPARSEMEM_STATIC
 
 config ARCH_SPARSEMEM_DEFAULT
 	def_bool ARCH_SPARSEMEM_ENABLE
-- 
2.25.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm: use SPARSMEM_STATIC when SPARSEMEM is enabled (Was: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting)

[Florian Fainelli]

On 5/7/2020 1:08 PM, Mike Rapoport wrote:
> On Thu, May 07, 2020 at 11:30:39AM +0100, Russell King - ARM Linux admin wrote:
>> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
>>
>> No explanation why that is desirable.
>>
>>> -config ARCH_SPARSEMEM_DEFAULT
>>> -	def_bool ARCH_SPARSEMEM_ENABLE
>>> -
>>
>> What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
>> which is exactly what we want for the non-multiplatform boards that
>> select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
>> because that is what the platform requires.
>>
>> For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
>> four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
>> 0x1c000000.  These correspond with the two memory slots - the first two
>> for the first slot, and the second two for the second slot.  Each slot
>> has two banks.  The size of each memory bank depends on the size of the
>> module.
> 
> Out of curiosity I've run 
> 
> 	make ARCH=arm rpc_defconfig
> 	grep SPARSEMEM .config
> 
> and I was surprised to find out that it has
> 
> 	CONFIG_SPARSEMEM_EXTREME=y
> 
> Which would waste several kilibytes of memory for nothing.
> Here is the fix:
> 
> From 7097c114226b5b1b2fc6bb605bf0d7eae601cc7f Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.ibm.com>
> Date: Thu, 7 May 2020 22:39:12 +0300
> Subject: [PATCH] arm: use SPARSMEM_STATIC when SPARSEMEM is enabled
> 
> The commit 3e347261a80b5 ("[PATCH] sparsemem extreme implementation")
> made SPARSMEM_EXTREME the default option for configurations that enable
> SPARSEMEM.
> 
> For ARM systems with handful of memory banks SPARSEMEM_EXTREME is an
> overkill.
> 
> Ensure that SPARSMEM_STATIC is enabled in the configurations that use
> SPARSEMEM.
> 
> Fixes: 3e347261a80b5 ("[PATCH] sparsemem extreme implementation")
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Mike Rapoport]

On Thu, May 07, 2020 at 11:30:39AM +0100, Russell King - ARM Linux admin wrote:
> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
> 
> No explanation why that is desirable.
> 
> > -config ARCH_SPARSEMEM_DEFAULT
> > -	def_bool ARCH_SPARSEMEM_ENABLE
> > -
> 
> What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
> which is exactly what we want for the non-multiplatform boards that
> select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
> because that is what the platform requires.

The ARCH_SPARSEMEM_DEFAULT knob has no effect unless manual selection
of the memory model is enabled, i.e. arch Kconfig sets
ARCH_SELECT_MEMORY_MODEL to 'y'.

Otherwise, ARCH_SPARSEMEM_ENABLE is sufficient to select SPARSEMEM over
FLATMEM:

config SPARSEMEM
	def_bool y
	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL

config FLATMEM
	def_bool y
	depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL

> For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
> four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
> 0x1c000000.  These correspond with the two memory slots - the first two
> for the first slot, and the second two for the second slot.  Each slot
> has two banks.  The size of each memory bank depends on the size of the
> module.
>
> Flatmem is completely unable to work with this setup if all banks are
> populated, and the first bank does not contain enough memory to allocate
> the struct page array.  So, sparsemem is the only option there.
> 
> Hence, for these platforms, we want sparsemem and only sparsemem, not
> flatmem.
> 
> So, this patch which makes it possible to select flatmem is completely
> out of the question for these platforms.

This patch alone won't make it possible to select flatmem for these
platforms, actually, as of now it changes nothing.

The removal of ARCH_SPARSEMEM_DEFAULT will have an effect only with
addtion of ARCH_SELECT_MEMORY_MODEL.

If I understood Florian's intention correctly, the goal was to allow
manual selection of the memory model for multiplatform builds that today
implicitly use flatmem.

I think that the patch below would achieve that without changing the
current defaults and without forcing flatmem on the platforms that
already explicitly select sparsemem.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 66a04f6f4775..b6eb1a28ca27 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -312,6 +312,9 @@ choice
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
 	depends on MMU
+	select ARCH_FLATMEM_ENABLE
+	select ARCH_SPARSEMEM_ENABLE
+	select ARCH_SELECT_MEMORY_MODEL
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT
 	select AUTO_ZRELADDR
@@ -1515,11 +1518,14 @@ config OABI_COMPAT
 config ARCH_HAS_HOLES_MEMORYMODEL
 	bool
 
+config ARCH_FLATMEM_ENABLE
+	bool
+
 config ARCH_SPARSEMEM_ENABLE
 	bool
 
-config ARCH_SPARSEMEM_DEFAULT
-	def_bool ARCH_SPARSEMEM_ENABLE
+config ARCH_SELECT_MEMORY_MODEL
+	bool
 
 config HAVE_ARCH_PFN_VALID
 	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM

> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Florian Fainelli]

On 5/7/2020 1:29 PM, Mike Rapoport wrote:
> On Thu, May 07, 2020 at 11:30:39AM +0100, Russell King - ARM Linux admin wrote:
>> On Wed, May 06, 2020 at 04:50:08PM -0700, Florian Fainelli 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.
>>
>> No explanation why that is desirable.
>>
>>> -config ARCH_SPARSEMEM_DEFAULT
>>> -	def_bool ARCH_SPARSEMEM_ENABLE
>>> -
>>
>> What this basically says is ARCH_SPARSEMEM_ENABLE=ARCH_SPARSEMEM_DEFAULT,
>> which is exactly what we want for the non-multiplatform boards that
>> select ARCH_SPARSEMEM_ENABLE - we _want_ them to default to sparsemem
>> because that is what the platform requires.
> 
> The ARCH_SPARSEMEM_DEFAULT knob has no effect unless manual selection
> of the memory model is enabled, i.e. arch Kconfig sets
> ARCH_SELECT_MEMORY_MODEL to 'y'.
> 
> Otherwise, ARCH_SPARSEMEM_ENABLE is sufficient to select SPARSEMEM over
> FLATMEM:
> 
> config SPARSEMEM
> 	def_bool y
> 	depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL
> 
> config FLATMEM
> 	def_bool y
> 	depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL
> 
>> For example, with RiscPC, which selects ARCH_SPARSEMEM_ENABLE, we have
>> four banks of memory at 0x10000000, 0x14000000, 0x18000000 and
>> 0x1c000000.  These correspond with the two memory slots - the first two
>> for the first slot, and the second two for the second slot.  Each slot
>> has two banks.  The size of each memory bank depends on the size of the
>> module.
>>
>> Flatmem is completely unable to work with this setup if all banks are
>> populated, and the first bank does not contain enough memory to allocate
>> the struct page array.  So, sparsemem is the only option there.
>>
>> Hence, for these platforms, we want sparsemem and only sparsemem, not
>> flatmem.
>>
>> So, this patch which makes it possible to select flatmem is completely
>> out of the question for these platforms.
> 
> This patch alone won't make it possible to select flatmem for these
> platforms, actually, as of now it changes nothing.
> 
> The removal of ARCH_SPARSEMEM_DEFAULT will have an effect only with
> addtion of ARCH_SELECT_MEMORY_MODEL.
> 
> If I understood Florian's intention correctly, the goal was to allow
> manual selection of the memory model for multiplatform builds that today
> implicitly use flatmem.

That is correct.

> 
> I think that the patch below would achieve that without changing the
> current defaults and without forcing flatmem on the platforms that
> already explicitly select sparsemem.

Agree, with your patch, we have the following:

mutli_v7_defonfig -> FLATMEM
ep93xx_defconfig -> SPARSEMEM
rpc_defconfig -> SPARSEMEM
assabet_defconfig -> SPARSEMEM

with the bonus that when you run menuconfig you can now select sparsemem
for a multi-platform build, which was the intention.

Tested-by: Florian Fainelli <f.fainelli@gmail.com>


> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 66a04f6f4775..b6eb1a28ca27 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -312,6 +312,9 @@ choice
>  config ARCH_MULTIPLATFORM
>  	bool "Allow multiple platforms to be selected"
>  	depends on MMU
> +	select ARCH_FLATMEM_ENABLE
> +	select ARCH_SPARSEMEM_ENABLE
> +	select ARCH_SELECT_MEMORY_MODEL
>  	select ARM_HAS_SG_CHAIN
>  	select ARM_PATCH_PHYS_VIRT
>  	select AUTO_ZRELADDR
> @@ -1515,11 +1518,14 @@ config OABI_COMPAT
>  config ARCH_HAS_HOLES_MEMORYMODEL
>  	bool
>  
> +config ARCH_FLATMEM_ENABLE
> +	bool
> +
>  config ARCH_SPARSEMEM_ENABLE
>  	bool
>  
> -config ARCH_SPARSEMEM_DEFAULT
> -	def_bool ARCH_SPARSEMEM_ENABLE
> +config ARCH_SELECT_MEMORY_MODEL
> +	bool
>  
>  config HAVE_ARCH_PFN_VALID
>  	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
> 
>> -- 
>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
> 

-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Mike Rapoport]

On Thu, May 07, 2020 at 01:47:57PM -0700, Florian Fainelli wrote:
> 
> On 5/7/2020 1:29 PM, Mike Rapoport wrote:

...

> > If I understood Florian's intention correctly, the goal was to allow
> > manual selection of the memory model for multiplatform builds that today
> > implicitly use flatmem.
> 
> That is correct.
> 
> > 
> > I think that the patch below would achieve that without changing the
> > current defaults and without forcing flatmem on the platforms that
> > already explicitly select sparsemem.
> 
> Agree, with your patch, we have the following:
> 
> mutli_v7_defonfig -> FLATMEM
> ep93xx_defconfig -> SPARSEMEM
> rpc_defconfig -> SPARSEMEM
> assabet_defconfig -> SPARSEMEM
> 
> with the bonus that when you run menuconfig you can now select sparsemem
> for a multi-platform build, which was the intention.

If there is a need to use sparsemem for the multiplatform build, then
maybe we should consider moving to sparsemem?

The increase in size for the defconfig build is about 7k and some of if
is accounted for the .init code and data:

   text    data     bss     dec     hex filename
14539957        7461462  413288 22414707        1560573 vmlinux-flatmem
14545233        7461762  415400 22422395        156237b vmlinux-sparse-static

I don't have ARM hardware, so I cannot measure the run-time effect though. 


> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
 
Thanks!

> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 66a04f6f4775..b6eb1a28ca27 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -312,6 +312,9 @@ choice
> >  config ARCH_MULTIPLATFORM
> >  	bool "Allow multiple platforms to be selected"
> >  	depends on MMU
> > +	select ARCH_FLATMEM_ENABLE
> > +	select ARCH_SPARSEMEM_ENABLE
> > +	select ARCH_SELECT_MEMORY_MODEL
> >  	select ARM_HAS_SG_CHAIN
> >  	select ARM_PATCH_PHYS_VIRT
> >  	select AUTO_ZRELADDR
> > @@ -1515,11 +1518,14 @@ config OABI_COMPAT
> >  config ARCH_HAS_HOLES_MEMORYMODEL
> >  	bool
> >  
> > +config ARCH_FLATMEM_ENABLE
> > +	bool
> > +
> >  config ARCH_SPARSEMEM_ENABLE
> >  	bool
> >  
> > -config ARCH_SPARSEMEM_DEFAULT
> > -	def_bool ARCH_SPARSEMEM_ENABLE
> > +config ARCH_SELECT_MEMORY_MODEL
> > +	bool
> >  
> >  config HAVE_ARCH_PFN_VALID
> >  	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
> > 
> >> -- 
> >> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> >> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
> > 
> 
> -- 
> Florian

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

[Florian Fainelli]

On 5/8/2020 2:41 PM, Mike Rapoport wrote:
> On Thu, May 07, 2020 at 01:47:57PM -0700, Florian Fainelli wrote:
>>
>> On 5/7/2020 1:29 PM, Mike Rapoport wrote:
> 
> ...
> 
>>> If I understood Florian's intention correctly, the goal was to allow
>>> manual selection of the memory model for multiplatform builds that today
>>> implicitly use flatmem.
>>
>> That is correct.
>>
>>>
>>> I think that the patch below would achieve that without changing the
>>> current defaults and without forcing flatmem on the platforms that
>>> already explicitly select sparsemem.
>>
>> Agree, with your patch, we have the following:
>>
>> mutli_v7_defonfig -> FLATMEM
>> ep93xx_defconfig -> SPARSEMEM
>> rpc_defconfig -> SPARSEMEM
>> assabet_defconfig -> SPARSEMEM
>>
>> with the bonus that when you run menuconfig you can now select sparsemem
>> for a multi-platform build, which was the intention.
> 
> If there is a need to use sparsemem for the multiplatform build, then
> maybe we should consider moving to sparsemem?

For ARCH_BRCMSTB we definitively want sparsemem (hence these patches)
because of the memory map for those chips, but not having access to all
ARM platforms that are supported by the multi-platform kernel, I would
rather we stay conservative and allow platforms to select the memory
model they want. If it turns out that sparsemem is the default, I
suppose we could always change it later on. Arnd, Russell, what do you
think?

> > The increase in size for the defconfig build is about 7k and some of if
> is accounted for the .init code and data:
> 
>    text    data     bss     dec     hex filename
> 14539957        7461462  413288 22414707        1560573 vmlinux-flatmem
> 14545233        7461762  415400 22422395        156237b vmlinux-sparse-static
> 
> I don't have ARM hardware, so I cannot measure the run-time effect though. 
> 
> 
>> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>  
> Thanks!
> 
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 66a04f6f4775..b6eb1a28ca27 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -312,6 +312,9 @@ choice
>>>  config ARCH_MULTIPLATFORM
>>>  	bool "Allow multiple platforms to be selected"
>>>  	depends on MMU
>>> +	select ARCH_FLATMEM_ENABLE
>>> +	select ARCH_SPARSEMEM_ENABLE
>>> +	select ARCH_SELECT_MEMORY_MODEL
>>>  	select ARM_HAS_SG_CHAIN
>>>  	select ARM_PATCH_PHYS_VIRT
>>>  	select AUTO_ZRELADDR
>>> @@ -1515,11 +1518,14 @@ config OABI_COMPAT
>>>  config ARCH_HAS_HOLES_MEMORYMODEL
>>>  	bool
>>>  
>>> +config ARCH_FLATMEM_ENABLE
>>> +	bool
>>> +
>>>  config ARCH_SPARSEMEM_ENABLE
>>>  	bool
>>>  
>>> -config ARCH_SPARSEMEM_DEFAULT
>>> -	def_bool ARCH_SPARSEMEM_ENABLE
>>> +config ARCH_SELECT_MEMORY_MODEL
>>> +	bool
>>>  
>>>  config HAVE_ARCH_PFN_VALID
>>>  	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>>>
>>>> -- 
>>>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>>>> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
>>>
>>
>> -- 
>> Florian
> 

-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Florian Fainelli]

From: Gregory Fong <gregory.0xf0@gmail.com>

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>
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5986277296c3..7bb5264a9c3a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -312,6 +312,8 @@ choice
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
 	depends on MMU
+	select ARCH_FLATMEM_ENABLE
+	select ARCH_SPARSEMEM_ENABLE
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT
 	select AUTO_ZRELADDR
@@ -1515,6 +1517,9 @@ config OABI_COMPAT
 config ARCH_HAS_HOLES_MEMORYMODEL
 	bool
 
+config ARCH_FLATMEM_ENABLE
+	bool
+
 config ARCH_SPARSEMEM_ENABLE
 	bool
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mike Rapoport]

On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> From: Gregory Fong <gregory.0xf0@gmail.com>
> 
> 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>
> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> Signed-off-by: Doug Berger <opendmb@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>  arch/arm/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5986277296c3..7bb5264a9c3a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -312,6 +312,8 @@ choice
>  config ARCH_MULTIPLATFORM
>  	bool "Allow multiple platforms to be selected"
>  	depends on MMU
> +	select ARCH_FLATMEM_ENABLE
> +	select ARCH_SPARSEMEM_ENABLE

The logic in mm/Kconfig is quite convoluted, so selecting
ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.

On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
something like:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7bb5264a9c3a..b6eb1a28ca27 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -314,6 +314,7 @@ config ARCH_MULTIPLATFORM
 	depends on MMU
 	select ARCH_FLATMEM_ENABLE
 	select ARCH_SPARSEMEM_ENABLE
+	select ARCH_SELECT_MEMORY_MODEL
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT
 	select AUTO_ZRELADDR
@@ -1523,6 +1524,9 @@ config ARCH_FLATMEM_ENABLE
 config ARCH_SPARSEMEM_ENABLE
 	bool
 
+config ARCH_SELECT_MEMORY_MODEL
+	bool
+
 config HAVE_ARCH_PFN_VALID
 	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
>  	select ARM_HAS_SG_CHAIN
>  	select ARM_PATCH_PHYS_VIRT
>  	select AUTO_ZRELADDR
> @@ -1515,6 +1517,9 @@ config OABI_COMPAT
>  config ARCH_HAS_HOLES_MEMORYMODEL
>  	bool
>  
> +config ARCH_FLATMEM_ENABLE
> +	bool
> +
>  config ARCH_SPARSEMEM_ENABLE
>  	bool
>  
> -- 
> 2.17.1
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Florian Fainelli]

On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
>> From: Gregory Fong <gregory.0xf0@gmail.com>
>>
>> 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>
>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>>  arch/arm/Kconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5986277296c3..7bb5264a9c3a 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -312,6 +312,8 @@ choice
>>  config ARCH_MULTIPLATFORM
>>  	bool "Allow multiple platforms to be selected"
>>  	depends on MMU
>> +	select ARCH_FLATMEM_ENABLE
>> +	select ARCH_SPARSEMEM_ENABLE
> 
> The logic in mm/Kconfig is quite convoluted, so selecting
> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> 
> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> something like:

Yes indeed, thanks that does allow me to select between flatmem and
sparsemem from menuconfig correctly now.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Florian Fainelli]

On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> 
> 
> On 5/7/2020 12:27 AM, Mike Rapoport wrote:
>> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
>>> From: Gregory Fong <gregory.0xf0@gmail.com>
>>>
>>> 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>
>>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
>>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>>  arch/arm/Kconfig | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 5986277296c3..7bb5264a9c3a 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -312,6 +312,8 @@ choice
>>>  config ARCH_MULTIPLATFORM
>>>  	bool "Allow multiple platforms to be selected"
>>>  	depends on MMU
>>> +	select ARCH_FLATMEM_ENABLE
>>> +	select ARCH_SPARSEMEM_ENABLE
>>
>> The logic in mm/Kconfig is quite convoluted, so selecting
>> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
>>
>> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
>> something like:
> 
> Yes indeed, thanks that does allow me to select between flatmem and
> sparsemem from menuconfig correctly now.

Mike, do you want to make a formal submission to Russell's patch
tracker? If so, feel free to add:

Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mike Rapoport]

On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> 
> 
> On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > 
> > 
> > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> >>>
> >>> 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>
> >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >>> ---
> >>>  arch/arm/Kconfig | 5 +++++
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index 5986277296c3..7bb5264a9c3a 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -312,6 +312,8 @@ choice
> >>>  config ARCH_MULTIPLATFORM
> >>>  	bool "Allow multiple platforms to be selected"
> >>>  	depends on MMU
> >>> +	select ARCH_FLATMEM_ENABLE
> >>> +	select ARCH_SPARSEMEM_ENABLE
> >>
> >> The logic in mm/Kconfig is quite convoluted, so selecting
> >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> >>
> >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> >> something like:
> > 
> > Yes indeed, thanks that does allow me to select between flatmem and
> > sparsemem from menuconfig correctly now.
> 
> Mike, do you want to make a formal submission to Russell's patch
> tracker? If so, feel free to add:

I actually hoped to hear from people what do they think about switching
over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
it would make sense.

Russel, Arnd, can you comment please?

> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Thanks!
> --
> Florian

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Arnd Bergmann]

On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > >>>
> > >>> 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>
> > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > >>> ---
> > >>>  arch/arm/Kconfig | 5 +++++
> > >>>  1 file changed, 5 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>> index 5986277296c3..7bb5264a9c3a 100644
> > >>> --- a/arch/arm/Kconfig
> > >>> +++ b/arch/arm/Kconfig
> > >>> @@ -312,6 +312,8 @@ choice
> > >>>  config ARCH_MULTIPLATFORM
> > >>>   bool "Allow multiple platforms to be selected"
> > >>>   depends on MMU
> > >>> + select ARCH_FLATMEM_ENABLE
> > >>> + select ARCH_SPARSEMEM_ENABLE
> > >>
> > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > >>
> > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > >> something like:
> > >
> > > Yes indeed, thanks that does allow me to select between flatmem and
> > > sparsemem from menuconfig correctly now.
> >
> > Mike, do you want to make a formal submission to Russell's patch
> > tracker? If so, feel free to add:
>
> I actually hoped to hear from people what do they think about switching
> over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> it would make sense.

It seems that at least s5p/exynos and clps711x (armv4) used to default to
sparsemem, and that got lost in the multiplatform conversion.

I also see discontiguous memory ranges in multiple broadcom chips,
on TI dm8168, ecx-2000 and imx.

> Russel, Arnd, can you comment please?

I see no problem with giving users the choice for all multiplatform
builds. No idea on what the default should be really, i.e. whether
only v7 configurations should make it the default, or rather none of
them or all of them.

Maybe lets leave the default unchanged with flatmem but enable it
in multi_v7_defconfig and the configurations for chips that are known
to have discontiguous memory (clps, bcm, imx, exynos, ...).

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mike Rapoport]

On Tue, May 19, 2020 at 09:59:48AM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > > >>>
> > > >>> 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>
> > > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > >>> ---
> > > >>>  arch/arm/Kconfig | 5 +++++
> > > >>>  1 file changed, 5 insertions(+)
> > > >>>
> > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > >>> index 5986277296c3..7bb5264a9c3a 100644
> > > >>> --- a/arch/arm/Kconfig
> > > >>> +++ b/arch/arm/Kconfig
> > > >>> @@ -312,6 +312,8 @@ choice
> > > >>>  config ARCH_MULTIPLATFORM
> > > >>>   bool "Allow multiple platforms to be selected"
> > > >>>   depends on MMU
> > > >>> + select ARCH_FLATMEM_ENABLE
> > > >>> + select ARCH_SPARSEMEM_ENABLE
> > > >>
> > > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > > >>
> > > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > > >> something like:
> > > >
> > > > Yes indeed, thanks that does allow me to select between flatmem and
> > > > sparsemem from menuconfig correctly now.
> > >
> > > Mike, do you want to make a formal submission to Russell's patch
> > > tracker? If so, feel free to add:
> >
> > I actually hoped to hear from people what do they think about switching
> > over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> > it would make sense.
> 
> It seems that at least s5p/exynos and clps711x (armv4) used to default to
> sparsemem, and that got lost in the multiplatform conversion.
> 
> I also see discontiguous memory ranges in multiple broadcom chips,
> on TI dm8168, ecx-2000 and imx.
> 
> > Russel, Arnd, can you comment please?
> 
> I see no problem with giving users the choice for all multiplatform
> builds. No idea on what the default should be really, i.e. whether
> only v7 configurations should make it the default, or rather none of
> them or all of them.

Me neither :)

I'd say let's move forward with letting user select the memory model for
all multiplaform builds and keep flatmem the default.

Enabling sparsemem (with SPARSEMEM_STATIC) for defconfig build increases
the kernel nearly by 8k and most probably will make things slower.


> Maybe lets leave the default unchanged with flatmem but enable it in
> multi_v7_defconfig and the configurations for chips that are known
> to have discontiguous memory (clps, bcm, imx, exynos, ...).
>
>       Arnd

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Russell King - ARM Linux admin]

On Tue, May 19, 2020 at 05:43:06PM +0300, Mike Rapoport wrote:
> On Tue, May 19, 2020 at 09:59:48AM +0200, Arnd Bergmann wrote:
> > On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > > > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > > > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > > > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > > > >>>
> > > > >>> 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>
> > > > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > > > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > > > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > > > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > > >>> ---
> > > > >>>  arch/arm/Kconfig | 5 +++++
> > > > >>>  1 file changed, 5 insertions(+)
> > > > >>>
> > > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > >>> index 5986277296c3..7bb5264a9c3a 100644
> > > > >>> --- a/arch/arm/Kconfig
> > > > >>> +++ b/arch/arm/Kconfig
> > > > >>> @@ -312,6 +312,8 @@ choice
> > > > >>>  config ARCH_MULTIPLATFORM
> > > > >>>   bool "Allow multiple platforms to be selected"
> > > > >>>   depends on MMU
> > > > >>> + select ARCH_FLATMEM_ENABLE
> > > > >>> + select ARCH_SPARSEMEM_ENABLE
> > > > >>
> > > > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > > > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > > > >>
> > > > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > > > >> something like:
> > > > >
> > > > > Yes indeed, thanks that does allow me to select between flatmem and
> > > > > sparsemem from menuconfig correctly now.
> > > >
> > > > Mike, do you want to make a formal submission to Russell's patch
> > > > tracker? If so, feel free to add:
> > >
> > > I actually hoped to hear from people what do they think about switching
> > > over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> > > it would make sense.
> > 
> > It seems that at least s5p/exynos and clps711x (armv4) used to default to
> > sparsemem, and that got lost in the multiplatform conversion.
> > 
> > I also see discontiguous memory ranges in multiple broadcom chips,
> > on TI dm8168, ecx-2000 and imx.
> > 
> > > Russel, Arnd, can you comment please?
> > 
> > I see no problem with giving users the choice for all multiplatform
> > builds. No idea on what the default should be really, i.e. whether
> > only v7 configurations should make it the default, or rather none of
> > them or all of them.
> 
> Me neither :)
> 
> I'd say let's move forward with letting user select the memory model for
> all multiplaform builds and keep flatmem the default.
> 
> Enabling sparsemem (with SPARSEMEM_STATIC) for defconfig build increases
> the kernel nearly by 8k and most probably will make things slower.

I think when selecting the default, you need to consider whether
platforms can boot with that default configuration or not.

There are cases where the reason to use sparsemem is not an optional
one but is out of necessity - they require the page array to be split
up in order to boot successfully.

With that in mind, flatmem becomes an "optimisation" over sparsemem.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mike Rapoport]

On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 05:43:06PM +0300, Mike Rapoport wrote:
> > On Tue, May 19, 2020 at 09:59:48AM +0200, Arnd Bergmann wrote:
> > > On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > > On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > > > >
> > > > > Mike, do you want to make a formal submission to Russell's patch
> > > > > tracker? If so, feel free to add:
> > > >
> > > > I actually hoped to hear from people what do they think about switching
> > > > over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> > > > it would make sense.
> > > 
> > > It seems that at least s5p/exynos and clps711x (armv4) used to default to
> > > sparsemem, and that got lost in the multiplatform conversion.
> > > 
> > > I also see discontiguous memory ranges in multiple broadcom chips,
> > > on TI dm8168, ecx-2000 and imx.
> > > 
> > > > Russel, Arnd, can you comment please?
> > > 
> > > I see no problem with giving users the choice for all multiplatform
> > > builds. No idea on what the default should be really, i.e. whether
> > > only v7 configurations should make it the default, or rather none of
> > > them or all of them.
> > 
> > Me neither :)
> > 
> > I'd say let's move forward with letting user select the memory model for
> > all multiplaform builds and keep flatmem the default.
> > 
> > Enabling sparsemem (with SPARSEMEM_STATIC) for defconfig build increases
> > the kernel nearly by 8k and most probably will make things slower.
> 
> I think when selecting the default, you need to consider whether
> platforms can boot with that default configuration or not.
> 
> There are cases where the reason to use sparsemem is not an optional
> one but is out of necessity - they require the page array to be split
> up in order to boot successfully.
> 
> With that in mind, flatmem becomes an "optimisation" over sparsemem.

At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX, 
ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.

I do not intend to change that, I am only going add an ability to select
the memory model for ARCH_MULTIPLATFORM. 

I'll respin the series on the list before adding the patches to the
patch system.

> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Arnd Bergmann]

On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
> > There are cases where the reason to use sparsemem is not an optional
> > one but is out of necessity - they require the page array to be split
> > up in order to boot successfully.
> >
> > With that in mind, flatmem becomes an "optimisation" over sparsemem.
>
> At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
> ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
>
> I do not intend to change that, I am only going add an ability to select
> the memory model for ARCH_MULTIPLATFORM.
>
> I'll respin the series on the list before adding the patches to the
> patch system.

I think we'll make EP93xx part of multiplatform at some point, IIRC
only the missing clock driver is stopping us at the moment, and I already
discussed with Linus Walleij how that can be done.

My guess is that ep93xx is one platform on which sparsemem is
just an optimization to reduce the initial memory consumption, but
we should verify that when we get there.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Russell King - ARM Linux admin]

On Tue, May 19, 2020 at 05:32:52PM +0200, Arnd Bergmann wrote:
> On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
> > > There are cases where the reason to use sparsemem is not an optional
> > > one but is out of necessity - they require the page array to be split
> > > up in order to boot successfully.
> > >
> > > With that in mind, flatmem becomes an "optimisation" over sparsemem.
> >
> > At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
> > ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
> >
> > I do not intend to change that, I am only going add an ability to select
> > the memory model for ARCH_MULTIPLATFORM.
> >
> > I'll respin the series on the list before adding the patches to the
> > patch system.
> 
> I think we'll make EP93xx part of multiplatform at some point, IIRC
> only the missing clock driver is stopping us at the moment, and I already
> discussed with Linus Walleij how that can be done.
> 
> My guess is that ep93xx is one platform on which sparsemem is
> just an optimization to reduce the initial memory consumption, but
> we should verify that when we get there.

When you have a platform where the memory is segmented into separate
blocks widely spaced, sparsemem is not an optimisation.  For example,
If you have four blocks spaced across 1GB, that requires about
256Ki struct page's.  Assuming 32 byte struct page, that requires 8MiB
of contiguous memory.

If we also consider the other constraint - that the kernel has to fit
in the first bank of memory, then, considering the size of the kernel
(the first two are non-multiplatform kernels):

text     data   bss      dec      hex      filename
4045505  903700   92984  5042189  4cf00d   n2100/boot/vmlinux-5.6.12+
4045361  957276 1159052  6161689  5e0519   assabet/boot/vmlinux-5.2.0+
6933363 1451420  203984  8588767  830ddf   virt/boot/vmlinux-5.6.0+
9980260 3568070 7403296 20951626 13fb24a   multi/boot/vmlinux-5.3.0+

So, realistically, we're looking at imposing a requirement that the
first bank of memory is no smaller than 16MB on these machines if a
"default" flatmem multiplatform kernel is going to be able to boot,
and if all banks are populated, that there is another bank that has
at least 8MB to hold the memmap array.

BTW, the "optimisation" argument for sparsemem doesn't actually
hold.  For flatmem, we free the unused parts of the memmap array,
freeing those pages for other uses.  Sparsemem on ARM is about
allowing these platforms to boot with their memory spread across
the physical address space savannah.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mike Rapoport]

Hi Russell,

On Tue, May 19, 2020 at 05:54:45PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 05:32:52PM +0200, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
> > > > There are cases where the reason to use sparsemem is not an optional
> > > > one but is out of necessity - they require the page array to be split
> > > > up in order to boot successfully.
> > > >
> > > > With that in mind, flatmem becomes an "optimisation" over sparsemem.
> > >
> > > At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
> > > ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
> > >
> > > I do not intend to change that, I am only going add an ability to select
> > > the memory model for ARCH_MULTIPLATFORM.
> > >
> > > I'll respin the series on the list before adding the patches to the
> > > patch system.
> > 
> > I think we'll make EP93xx part of multiplatform at some point, IIRC
> > only the missing clock driver is stopping us at the moment, and I already
> > discussed with Linus Walleij how that can be done.
> > 
> > My guess is that ep93xx is one platform on which sparsemem is
> > just an optimization to reduce the initial memory consumption, but
> > we should verify that when we get there.
> 
> When you have a platform where the memory is segmented into separate
> blocks widely spaced, sparsemem is not an optimisation.  For example,
> If you have four blocks spaced across 1GB, that requires about
> 256Ki struct page's.  Assuming 32 byte struct page, that requires 8MiB
> of contiguous memory.
> 
> If we also consider the other constraint - that the kernel has to fit
> in the first bank of memory, then, considering the size of the kernel
> (the first two are non-multiplatform kernels):
> 
> text     data   bss      dec      hex      filename
> 4045505  903700   92984  5042189  4cf00d   n2100/boot/vmlinux-5.6.12+
> 4045361  957276 1159052  6161689  5e0519   assabet/boot/vmlinux-5.2.0+
> 6933363 1451420  203984  8588767  830ddf   virt/boot/vmlinux-5.6.0+
> 9980260 3568070 7403296 20951626 13fb24a   multi/boot/vmlinux-5.3.0+
> 
> So, realistically, we're looking at imposing a requirement that the
> first bank of memory is no smaller than 16MB on these machines if a
> "default" flatmem multiplatform kernel is going to be able to boot,
> and if all banks are populated, that there is another bank that has
> at least 8MB to hold the memmap array.
> 
> BTW, the "optimisation" argument for sparsemem doesn't actually
> hold.  For flatmem, we free the unused parts of the memmap array,
> freeing those pages for other uses.  Sparsemem on ARM is about
> allowing these platforms to boot with their memory spread across
> the physical address space savannah.

There is no argument that sparsemem is more robust and flexible in its
ability to hande separated memory banks. And, AFAIU, nobody suggests to
start using flatmem instead of sparsemem on any machine.

Currently, when you build the kernel with "make defconfig && make" or
"make multi_X_defconfig && make" kconfig implicitly selects flatmem and
there is no possiblity to enable sparsemem in the menuconfig.

Florian sent the pathces with the purpose to allow overriding the
explict choise of flatmem with sparsemem in menuconfig.

At some point I've asked whether we would like to use sparsemem instead
of flatmem as the default for the multiplafrom build. The upside of such
change is the robustness you described above. The downside is a bit
larger kernel image and slight slow down in page_to_pfn and pfn_to_page.

That said we have two options:
* Massage the patches Florian sent and add ability to select memory
model in menuconfig for the multiplatform builds without changing
anything in configurations that were not manually atered.
* Simply add 'select ARCH_SPAPSEMEM_ENABLE' under 'ARCH_MULTIPLAFROM'
and force all multiplatform builds to use sparsemem.

So the question is what is the preferred way to move forward.

> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Arnd Bergmann]

On Tue, May 19, 2020 at 6:54 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, May 19, 2020 at 05:32:52PM +0200, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
> > > > There are cases where the reason to use sparsemem is not an optional
> > > > one but is out of necessity - they require the page array to be split
> > > > up in order to boot successfully.
> > > >
> > > > With that in mind, flatmem becomes an "optimisation" over sparsemem.
> > >
> > > At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
> > > ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
> > >
> > > I do not intend to change that, I am only going add an ability to select
> > > the memory model for ARCH_MULTIPLATFORM.
> > >
> > > I'll respin the series on the list before adding the patches to the
> > > patch system.
> >
> > I think we'll make EP93xx part of multiplatform at some point, IIRC
> > only the missing clock driver is stopping us at the moment, and I already
> > discussed with Linus Walleij how that can be done.
> >
> > My guess is that ep93xx is one platform on which sparsemem is
> > just an optimization to reduce the initial memory consumption, but
> > we should verify that when we get there.
>
> When you have a platform where the memory is segmented into separate
> blocks widely spaced, sparsemem is not an optimisation.  For example,
> If you have four blocks spaced across 1GB, that requires about
> 256Ki struct page's.  Assuming 32 byte struct page, that requires 8MiB
> of contiguous memory.

I checked the datasheet: ep93xx has four chip-selects, each of them
with their own 256MB memory area. Most boards we support use only
the last chipselect, but those that have more than one would waste
up to 2MB per additional memory chip, which is not nice but doesn't
make it a hard requirement as long as the kernel can fit into the first one.

However, the chips has a second problem: depending on the
specific memory configuration, only every other 2/4/8MB within
that range may actually be used, so the mem_map[] array would
double its size in practice and (worse) the kernel would likely
not fit into the first section without sparsemem.

This means we should indeed treat it as a requirement for ep93xx.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Florian Fainelli]

On 5/19/2020 1:42 PM, Arnd Bergmann wrote:
> On Tue, May 19, 2020 at 6:54 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>> On Tue, May 19, 2020 at 05:32:52PM +0200, Arnd Bergmann wrote:
>>> On Tue, May 19, 2020 at 5:27 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>>>> On Tue, May 19, 2020 at 04:04:52PM +0100, Russell King - ARM Linux admin wrote:
>>>>> There are cases where the reason to use sparsemem is not an optional
>>>>> one but is out of necessity - they require the page array to be split
>>>>> up in order to boot successfully.
>>>>>
>>>>> With that in mind, flatmem becomes an "optimisation" over sparsemem.
>>>>
>>>> At the moment, there are three platforms that enable SPARSEMEM: ARCH_EP93XX,
>>>> ARCH_RPC and ARCH_SA1100. All the rest have FLATMEM implcitly selected.
>>>>
>>>> I do not intend to change that, I am only going add an ability to select
>>>> the memory model for ARCH_MULTIPLATFORM.
>>>>
>>>> I'll respin the series on the list before adding the patches to the
>>>> patch system.
>>>
>>> I think we'll make EP93xx part of multiplatform at some point, IIRC
>>> only the missing clock driver is stopping us at the moment, and I already
>>> discussed with Linus Walleij how that can be done.
>>>
>>> My guess is that ep93xx is one platform on which sparsemem is
>>> just an optimization to reduce the initial memory consumption, but
>>> we should verify that when we get there.
>>
>> When you have a platform where the memory is segmented into separate
>> blocks widely spaced, sparsemem is not an optimisation.  For example,
>> If you have four blocks spaced across 1GB, that requires about
>> 256Ki struct page's.  Assuming 32 byte struct page, that requires 8MiB
>> of contiguous memory.
> 
> I checked the datasheet: ep93xx has four chip-selects, each of them
> with their own 256MB memory area. Most boards we support use only
> the last chipselect, but those that have more than one would waste
> up to 2MB per additional memory chip, which is not nice but doesn't
> make it a hard requirement as long as the kernel can fit into the first one.
> 
> However, the chips has a second problem: depending on the
> specific memory configuration, only every other 2/4/8MB within
> that range may actually be used, so the mem_map[] array would
> double its size in practice and (worse) the kernel would likely
> not fit into the first section without sparsemem.
> 
> This means we should indeed treat it as a requirement for ep93xx.

That is already captured with the select ARCH_SPARSEMEM_ENABLE or the
ARCH_EP93XX entry.

Should we just make it possible for multi platform users to override the
memory model in their configuration file and later we just default
ARCH_MULTI_V7 to sparsemem?
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Arnd Bergmann]

On Thu, May 21, 2020 at 4:45 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 5/19/2020 1:42 PM, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 6:54 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> >
> > I checked the datasheet: ep93xx has four chip-selects, each of them
> > with their own 256MB memory area. Most boards we support use only
> > the last chipselect, but those that have more than one would waste
> > up to 2MB per additional memory chip, which is not nice but doesn't
> > make it a hard requirement as long as the kernel can fit into the first one.
> >
> > However, the chips has a second problem: depending on the
> > specific memory configuration, only every other 2/4/8MB within
> > that range may actually be used, so the mem_map[] array would
> > double its size in practice and (worse) the kernel would likely
> > not fit into the first section without sparsemem.
> >
> > This means we should indeed treat it as a requirement for ep93xx.
>
> That is already captured with the select ARCH_SPARSEMEM_ENABLE or the
> ARCH_EP93XX entry.

Yes, we just need to keep it that way when ep93xx eventually
becomes part of the ARCH_MULTI_V4T configuration.

> Should we just make it possible for multi platform users to override the
> memory model in their configuration file and later we just default
> ARCH_MULTI_V7 to sparsemem?

I think there are three steps:

1. make the memory model user-selectable for all multiplatform kernels
   to allow sparsemem
2. change the defconfig files for platforms that would likely benefit
  (multi_v7_defconfig, exynos_defconfig, imx_v6_v7_defconfig, ...)
3. change the default for ARCH_MULTI_V7, or alternatively for
   configurations that include platforms that usually want it.

My preference would be to have the first two in v5.8, but leave
the third one for a later time, depending on who needs it.
I notice that the changelog text does not give a particular
example of platforms with very sparse memory maps. It
might help to have more background there. Among the platforms
I see, it seems fairly rare to have any RAM above the 4GB
boundary on ARMv7 based chips: keystone2, r-car, and
highbank would be the main examples I can think of, but I
don't know if they have large holes in the memory map.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Russell King - ARM Linux admin]

On Wed, May 06, 2020 at 04:50:07PM -0700, Florian Fainelli wrote:
> Hi all,
> 
> This patch series somehow got lost back in 2015, and while looking at
> the various patches that we are carrying in our BRCMSTB downstream
> kernel those two patches should have made it upstream.

I don't believe it's a good idea for multiplatform.

If you have a platform that relies on sparsemem within the multiplatform
family, and you select flatmem, how would it boot?

Sparsemem can support flatmem layouts, but flatmem can't support
sparsemem layouts.

So, allowing flatmem seems to go against the underlying principle of
multiplatform support.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Mike Rapoport]

Hi Russell,

On Thu, May 07, 2020 at 09:14:09AM +0100, Russell King - ARM Linux admin wrote:
> On Wed, May 06, 2020 at 04:50:07PM -0700, Florian Fainelli wrote:
> > Hi all,
> > 
> > This patch series somehow got lost back in 2015, and while looking at
> > the various patches that we are carrying in our BRCMSTB downstream
> > kernel those two patches should have made it upstream.
> 
> I don't believe it's a good idea for multiplatform.
> 
> If you have a platform that relies on sparsemem within the multiplatform
> family, and you select flatmem, how would it boot?
> 
> Sparsemem can support flatmem layouts, but flatmem can't support
> sparsemem layouts.
> 
> So, allowing flatmem seems to go against the underlying principle of
> multiplatform support.

Currently neither of multiplafrom builds has SPARSEMEM enabled, so
unless I misread theses patches, they actually allow enabling SPARSEMEM
in menuconfig for custom builds based on a multiplatform config.

> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel