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