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

[Mike Rapoport <rppt@linux.ibm.com>]

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