add an -Os config option
PATCH 1/1 add an -Os config option
The patch below adds an option OPTIMIZE_FOR_SIZE (depending on EMBEDDED) that changes the optimization from -O2 to -Os.
cu
Adrian
init/Kconfig renamed from init/Kconfig.old +11 -0
@@ -118,6 +118,17 @@ a "non-standard" kernel. Only use this if you really know what you are doing. +config OPTIMIZE_FOR_SIZE + bool "Optimize for size" if EMBEDDED + default n + help + Enabling this option will pass "-Os" instead of "-O2" to gcc + resulting in a smaller kernel. + + The resulting kernel might be significantly slower. + + If unsure, say N. + config KALLSYMS bool "Load all symbols for debugging/kksymoops" if EMBEDDED default y
Makefile renamed from Makefile.old +7 -1
@@ -223,7 +223,7 @@ NOSTDINC_FLAGS = -nostdinc -iwithprefix include CPPFLAGS := -D__KERNEL__ -Iinclude -CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \ +CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common AFLAGS := -D__ASSEMBLY__
@@ -318,6 +318,12 @@ -include .config.cmd +ifdef CONFIG_OPTIMIZE_FOR_SIZE +CFLAGS += -Os +else +CFLAGS += -O2 +endif + ifndef CONFIG_FRAME_POINTER CFLAGS += -fomit-frame-pointer endif
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
init/Kconfig line 128
Quoted 1 line · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.
With my poor english knowledge I would say it should be "significant". Correct?
- --
Regards Michael Buesch [ http://www.8ung.at/tuxsoft ] Animals on this machine: some GNUs and Penguin 2.6.0-test3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/OAhroxoigfggmSgRAuZhAJ4kRQBY0+ryHIgFDLaRCq/QBJWoiwCfX/HT HPIqp2wBp2yXM+mlwGQck+s=
=ZjQ4
-----END PGP SIGNATURE-----
Quoted 8 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1init/Kconfig line 128
Quoted 1 line · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
No, the english in the patch is correct.
Am Mo, 2003-08-11 um 23.19 schrieb Michael Buesch:
Quoted 5 lines · Adrian Bunk
init/Kconfig line 128
Quoted 1 line
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
I don't think so. The sentence above looks fine to me... (and I'm not an english genius either) :)
--
Christophe Saout <[email protected]>
Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Quoted 5 lines · Michael Buesch
init/Kconfig line 128
Quoted 1 line · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
Nope, it's an adverb (modifying the adjective "slower"), hence the -ly suffix.
Signature · 1 line
ilmari
Quoted 9 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1init/Kconfig line 128
Quoted 1 line · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Signature · 7 lines
Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Quoted 4 lines · Gene Heskett
Quoted 3 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines
Quoted 6 lines · Adrian Bunk
init/Kconfig line 128
Quoted 1 line
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Now you have hit one of my hot buttons :)
Your use of useage is an incorrect use. Simply use use in the above sentence :)
sineage, useage, etc. are simply incorrect
Quoted 12 lines · Thomas Molina
Quoted 10 lines · Gene Heskett
Quoted 9 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1init/Kconfig line 128
Quoted 1 line · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
Quoted 8 lines
Quoted 4 lines
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Now you have hit one of my hot buttons :)
Your use of useage is an incorrect use. Simply use use in the above sentence :)
Pedantry leakage causes no shrinkage of English use wreckage.
Steven
Quoted 3 lines · Steven Cole
Pedantry leakage causes no shrinkage of English use wreckage.
Argh, to my head, this has caused much damage. :)
Quoted 14 lines · Thomas Molina
Quoted 4 lines · Gene Heskett
Quoted 3 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 8 lines
Quoted 5 lines · Adrian Bunk
init/Kconfig line 128
Quoted 1 line
init/Kconfig renamed from init/Kconfig.old +1
-0+ The resulting kernel might be significantly slower.With my poor english knowledge I would say it should be "significant". Correct?
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Quoted 6 lines
Now you have hit one of my hot buttons :)
Your use of useage is an incorrect use. Simply use use in the above sentence :)
sineage, useage, etc. are simply incorrect
Well, in the everyday use, they do seem to be miss-used quite frequently as it is observed by me. And I am not an english professor, just a senior (68) citizen with an 8th grade education, a GED, and a diploma from the University of Hard Knocks. There really is such a thing you see.
Signature · 7 lines
Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · Gene Heskett
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Thank you all for the correction.
I'll now take my english-dictinoary to learn a bit. :)
- --
Regards Michael Buesch [ http://www.8ung.at/tuxsoft ] Animals on this machine: some GNUs and Penguin 2.6.0-test3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/OL1eoxoigfggmSgRAjFMAJkB2JUMgOal+TPPNje5N4RbgxdViQCfZsEI PWSDjc5fyF+M1NpCV82hnhI=
=OyMT
-----END PGP SIGNATURE-----
Quoted 9 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 2 lines · Gene Heskett
No, the quoted "significantly" version is the correct english useage in this apparently present tense.
Thank you all for the correction.
I'll now take my english-dictinoary to learn a bit. :)
And I pushed somebodies hot button when I said 'useage' instead of 'usage'. You win some, and you lose some. :)
Signature · 7 lines
Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Quoted 5 lines · Michael Buesch
Quoted 1 line · Adrian Bunk
+ The resulting kernel might be significantly slower.
With my poor english knowledge I would say it should be "significant". Correct?
"Significantly" is correct in this case as it is an adverb modifying the adjective "slower."
Warren Turkal
Signature · 2 lines
Treasurer, GOLUM, Inc. http://www.golum.org
Quoted 2 lines · Adrian Bunk
The patch below adds an option
OPTIMIZE_FOR_SIZE(depending on EMBEDDED) that changes the optimization from -O2 to -Os.
What about those of us who already build the kernel with -Os (eg, ARM) ?
This option will be confusing in that situation.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 2 lines · Adrian Bunk
The patch below adds an option
OPTIMIZE_FOR_SIZE(depending on EMBEDDED) that changes the optimization from -O2 to -Os.
Please dropt the if EMBEDDED - this makes perfecty sense for lots of todays hardware..
In fact we should probably rather do some some benchmarking whether it would be a good idea to make -Os the default.
Quoted 10 lines · Christoph Hellwig
Quoted 1 line · Adrian Bunk
The patch below adds an option
OPTIMIZE_FOR_SIZE(depending on EMBEDDED) that changes the optimization from -O2 to -Os.Please dropt the if EMBEDDED - this makes perfecty sense for lots of todays hardware..
In fact we should probably rather do some some benchmarking whether it would be a good idea to make -Os the default.
Interesting thought... In reality, we want the system to spend as little time in the kernel as possible. If we've done that job right, then optimizing for size shouldn't matter as much. We're still spending most of our time in user space.
Furthermore, it may be that we could benefit from compiling some source files with -Os and others with -O2, depending on how critical they are and how much they are ACTUALLY affected.
So... we need profiling to determine what is used and how much. And we need benchmarking to determine what is affected and by how much. Over the next couple of years, it might be good for Linus and others to adopt a policy where the default optimization for individual files is determined based on experience and need.
If only 5% of the source files are compiled with -O2, that's not going to bloat the kernel much, we'll get an optimal balance of performance and size, and everyone will be happy.
We may find it valuable to divide up the sources differently. There may be source files with both critical and noncritical functions that needed to be separated out so they can be compiled differently.
And while we're at it, if there is ever any benefit to -O3, that could be used on a per-file basis as well.
Comments?
Quoted 21 lines · Timothy Miller
Quoted 11 lines · Christoph Hellwig
Quoted 2 lines · Adrian Bunk
The patch below adds an option
OPTIMIZE_FOR_SIZE(depending on EMBEDDED) that changes the optimization from -O2 to -Os.Please dropt the if EMBEDDED - this makes perfecty sense for lots of todays hardware..
In fact we should probably rather do some some benchmarking whether it would be a good idea to make -Os the default.
Interesting thought... In reality, we want the system to spend as little time in the kernel as possible. If we've done that job right, then optimizing for size shouldn't matter as much. We're still spending most of our time in user space.
Quoted 5 lines
Furthermore, it may be that we could benefit from compiling some source files with -Os and others with -O2, depending on how critical they are and how much they are ACTUALLY affected.
...
Comments?
First of all, compiling my own kernel with gcc 3.3.1 resulted in less than 10% difference in the size of the kernel image (and ACPI is not part of my kernel) - the mere difference in size isn't that important except for special needs (like boot _floppies_ or embedded systems with very limited memory).
The benchmarking Christoph was referring to was to check whether a kernel completely compiled with -Os is faster than a kernel compiled with -O2. This might sound strange, but if the code is smaller more fits into the cache and modern CPUs suffer much every time they need to access the incredibly slow RAM.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 2 lines · Timothy Miller
Furthermore, it may be that we could benefit from compiling some source files with -Os and others with -O2, depending on how critical they are and how much they are ACTUALLY affected.
At one time last year, there was a brief discussion about modifying the kernel's build process to make it build whole directories of sources as a single "compilation unit". As I remember, this allowed the compiler to make better decisions about how to organize the resulting code, what to keep/discard, optimization, etc.
With the simplifications that have already occurred in the 2.6 makefiles, it seems to me that this would be an easier thing to do now (as opposed to the old makefiles where the build process had a harder time figuring out what source files were going to end up in the same object file). Now that kbuild always builds "built-on.o" in each source directory, could it perform that step by actually feeding gcc all the relevant source files in some combined form?
Granted, this is not something you'd want to use during debugging of kernel code, it would only be relevant for those trying to minimize their kernel size and/or get the last possible bits of speed out of the running kernel.
init/Kconfig line 128
Quoted 8 lines · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +8
-0+config OPTIMIZE_FOR_SIZE + bool "Optimize for size" if EMBEDDED + default n + help + Enabling this option will pass "-Os" instead of "-O2" to gcc + resulting in a smaller kernel. + + The resulting kernel might be significantly slower.
With most of the gcc's I tried -Os was faster.
Quoted 7 lines · Alan Cox
init/Kconfig line 128
Quoted 4 lines · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +4
-0+ Enabling this option will pass "-Os" instead of "-O2" to gcc + resulting in a smaller kernel. + + The resulting kernel might be significantly slower.With most of the gcc's I tried -Os was faster.
Because of a better L1-instruction cache footprint?
Joe
Quoted 13 lines · Alan Cox
init/Kconfig line 128
Quoted 8 lines · Adrian Bunk
init/Kconfig renamed from init/Kconfig.old +8
-0+config OPTIMIZE_FOR_SIZE + bool "Optimize for size" if EMBEDDED + default n + help + Enabling this option will pass "-Os" instead of "-O2" to gcc + resulting in a smaller kernel. + + The resulting kernel might be significantly slower.With most of the gcc's I tried -Os was faster.
Why is -Os faster? Fewer cache misses?
Wouldn't that make -O2 kinda pointless? It seems kinda futile to optimize for speed just to have it come out slower.