Shrinking the kernel with gcc [LWN.net]

Shrinking the kernel with gcc

Posted Jan 24, 2004 17:01 UTC (Sat) by Duncan (guest, #6647)
Parent article: Shrinking the kernel with gcc

Trying this now.. On a dual Opteron system, thus amd64/x86_64 arch, SMP
kernel, from the Mdk 2.4.22, release 27 package (which includes backporting
of some of the recent security patches, in case anyone is wondering), with
pretty much everything left as modules, except reiserfs, which I build-in since
that's what I run, to avoid having an initrd.

With -Os and -funit-at-a-time, fully bzip2ed size went from 1.16 (base 10)
Megabytes, to 1.05, thus shrinking >100 kb (base 10). Unfortunately, I didn't
think to get the full-size size of the normal -O2 version from /usr/src/linux b4 I
recompiled with the new parameters.

There is, however, an additional complication with -mregparm=3, not
mentioned in the article. Acccording to the GCC manpage, not only must all
modules be built with it (as covered by the article), but so must the main
system libraries, which I take to include glibc, etc. if anything is built with it.
At this point, I'm not going to rebuild them, just to see how much better I can
get it. However, I AM trying the kernel rebuild (as I write), to check size, and
will of course try rebooting to it if the rebuild completes without issue. Maybe
I'm interpreting the library reference incorrectly, and that doesn't apply to the
kernel, only to userspace builds.

We'll see..

Duncan

(Log in to post comments)

The results, here

Posted Jan 24, 2004 17:57 UTC (Sat) by Duncan (guest, #6647) [Link]

"Here" being as mentioned in the upline post.. amd64, Mandrake's 2.4.22-27
kernel, SMP, reiserfs built-in to avoid initrd, but basically everything else
possible as modules.

Not sure how this will turn out with proportional fonts, and what it does to my
tabs, but..

kernel build switches bzImage sz. uncomp. sz.
-O2 (standard) 1167599 6141545
-Os -funit-at-a-time 1056342 5892105
-Os -funit-at-a-time -mregparm=3 995372 5366728

As expected, due to the problem noted in the previous post, however, meaning
system libs need compiled with the same switch, something I didn't do, the
-mregparm=3 kernel wouldn't boot. The -Os -funit-at-a-time kernel DID,
however, boot, and is what I'm running now while writing this (in Konqueror,
so it's stable enough to run X and KDE, and complete this note in Konqueror,
at least).

Haven't noticed any performance differences in the few minutes I've been
running it, but then, with a dual Opteron and a gig of memory running a
desktop, pretty much ANYTHING is relatively fast. <g>

Duncan

-mregparms and system libraries

Posted Jan 24, 2004 19:15 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

Acccording to the GCC manpage, not only must all modules be built with it (as covered by the article), but so must the main system libraries, which I take to include glibc, etc. if anything is built with it.

Remember that the manual you're reading isn't specifically for compiling a Linux kernel. It's for compiling any program. Then clearly when it says libraries must be compiled with -mregparm, it means those libraries to which your program links. The typical program is a user space program that links to "system libraries." But the Linux kernel is not typical and does NOT link to glibc (unless it's user mode Linux!). So you're OK there.

You don't link the kernel to glibc (unless it's User Mode Linux), so don't worry about that one.