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

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
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 17:54:45 +0100	[thread overview]
Message-ID: <20200519165445.GI1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAK8P3a2iZNm310x8g2Zv0TjGJ=Px7hu14i3Ka7GQBZwyKPUesA@mail.gmail.com>

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