Slimming down the bird: A 2.6 kernel for PCs with 4-8 megs

Last Updated on April 14, 2017 by Dave Farquhar

In case you haven’t read about it elsewhere, a new branch of the Linux kernel called -tiny was quietly released last month. Its main intent is for embedded systems, but I can see all sorts of uses for it. The smaller the kernel, the faster it loads off a floppy, so it’d be great for boot disks. Likewise for diskless machines that boot off the network.
Some people claim that compiling the kernel with the -Os parameter, as this branch permits, causes faster operation than compilations with the normal -O2. The theory is that the system spends more time in user space than in kernel space, and therefore, the kernel will almost never be in system cache, and therefore, the smaller it is, the faster it will operate. I’m sure someone who knows some specifics of how CPUs and caches work could validate or refute this. Even Steve DeLassus, who has both an electrical engineering and a computer science degree from one of the best universities in the world for that kind of thing, admits that sometimes these specifics get over his head. So if Steve doesn’t always know, then how am I supposed to know?

But the argument sounds good on paper.

With this kernel slimmed down as much as possible (no networking), it can boot in 2 megs. With networking, it can boot in 2.5 megs. With a comfortable set of features, it runs in 4-8 megs, which a mainline kernel doesn’t always do anymore.

Obviously, this is a perfect companion for projects like asmutils and uClibc/Busybox/Tinylogin.

If you found this post informative or helpful, please share it!

One thought on “Slimming down the bird: A 2.6 kernel for PCs with 4-8 megs

  • January 10, 2004 at 3:32 pm
    Permalink

    Hi Dave,

    I have been running Gentoo for quite some time and as you know, you get to choose your own compile flags for the stuff you compile. I have seen lots of tests done on Gentoo machines with different compile flags to test speed. For the most part I think most people agree that the -Os is probably slowest of the -O parameters. The only real good thing about it is that it creates the smallest binaries. I think that folks also agree that -O3 is also compile overkill. The binaries become too large, take too long to compile and are not as fast as -O2. Having done some tests on -O2 and -O3 I agree.

    However, there are always exceptions to the rule and people that disagree. What I wrote above is after collecting data from several different tests I have read about along with small tests that I have done myself.

    /David T.

Comments are closed.