SPARSEMEM memory needs?

[Ard Biesheuvel]

On Tue, 7 Jun 2022 at 11:53, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Tue, Jun 7, 2022 at 11:38 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > On Tue, 7 Jun 2022 at 11:29, Joakim Tjernlund <Joakim.Tjernlund at infinera.com> wrote:
> > > >
> > > > OK, so even if I am not a fan of this practice [0], running a 32-bit
> > > > kernel would likely be an option for you as well. Have you considered
> > > > this?
> > > >
> > ..
> > >
> > > Briefly considered 32 bits kernel but as I understand it, it is even more unsupported so I have opted
> > > for 64 bits kernel for now. I may have to revisit that though. ARM is still new to me.
> >
> > It is a bad idea for many reasons, but you may not have a choice.
>
> They are clearly both bad on this hardware ;-)
>
> If we can improve support for a 36MB configuration on arm64, that
> would likely also help
> those users with actual DDR3 ram (128MB to 512MB typically) that you see more
> commonly, and that's certainly a good thing.
>

I agree with that in principle, but as I explained, playing with the
section sizes and vmemmap granularity does not help on systems where
the DRAM is a 128 MiB aligned multiple of 128 MiB; if anything, we'll
use slightly more memory.

> Another alternative to using a 32-bit kernel would be to not use Linux
> at all. There are
> enough RTOS variants in the world that have a growing feature set and that may
> be sufficient for Joakim's workload but use a lot less RAM.
> If there is only one application running, there may not be a no need
> for the complexity
> in our file systems, memory protection or network stack either.
>

Nicolas Pitre did some work a few years ago to drastically reduce the
kernel's memory footprint, but I don't think there was a lot of
support for the more intrusive changes that he suggested. Linux is
just not as suited for true embedded use anymore, and the arm64 kernel
in particular was just never intended for that.

So yes to using less memory in the general case, but intrusive changes
such as the one I proposed are unlikely to be adopted (and the arm64
kernel, unlike the 32-bit one, tries really hard to only have a single
image and a single defconfig)