Re: Minimizing the Kernel

Re: Minimizing the Kernel

[rwhron]

> Hmm, has anyone tried -Os with gcc3+ ?
> Maybe that'd be good for size optimization?

2.6.0-test3 compiled with gcc-3.3.1 and redhat 7.2's
gcc-2.96-112.  gcc-3.3.1 saves about 275k text (10%).
-Os is more effective on gcc-3.3.1 than 2.96.
These were all built with the same .config.

size vmlinux-*
   text    data     bss     dec     hex filename
2120419  449928  131748 2702095  293b0f vmlinux-3.3.1-Os
2124890  449928  131748 2706566  294c86 vmlinux-3.3.1-Os-falign=2
2334482  457304  125952 2917738  2c856a vmlinux-2.96-112-Os
2405382  449960  131748 2987090  2d9452 vmlinux-3.3.1
2408343  457332  125952 2991627  2da60b vmlinux-2.96-112

Most frequently saved instruction with gcc-3.3.1 -Os is nop.

This was on x86.  The -falign=2 version had -falign-functions=2
-falign-jumps=2 -falign-labels=2 -falign-loops=2.  I believe the
default with -Os is no alignment (i.e. -falign-*=0).

I benchmarked those compilers/options on a K6/2.  You could wade
through http://home.earthlink.net/~rwhron/kernel/bigbox.html
to see all the results.  

Quick summary:
gcc-3.3.1 -Os -falign=2 was best for most LMbench tests.  
For other benchmarks that wasn't always true.  K6/2 has small
L1 cache (32+32K)  L2 cache is 1M, but not much faster than RAM
on my box.

These generalizations can be made:
1) gcc-3.3.1 -Os kernel code is about 10% smaller than gcc-2.96 -Os.
2) Actual memory savings is not 10%, because dynamic structure
   sizes don't change.
3) gcc-3.3.1 takes significantly longer to compile source.

YMMV

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

Re: Minimizing the Kernel

[rwhron]

> I benchmarked those compilers/options on a K6/2.

Here is the real link.  It's cleaned up to only
include the compiler benchmarks.  The results are
mostly sorted so better numbers are at the top of each
section.

http://home.earthlink.net/~rwhron/kernel/compiler.html

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

Re: Minimizing the Kernel

[Andrzej Krzysztofowicz]

> > Well for starters dont use gcc 3 or above.. code size has increased
> > dramatically with thoose versions. sure they give you more optimization
> Hmm, has anyone tried -Os with gcc3+ ?
> Maybe that'd be good for size optimization?

AFAIK, the -Os optimization in gcc3 gives you larger binary than -Os in
gcc2.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology

Re: Minimizing the Kernel

[Timothy Miller]

Andrzej Krzysztofowicz wrote:
>>>Well for starters dont use gcc 3 or above.. code size has increased
>>>dramatically with thoose versions. sure they give you more optimization
>>
>>Hmm, has anyone tried -Os with gcc3+ ?
>>Maybe that'd be good for size optimization?
> 
> 
> AFAIK, the -Os optimization in gcc3 gives you larger binary than -Os in
> gcc2.
> 

Any ideas why?  I mean, what does all the extra code DO?

And have you considered that some of that extra code might be there for 
correctness purposes?

Minimizing the Kernel

[Scott Robert Ladd]

I want to created the smallest, fastest kernel that supports all the 
necessary features of a given system.

Obviously, the answer is very system dependent, requiring a keen 
knowledge of the relationships between hardware and Linux components.

Unless I'm missing something (always a possibility), the kernel 
configurations do not provide a clear idea of component size. In other 
words, if I include "burfulgunk port support" in my kernel build, I'd 
like to have a rough idea of the component's size. I might not need to 
support the "burfulgunk", especially if it's a large component (for, 
say, a legacy port.)

I'm well aware that code sizes differ between platforms; I'm looking for 
general information, as a guideline to generating a small kernel.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Minimizing the Kernel

[Matt Heler]

Well for starters dont use gcc 3 or above.. code size has increased 
dramatically with thoose versions. sure they give you more optimization , but 
if your looking for a small kernel use anything below 3..

Matt H.

On Wednesday 24 September 2003 09:32 am, Scott Robert Ladd wrote:
> I want to created the smallest, fastest kernel that supports all the
> necessary features of a given system.
>
> Obviously, the answer is very system dependent, requiring a keen
> knowledge of the relationships between hardware and Linux components.
>
> Unless I'm missing something (always a possibility), the kernel
> configurations do not provide a clear idea of component size. In other
> words, if I include "burfulgunk port support" in my kernel build, I'd
> like to have a rough idea of the component's size. I might not need to
> support the "burfulgunk", especially if it's a large component (for,
> say, a legacy port.)
>
> I'm well aware that code sizes differ between platforms; I'm looking for
> general information, as a guideline to generating a small kernel.

Re: Minimizing the Kernel

[Maciej Soltysiak]

> Well for starters dont use gcc 3 or above.. code size has increased
> dramatically with thoose versions. sure they give you more optimization
Hmm, has anyone tried -Os with gcc3+ ?
Maybe that'd be good for size optimization?

Regards,
Maciej

Re: Minimizing the Kernel

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On Wed, 24 Sep 2003 19:13:28 +0200, Maciej Soltysiak said:
> > Well for starters dont use gcc 3 or above.. code size has increased
> > dramatically with thoose versions. sure they give you more optimization
> Hmm, has anyone tried -Os with gcc3+ ?
> Maybe that'd be good for size optimization?

I've usually been compiling with -Os on gcc3 for a while, works for me.

% size */vmlinux
   text    data     bss     dec     hex filename
3034134  620847  224824 3879805  3b337d linux-2.6.0-test4-mm6/vmlinux
3476451  621246  227512 4325209  41ff59 linux-2.6.0-test5-mm2/vmlinux
3034632  622210  226360 3883202  3b40c2 linux-2.6.0-test5-mm3/vmlinux
3037706  623409  226360 3887475  3b5173 linux-2.6.0-test5-mm4/vmlinux

-mm6, -mm3, and -mm4 were compiled with -Os, -mm2 with -O2.  All with gcc 3.3.1
from RedHat Rawhide.  Given how close -mm6, -mm3, and -mm4 are in size, the 12%
or so size saving is almost certainly the efects of -Os rather than changes in
the size of the code.  I could rebuild any of them to get an exact number, but
it would take a while on this laptop....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]