lkml.org 
[lkml]   [2017]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/8] scheduler tinification

* Nicolas Pitre <nicolas.pitre@linaro.org> wrote:

> > With the stroke of a pen from the CFO: "yes, we can spend more on our next
> > hardware design!" the problem goes away, overnight, and nobody will look back at
> > the hardware hack that had only 1MB of RAM.
>
> Of course hobbyists can already get a Raspberry Pi Zero and run a full
> featured Linux distro on it... for a mere 5 bucks. That comes with 512MB
> of RAM so my patches certainly don't make a difference there.

Note that those mere 5 bucks are probably 50 cents or less in bulk. Perfectly fine
economics for many types of 'throw away IoT hardware' products.

> But that's not that simple. First there is a fundamental constraint
> which is power consumption. If you want your device to run for months
> (some will hope years) from the same tiny battery then you just cannot
> afford SDRAM. So we're talking static RAM here. And to keep costs down
> because you want to give away your thingies by the millions for free it
> usually means single-chip designs with on-chip sub-megabyte static RAM.
> And in that field the 256KB mark is located towards the high end of the
> spectrum. Many IPv6-capable chips available today have less than that.
>
> And the thing is: people already manage to do a awful lot of stuff in
> such a constrained device. Some probably did a good job of it, but most
> of them likely suck and we don't know about their bugs because we have
> no idea what's running inside.

Ok, let me put it this way: there's no way in hell I see a viable Linux kernel
running (no matter how stripped down) in 32K or even 64K of RAM. 256K is a stretch
as well - but that RAM size you claim to be already 'high end', so it probably
wouldn't be used as a standardized solution anyway...

Today a Linux 'allnoconfig' kernel, i.e. a kernel with no device drivers and no
filesystems whatsoever and with everything optional turned off (including all
networking!), is over 2MB large text+data (on x86, which has a compressed
instruction set - it would possibly be larger on simpler CPUs):

triton:~/tip> size vmlinux
text data bss dec filename
926056 208624 1215904 2350584 vmlinux

A series that shrinks the .text size of the allnoconfig core Linux kernel from 1MB
to 9.9MB in isolation is not proof.

There will literally have to be two orders of magnitude more patches than that to
reach the 32K size envelope, if I (very) optimistically assume that the difficulty
to shrink code is constant (which it most certainly is not).

I.e. the whole stated premise of the series is wildly not realistic AFAICS, the
series does not make Linux more usable at all on that category of devices (Linux
is totally inadequate because it's way too large), it only increases its
complexity.

But you can prove me wrong: show me a Linux kernel for a real device that fits
into 32KB of RAM (or even 256 KB) and _then_ I'll consider the cost/benefit
equation.

Until that happens I consider most forms of additional complexity on the
non-hardware dependent side of the kernel a net negative.

Thanks,

Ingo

\
 
 \ /
  Last update: 2017-06-12 01:57    [W:0.241 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site