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
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.
> 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
> > 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 [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Gdansk University of Technology
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....
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?
> 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
> 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