* Re: Minimizing the Kernel
@ 2003-09-24 17:32 Andrzej Krzysztofowicz
2003-09-24 22:39 ` Timothy Miller
0 siblings, 1 reply; 8+ messages in thread
From: Andrzej Krzysztofowicz @ 2003-09-24 17:32 UTC (permalink / raw)
To: kernel list
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
2003-09-24 17:32 Minimizing the Kernel Andrzej Krzysztofowicz
@ 2003-09-24 22:39 ` Timothy Miller
0 siblings, 0 replies; 8+ messages in thread
From: Timothy Miller @ 2003-09-24 22:39 UTC (permalink / raw)
To: Andrzej Krzysztofowicz; +Cc: kernel list
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
@ 2003-09-25 4:54 rwhron
0 siblings, 0 replies; 8+ messages in thread
From: rwhron @ 2003-09-25 4:54 UTC (permalink / raw)
To: linux-kernel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
@ 2003-09-25 2:22 rwhron
0 siblings, 0 replies; 8+ messages in thread
From: rwhron @ 2003-09-25 2:22 UTC (permalink / raw)
To: linux-kernel; +Cc: solt
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Minimizing the Kernel
@ 2003-09-24 16:32 Scott Robert Ladd
2003-09-24 16:39 ` Matt Heler
0 siblings, 1 reply; 8+ messages in thread
From: Scott Robert Ladd @ 2003-09-24 16:32 UTC (permalink / raw)
To: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
2003-09-24 16:32 Scott Robert Ladd
@ 2003-09-24 16:39 ` Matt Heler
2003-09-24 17:13 ` Maciej Soltysiak
0 siblings, 1 reply; 8+ messages in thread
From: Matt Heler @ 2003-09-24 16:39 UTC (permalink / raw)
To: Scott Robert Ladd, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
2003-09-24 16:39 ` Matt Heler
@ 2003-09-24 17:13 ` Maciej Soltysiak
2003-09-24 18:21 ` Valdis.Kletnieks
0 siblings, 1 reply; 8+ messages in thread
From: Maciej Soltysiak @ 2003-09-24 17:13 UTC (permalink / raw)
To: Matt Heler; +Cc: Scott Robert Ladd, Linux Kernel Mailing List
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Minimizing the Kernel
2003-09-24 17:13 ` Maciej Soltysiak
@ 2003-09-24 18:21 ` Valdis.Kletnieks
0 siblings, 0 replies; 8+ messages in thread
From: Valdis.Kletnieks @ 2003-09-24 18:21 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: Matt Heler, Scott Robert Ladd, Linux Kernel Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-09-25 4:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-24 17:32 Minimizing the Kernel Andrzej Krzysztofowicz
2003-09-24 22:39 ` Timothy Miller
-- strict thread matches above, loose matches on Subject: below --
2003-09-25 4:54 rwhron
2003-09-25 2:22 rwhron
2003-09-24 16:32 Scott Robert Ladd
2003-09-24 16:39 ` Matt Heler
2003-09-24 17:13 ` Maciej Soltysiak
2003-09-24 18:21 ` Valdis.Kletnieks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox