[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

[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

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