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

From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Doug Berger <opendmb@gmail.com>, Stephen Boyd <sboyd@kernel.org>,
	Kevin Cernekee <cernekee@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Gregory Fong <gregory.0xf0@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
Date: Tue, 19 May 2020 22:42:00 +0200	[thread overview]
Message-ID: <CAK8P3a32gDzqLBeBs8CtT9fhRncQNsJ0nrN=2Ws4DAWe3nOCZA@mail.gmail.com> (raw)
In-Reply-To: <20200519165445.GI1551@shell.armlinux.org.uk>

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