Re: [Q] TinyLinux project status (resend)


Rob Landley
 

On 04/24/2012 05:02 PM, Tim Bird wrote:
On 04/24/2012 12:22 PM, Rob Landley wrote:
On 04/18/2012 10:25 AM, Gross, Mark wrote:
I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/
Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal.
Call me a glutton for punishment. I have a background project to see if
Linux running in 1M is possible. The budget for some items:
256K kernel
256K library
64k shell
128k multi-call utility
Linux running in 1M of _ROM_ sure. Using the above for ram? Not a
chance. Your average shell is going to use more than 64k of _stack_.

In general, this would require (as Rob points out), reverting a lot
of features that have crept into Linux, and substituting smaller
code for some pieces.
You're ignoring page and dentry cache, which Linux isn't designed to
work without.

When you exec() a binary, that's implemented via mmap() (which is why
you can't exec a pipe or a chunk of memory, making executable
decompressors painful to implement on Linux). This means it must live in
a filesystem that supports mmap(). It then does a copy on write mapping
(when it can, nommu shortcuts some of this), demand faults the pages in,
and then self-modifying code (dynamic linking!) breaks the COW and
creates local copies. Static linking can actually use less DRAM at
runtime, especially when running multiple copies of each binary.
Note: if you fork and do _nothing_ you dirty something like 3 pages
between environment space and stack.

You can configure out the block layer, but you can't configure out the
VFS. "Everything is a file". (Running from initramfs _is_ the vfs, it's
small because it leverages that common code.)

One of the _big_ problems with 2.6 is that the disk cache has
historically been way too aggressive about how much memory it takes up,
and serious pressure to shrink it tends to trigger the OOM killer. You
can write 0 to /proc/sys/vm/swappiness but that's a big hammer and I've
had that trigger the OOM killer on me a lot (it's a regression that
comes and goes because it's not tested much).

By the way, if you chop out the OOM killer the failure mode becomes
"system suddenly locks hard".

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.

Join Celinux-dev@lists.celinuxforum.org to automatically receive all group messages.