SPARSEMEM memory needs?

[Arnd Bergmann]

On Tue, Jun 7, 2022 at 12:03 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> 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.

Right, that part would not help, but maybe there are some other easy
optimizations that would.

> > 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.

I think what happened with Nico's work is that the particular use case
for the MMU-less or DRAM-less systems just disappeared in 2017 when
Zephyr, FreeRTOS, mbed OS and others all received a lot of funding
and took over that particular market from Linux.

On the other hand, there is clearly still a market for small embedded
systems running Linux, it's just that "small" is no longer as small
as it used to be, with DDR3 (128MB to 512MB) and soon LPDDR4
(512MB and up) DRAM now as the dominant technology for low-end
devices, while DDR2 and earlier are no longer economically viable.

I think about half the platforms in arch/arm64 fit into this embedded
space (four or fewer A35/A53/A55 cores, under 1GB of RAM) already,
and I expect this to become more important over time as 32-bit cores
get less common in new chips.

> 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)

I don't see a configurable section size (possibly under CONFIG_EXPERT)
as too intrusive. The arm64 defconfig clearly is clearly required to work on
any kind of hardware, but there is enough precedence for Kconfig options
that make machine specific trade-offs (e.g. page size and VA size), or that
completely disable support for certain SoC platforms.

       Arnd