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

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

[Mike Rapoport]

(resendig for the correct address and with mailing list cc'ed, sorry for
the noise)

Hi,

Following the discussion at [1], I'm resending the patches that enable
memory model selection in menuconfig and such.

These patches do not change the way the configuration is generated from the
defconfigs and they do not change explicit selection of SPARSEMEM for
platforms that have "select ARCH_ENABLE_SPARSEMEM".

The mere change is that when a user runs an interactive configuration they
will be allowed to select between FLATMEM and SPARSMEM, which is not the
case today.

There is indeed some awkwardness in, e.g. removal of
ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
mm/Kconfig imposes.

For example, below is the diffs of the configurations generated with
'make rpc_defconfig' and 'make defconfig':

$ diff -s old/rpc_defconfig new/rpc_defconfig
Files old/rpc_defconfig and new/rpc_defconfig are identical

$ diff -u old/defconfig new/defconfig
--- old/defconfig	2020-05-20 17:51:01.832649705 +0300
+++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
@@ -674,6 +674,9 @@
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
 CONFIG_HAVE_ARCH_PFN_VALID=y
 CONFIG_HIGHMEM=y
 CONFIG_HIGHPTE=y
@@ -1061,6 +1064,9 @@
 #
 # Memory Management options
 #
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_SPARSEMEM_MANUAL is not set
 CONFIG_FLATMEM=y
 CONFIG_FLAT_NODE_MEM_MAP=y
 CONFIG_ARCH_KEEP_MEMBLOCK=y

[1] https://lore.kernel.org/linux-arm-kernel/20200506235009.25023-1-f.fainelli@gmail.com

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 | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

-- 
2.26.2


_______________________________________________
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

[Mike Rapoport]

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 c88a48d622fc..604caf652e2a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1519,9 +1519,6 @@ config ARCH_SPARSEMEM_ENABLE
 	bool
 	select SPARSEMEM_STATIC
 
-config ARCH_SPARSEMEM_DEFAULT
-	def_bool ARCH_SPARSEMEM_ENABLE
-
 config HAVE_ARCH_PFN_VALID
 	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
-- 
2.26.2


_______________________________________________
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

[Mike Rapoport]

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.

The addition of this option does not change the defaults and a build with
any defconfig will behave the same way as previously.

The only effect this change has is to enable user to change "Memory model"
selection in interactive kernel configuration (menuconfig, xconfig etc).

[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

[ rppt: added ARCH_SELECT_MEMORY_MODEL and update the changelog ]

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>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/arm/Kconfig | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 604caf652e2a..34b93e0903df 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,9 +1518,15 @@ config OABI_COMPAT
 config ARCH_HAS_HOLES_MEMORYMODEL
 	bool
 
+config ARCH_SELECT_MEMORY_MODEL
+	bool
+
+config ARCH_FLATMEM_ENABLE
+	bool
+
 config ARCH_SPARSEMEM_ENABLE
 	bool
-	select SPARSEMEM_STATIC
+	select SPARSEMEM_STATIC if SPARSEMEM
 
 config HAVE_ARCH_PFN_VALID
 	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
-- 
2.26.2


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

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

[Russell King - ARM Linux admin]

On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> (resendig for the correct address and with mailing list cc'ed, sorry for
> the noise)
> 
> Hi,
> 
> Following the discussion at [1], I'm resending the patches that enable
> memory model selection in menuconfig and such.
> 
> These patches do not change the way the configuration is generated from the
> defconfigs and they do not change explicit selection of SPARSEMEM for
> platforms that have "select ARCH_ENABLE_SPARSEMEM".
> 
> The mere change is that when a user runs an interactive configuration they
> will be allowed to select between FLATMEM and SPARSMEM, which is not the
> case today.
> 
> There is indeed some awkwardness in, e.g. removal of
> ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> mm/Kconfig imposes.
> 
> For example, below is the diffs of the configurations generated with
> 'make rpc_defconfig' and 'make defconfig':
> 
> $ diff -s old/rpc_defconfig new/rpc_defconfig
> Files old/rpc_defconfig and new/rpc_defconfig are identical
> 
> $ diff -u old/defconfig new/defconfig
> --- old/defconfig	2020-05-20 17:51:01.832649705 +0300
> +++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
> @@ -674,6 +674,9 @@
>  CONFIG_AEABI=y
>  # CONFIG_OABI_COMPAT is not set
>  CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> +CONFIG_ARCH_FLATMEM_ENABLE=y
> +CONFIG_ARCH_SPARSEMEM_ENABLE=y
>  CONFIG_HAVE_ARCH_PFN_VALID=y
>  CONFIG_HIGHMEM=y
>  CONFIG_HIGHPTE=y
> @@ -1061,6 +1064,9 @@
>  #
>  # Memory Management options
>  #
> +CONFIG_SELECT_MEMORY_MODEL=y
> +CONFIG_FLATMEM_MANUAL=y
> +# CONFIG_SPARSEMEM_MANUAL is not set
>  CONFIG_FLATMEM=y
>  CONFIG_FLAT_NODE_MEM_MAP=y
>  CONFIG_ARCH_KEEP_MEMBLOCK=y

Right, but the question is whether we want to offer flatmem for rpc.
It isn't allowed today, and so far no one has said why it's a
desirable change to make.

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Mike Rapoport]

On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > (resendig for the correct address and with mailing list cc'ed, sorry for
> > the noise)
> > 
> > Hi,
> > 
> > Following the discussion at [1], I'm resending the patches that enable
> > memory model selection in menuconfig and such.
> > 
> > These patches do not change the way the configuration is generated from the
> > defconfigs and they do not change explicit selection of SPARSEMEM for
> > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > 
> > The mere change is that when a user runs an interactive configuration they
> > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > case today.
> > 
> > There is indeed some awkwardness in, e.g. removal of
> > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > mm/Kconfig imposes.
> > 
> > For example, below is the diffs of the configurations generated with
> > 'make rpc_defconfig' and 'make defconfig':
> > 
> > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > Files old/rpc_defconfig and new/rpc_defconfig are identical
> > 
> > $ diff -u old/defconfig new/defconfig
> > --- old/defconfig	2020-05-20 17:51:01.832649705 +0300
> > +++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
> > @@ -674,6 +674,9 @@
> >  CONFIG_AEABI=y
> >  # CONFIG_OABI_COMPAT is not set
> >  CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> >  CONFIG_HAVE_ARCH_PFN_VALID=y
> >  CONFIG_HIGHMEM=y
> >  CONFIG_HIGHPTE=y
> > @@ -1061,6 +1064,9 @@
> >  #
> >  # Memory Management options
> >  #
> > +CONFIG_SELECT_MEMORY_MODEL=y
> > +CONFIG_FLATMEM_MANUAL=y
> > +# CONFIG_SPARSEMEM_MANUAL is not set
> >  CONFIG_FLATMEM=y
> >  CONFIG_FLAT_NODE_MEM_MAP=y
> >  CONFIG_ARCH_KEEP_MEMBLOCK=y
> 
> Right, but the question is whether we want to offer flatmem for rpc.
> It isn't allowed today, and so far no one has said why it's a
> desirable change to make.

With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
enabled and since any of these machines explicitly selects
ARCH_SPARSEMEM_ENABLE, the only available memory model would be
SPARSEMEM.

I played a bit with menuconfig and if any of the platforms requiring
sparsemem is selected, the menu allowing the user to choose the memory
model disappears.

> -- 
> 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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Mike Rapoport]

On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote:
> On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > the noise)
> > > 
> > > Hi,
> > > 
> > > Following the discussion at [1], I'm resending the patches that enable
> > > memory model selection in menuconfig and such.
> > > 
> > > These patches do not change the way the configuration is generated from the
> > > defconfigs and they do not change explicit selection of SPARSEMEM for
> > > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > > 
> > > The mere change is that when a user runs an interactive configuration they
> > > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > > case today.
> > > 
> > > There is indeed some awkwardness in, e.g. removal of
> > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > > mm/Kconfig imposes.
> > > 
> > > For example, below is the diffs of the configurations generated with
> > > 'make rpc_defconfig' and 'make defconfig':
> > > 
> > > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > > Files old/rpc_defconfig and new/rpc_defconfig are identical
> > > 
> > > $ diff -u old/defconfig new/defconfig
> > > --- old/defconfig	2020-05-20 17:51:01.832649705 +0300
> > > +++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
> > > @@ -674,6 +674,9 @@
> > >  CONFIG_AEABI=y
> > >  # CONFIG_OABI_COMPAT is not set
> > >  CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > >  CONFIG_HAVE_ARCH_PFN_VALID=y
> > >  CONFIG_HIGHMEM=y
> > >  CONFIG_HIGHPTE=y
> > > @@ -1061,6 +1064,9 @@
> > >  #
> > >  # Memory Management options
> > >  #
> > > +CONFIG_SELECT_MEMORY_MODEL=y
> > > +CONFIG_FLATMEM_MANUAL=y
> > > +# CONFIG_SPARSEMEM_MANUAL is not set
> > >  CONFIG_FLATMEM=y
> > >  CONFIG_FLAT_NODE_MEM_MAP=y
> > >  CONFIG_ARCH_KEEP_MEMBLOCK=y
> > 
> > Right, but the question is whether we want to offer flatmem for rpc.
> > It isn't allowed today, and so far no one has said why it's a
> > desirable change to make.
> 
> With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
> ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
> enabled and since any of these machines explicitly selects
> ARCH_SPARSEMEM_ENABLE, the only available memory model would be
> SPARSEMEM.
> 
> I played a bit with menuconfig and if any of the platforms requiring
> sparsemem is selected, the menu allowing the user to choose the memory
> model disappears.

Ah, when either of these patforms will become a part of the
multiplatform build, the only option for multiplatform build will be
sparsemem.
So it would be nice if somebody could check the cost of using sparsemem
vs flatmem, espessially on low end machines.

> > -- 
> > 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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Russell King - ARM Linux admin]

On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote:
> > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > > the noise)
> > > > 
> > > > Hi,
> > > > 
> > > > Following the discussion at [1], I'm resending the patches that enable
> > > > memory model selection in menuconfig and such.
> > > > 
> > > > These patches do not change the way the configuration is generated from the
> > > > defconfigs and they do not change explicit selection of SPARSEMEM for
> > > > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > > > 
> > > > The mere change is that when a user runs an interactive configuration they
> > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > > > case today.
> > > > 
> > > > There is indeed some awkwardness in, e.g. removal of
> > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > > > mm/Kconfig imposes.
> > > > 
> > > > For example, below is the diffs of the configurations generated with
> > > > 'make rpc_defconfig' and 'make defconfig':
> > > > 
> > > > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > > > Files old/rpc_defconfig and new/rpc_defconfig are identical
> > > > 
> > > > $ diff -u old/defconfig new/defconfig
> > > > --- old/defconfig	2020-05-20 17:51:01.832649705 +0300
> > > > +++ new/defconfig	2020-05-20 18:15:21.084385880 +0300
> > > > @@ -674,6 +674,9 @@
> > > >  CONFIG_AEABI=y
> > > >  # CONFIG_OABI_COMPAT is not set
> > > >  CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > > > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > > >  CONFIG_HAVE_ARCH_PFN_VALID=y
> > > >  CONFIG_HIGHMEM=y
> > > >  CONFIG_HIGHPTE=y
> > > > @@ -1061,6 +1064,9 @@
> > > >  #
> > > >  # Memory Management options
> > > >  #
> > > > +CONFIG_SELECT_MEMORY_MODEL=y
> > > > +CONFIG_FLATMEM_MANUAL=y
> > > > +# CONFIG_SPARSEMEM_MANUAL is not set
> > > >  CONFIG_FLATMEM=y
> > > >  CONFIG_FLAT_NODE_MEM_MAP=y
> > > >  CONFIG_ARCH_KEEP_MEMBLOCK=y
> > > 
> > > Right, but the question is whether we want to offer flatmem for rpc.
> > > It isn't allowed today, and so far no one has said why it's a
> > > desirable change to make.
> > 
> > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
> > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
> > enabled and since any of these machines explicitly selects
> > ARCH_SPARSEMEM_ENABLE, the only available memory model would be
> > SPARSEMEM.
> > 
> > I played a bit with menuconfig and if any of the platforms requiring
> > sparsemem is selected, the menu allowing the user to choose the memory
> > model disappears.
> 
> Ah, when either of these patforms will become a part of the
> multiplatform build, the only option for multiplatform build will be
> sparsemem.
> So it would be nice if somebody could check the cost of using sparsemem
> vs flatmem, espessially on low end machines.

Do you think they will become part of multiplatform?

If they're low-end machines, then adding:

(a) the additional memory overhead of a multiplatform kernel
(b) the additional runtime overhead of the complexities of multiplatform
    kernels

is surely an odd thing to do, especially when few really care about
these platforms becoming part of a multiplatform kernel, except those
who like the idea of multiplat.

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Mike Rapoport]

On Thu, May 21, 2020 at 03:50:20PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> > On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote:
> > > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> > > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > > > the noise)
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Following the discussion at [1], I'm resending the patches that enable
> > > > > memory model selection in menuconfig and such.
> > > > > 
> > > > > These patches do not change the way the configuration is generated from the
> > > > > defconfigs and they do not change explicit selection of SPARSEMEM for
> > > > > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > > > > 
> > > > > The mere change is that when a user runs an interactive configuration they
> > > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > > > > case today.
> > > > > 
> > > > > There is indeed some awkwardness in, e.g. removal of
> > > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > > > > mm/Kconfig imposes.
> > > > > 
> > > > Right, but the question is whether we want to offer flatmem for rpc.
> > > > It isn't allowed today, and so far no one has said why it's a
> > > > desirable change to make.
> > > 
> > > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
> > > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
> > > enabled and since any of these machines explicitly selects
> > > ARCH_SPARSEMEM_ENABLE, the only available memory model would be
> > > SPARSEMEM.
> > > 
> > > I played a bit with menuconfig and if any of the platforms requiring
> > > sparsemem is selected, the menu allowing the user to choose the memory
> > > model disappears.
> > 
> > Ah, when either of these patforms will become a part of the
> > multiplatform build, the only option for multiplatform build will be
> > sparsemem.
> > So it would be nice if somebody could check the cost of using sparsemem
> > vs flatmem, espessially on low end machines.
> 
> Do you think they will become part of multiplatform?
> 
> If they're low-end machines, then adding:
> 
> (a) the additional memory overhead of a multiplatform kernel
> (b) the additional runtime overhead of the complexities of multiplatform
>     kernels
> 
> is surely an odd thing to do, especially when few really care about
> these platforms becoming part of a multiplatform kernel, except those
> who like the idea of multiplat.

I honestly don't know, it was Arnd who was talking about adding ep93xx
to multiplat.

So, probably better phrasing would have been "if either of these
patforms will become a part of the multiplatform build...".

Anyway, benchmarking sparsemem vs flatmem on a platform that is already
a part of multiplat might be useful to understand whether we need both
of them or we can simply make everything use 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

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Geert Uytterhoeven]

Hi Russell,

On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> > Ah, when either of these patforms will become a part of the
> > multiplatform build, the only option for multiplatform build will be
> > sparsemem.
> > So it would be nice if somebody could check the cost of using sparsemem
> > vs flatmem, espessially on low end machines.
>
> Do you think they will become part of multiplatform?
>
> If they're low-end machines, then adding:
>
> (a) the additional memory overhead of a multiplatform kernel
> (b) the additional runtime overhead of the complexities of multiplatform
>     kernels
>
> is surely an odd thing to do, especially when few really care about
> these platforms becoming part of a multiplatform kernel, except those
> who like the idea of multiplat.

The fallacy of "multi-platform", again?

Isn't it a requirement for any new ARM v7-A platforms to be part of
ARCH_MULTI_V7, even if it's a low-end machine?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

[Russell King - ARM Linux admin]

On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> > > Ah, when either of these patforms will become a part of the
> > > multiplatform build, the only option for multiplatform build will be
> > > sparsemem.
> > > So it would be nice if somebody could check the cost of using sparsemem
> > > vs flatmem, espessially on low end machines.
> >
> > Do you think they will become part of multiplatform?
> >
> > If they're low-end machines, then adding:
> >
> > (a) the additional memory overhead of a multiplatform kernel
> > (b) the additional runtime overhead of the complexities of multiplatform
> >     kernels
> >
> > is surely an odd thing to do, especially when few really care about
> > these platforms becoming part of a multiplatform kernel, except those
> > who like the idea of multiplat.
> 
> The fallacy of "multi-platform", again?
> 
> Isn't it a requirement for any new ARM v7-A platforms to be part of
> ARCH_MULTI_V7, even if it's a low-end machine?

What does ARMv7 have to do with this thread, that is discussing the
older ARMv4 platforms? I find your comments above irrelevent to
this discussion, and seems to be worded to provoke a reaction.

Not playing.

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Geert Uytterhoeven]

Hi Russell,

On Tue, Jun 2, 2020 at 2:22 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote:
> > On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> > > > Ah, when either of these patforms will become a part of the
> > > > multiplatform build, the only option for multiplatform build will be
> > > > sparsemem.
> > > > So it would be nice if somebody could check the cost of using sparsemem
> > > > vs flatmem, espessially on low end machines.
> > >
> > > Do you think they will become part of multiplatform?
> > >
> > > If they're low-end machines, then adding:
> > >
> > > (a) the additional memory overhead of a multiplatform kernel
> > > (b) the additional runtime overhead of the complexities of multiplatform
> > >     kernels
> > >
> > > is surely an odd thing to do, especially when few really care about
> > > these platforms becoming part of a multiplatform kernel, except those
> > > who like the idea of multiplat.
> >
> > The fallacy of "multi-platform", again?
> >
> > Isn't it a requirement for any new ARM v7-A platforms to be part of
> > ARCH_MULTI_V7, even if it's a low-end machine?
>
> What does ARMv7 have to do with this thread, that is discussing the
> older ARMv4 platforms? I find your comments above irrelevent to
> this discussion, and seems to be worded to provoke a reaction.

Sorry, I used ARMv7 as an example, as it's rare for any new ARMv4
platforms to show up.  But the recently introduced sam9x60 (ARMv5) is
part of ARCH_MULTI_V5, and I expect it will be used with less than the
256 MiB provided on the dev board.

Nevertheless, there's a movement to convert everything to ARCH_MULTI_V*
where possible. So it matters for all variants.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

[Russell King - ARM Linux admin]

On Tue, Jun 02, 2020 at 02:37:45PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Tue, Jun 2, 2020 at 2:22 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote:
> > > > > Ah, when either of these patforms will become a part of the
> > > > > multiplatform build, the only option for multiplatform build will be
> > > > > sparsemem.
> > > > > So it would be nice if somebody could check the cost of using sparsemem
> > > > > vs flatmem, espessially on low end machines.
> > > >
> > > > Do you think they will become part of multiplatform?
> > > >
> > > > If they're low-end machines, then adding:
> > > >
> > > > (a) the additional memory overhead of a multiplatform kernel
> > > > (b) the additional runtime overhead of the complexities of multiplatform
> > > >     kernels
> > > >
> > > > is surely an odd thing to do, especially when few really care about
> > > > these platforms becoming part of a multiplatform kernel, except those
> > > > who like the idea of multiplat.
> > >
> > > The fallacy of "multi-platform", again?
> > >
> > > Isn't it a requirement for any new ARM v7-A platforms to be part of
> > > ARCH_MULTI_V7, even if it's a low-end machine?
> >
> > What does ARMv7 have to do with this thread, that is discussing the
> > older ARMv4 platforms? I find your comments above irrelevent to
> > this discussion, and seems to be worded to provoke a reaction.
> 
> Sorry, I used ARMv7 as an example, as it's rare for any new ARMv4
> platforms to show up.  But the recently introduced sam9x60 (ARMv5) is
> part of ARCH_MULTI_V5, and I expect it will be used with less than the
> 256 MiB provided on the dev board.
> 
> Nevertheless, there's a movement to convert everything to ARCH_MULTI_V*
> where possible. So it matters for all variants.

First, please understand that I have nothing against multiplatform.

What I do have problems with is the "lets move everything to
multiplatform" without fully reasoning it out, especially when it
comes to older platforms that have limited attraction for the whole
motivation behind multiplatform, which is the convenience of
distributions.

multiplatform is the current fad-de-jour, and everyone is in a "you
MUST convert EVERYTHING to it, because it's the best thing since
sliced bread".

multiplatform comes with it a load of forced-enabled options that
are force-enabled.  Should RiscPC be forced to have the common clock
support built into the kernel, when it doesn't' have _any_ controllable
clocks, when it's likely that the machines have limited memory
available?  Yes, I have recently booted the RiscPC with a 5.x kernel,
and no, it didn't need very much fixing, the code is quite *stable*
(oh, I blaspheme, we can't have stable code in Linux, we must change
it every five minutes.)

I think, maybe, you should leave these decisions to people who actually
have the platforms, know them inside out, and can assess whether
conversion really makes sense or not, rather than blindly joining the
zombie march repeating "multiplatform is great, everything must be
multiplatform".

What is patently obvious is that in Linux, there is no tolerance of
someone who has a differing view, and they end up receiving reaction
provoking comments designed to inflame the situation.  Difference of
opinion must be suppressed at all costs!

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Russell King - ARM Linux admin]

On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> (resendig for the correct address and with mailing list cc'ed, sorry for
> the noise)

There are two patches in the patch system, submitted within minutes
of each other, with the same summary "Allow either FLATMEM or
SPARSEMEM on the multiplatform build" but the patch and commit messages
are different.  I guess the summary for one of the patches is wrong?

-- 
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Mike Rapoport]

On Tue, May 26, 2020 at 12:18:04PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > (resendig for the correct address and with mailing list cc'ed, sorry for
> > the noise)
> 
> There are two patches in the patch system, submitted within minutes
> of each other, with the same summary "Allow either FLATMEM or
> SPARSEMEM on the multiplatform build" but the patch and commit messages
> are different.  I guess the summary for one of the patches is wrong?

Oops, my mistake.

The patch 8979/1 should have "ARM: Remove redundant
ARCH_SPARSEMEM_DEFAULT setting" in its subject.

Sorry.

> -- 
> 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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build

[Russell King - ARM Linux admin]

On Tue, May 26, 2020 at 02:42:16PM +0300, Mike Rapoport wrote:
> On Tue, May 26, 2020 at 12:18:04PM +0100, Russell King - ARM Linux admin wrote:
> > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > the noise)
> > 
> > There are two patches in the patch system, submitted within minutes
> > of each other, with the same summary "Allow either FLATMEM or
> > SPARSEMEM on the multiplatform build" but the patch and commit messages
> > are different.  I guess the summary for one of the patches is wrong?
> 
> Oops, my mistake.
> 
> The patch 8979/1 should have "ARM: Remove redundant
> ARCH_SPARSEMEM_DEFAULT setting" in its subject.

Thanks; updated the database with that.

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

[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

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