The patch below adds an option OPTIMIZE_FOR_SIZE (depending on EMBEDDED)
that changes the optimization from -O2 to -Os.
cu
Adrian
--- linux-2.6.0-test3/init/Kconfig.old 2003-08-11 01:33:31.000000000 +0200
+++ linux-2.6.0-test3/init/Kconfig 2003-08-11 01:46:48.000000000 +0200
@@ -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
--- linux-2.6.0-test3/Makefile.old 2003-08-11 01:34:41.000000000 +0200
+++ linux-2.6.0-test3/Makefile 2003-08-11 01:37:16.000000000 +0200
@@ -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
On Monday 11 August 2003 23:11, Adrian Bunk wrote:
> + 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-----
On Mon, Aug 11, 2003 at 11:19:39PM +0200, Michael Buesch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 11 August 2003 23:11, Adrian Bunk wrote:
> > + 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.
Michael Buesch <[email protected]> writes:
> On Monday 11 August 2003 23:11, Adrian Bunk wrote:
>> + 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.
--
ilmari
Am Mo, 2003-08-11 um 23.19 schrieb Michael Buesch:
> On Monday 11 August 2003 23:11, Adrian Bunk wrote:
> > + 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
On Mon, Aug 11, 2003 at 11:11:45PM +0200, Adrian Bunk wrote:
> 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.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Monday 11 August 2003 17:19, Michael Buesch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Monday 11 August 2003 23:11, Adrian Bunk wrote:
>> + 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.
--
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.
Michael Buesch wrote:
> On Monday 11 August 2003 23:11, Adrian Bunk wrote:
>> + 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
--
Treasurer, GOLUM, Inc.
http://www.golum.org
On Mon, 11 Aug 2003, Gene Heskett wrote:
> On Monday 11 August 2003 17:19, Michael Buesch wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Monday 11 August 2003 23:11, Adrian Bunk wrote:
> >> + 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
On Mon, 2003-08-11 at 20:51, Thomas Molina wrote:
> On Mon, 11 Aug 2003, Gene Heskett wrote:
>
> > On Monday 11 August 2003 17:19, Michael Buesch wrote:
> > >-----BEGIN PGP SIGNED MESSAGE-----
> > >Hash: SHA1
> > >
> > >On Monday 11 August 2003 23:11, Adrian Bunk wrote:
> > >> + 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 :)
Pedantry leakage causes no shrinkage of English use wreckage.
Steven
On Mon, Aug 11, 2003 at 11:11:45PM +0200, Adrian Bunk wrote:
> 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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 12 August 2003 03:29, Gene Heskett wrote:
> 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-----
On Llu, 2003-08-11 at 22:11, Adrian Bunk wrote:
> +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.
On Tuesday 12 August 2003 06:11, Michael Buesch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tuesday 12 August 2003 03:29, Gene Heskett wrote:
>> 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. :)
--
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.
On Monday 11 August 2003 22:51, Thomas Molina wrote:
>On Mon, 11 Aug 2003, Gene Heskett wrote:
>> On Monday 11 August 2003 17:19, Michael Buesch wrote:
>> >-----BEGIN PGP SIGNED MESSAGE-----
>> >Hash: SHA1
>> >
>> >On Monday 11 August 2003 23:11, Adrian Bunk wrote:
>> >> + 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
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.
--
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.
Steven Cole wrote:
>
> Pedantry leakage causes no shrinkage of English use wreckage.
>
Argh, to my head, this has caused much damage. :)
Christoph Hellwig wrote:
> On Mon, Aug 11, 2003 at 11:11:45PM +0200, Adrian Bunk wrote:
>
>>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?
On Tue, Aug 12, 2003 at 02:35:41PM +0100, Alan Cox wrote:
> On Llu, 2003-08-11 at 22:11, Adrian Bunk wrote:
>> + 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
On Tue, Aug 12, 2003 at 11:43:50AM -0400, Timothy Miller wrote:
>
>
> Christoph Hellwig wrote:
> >On Mon, Aug 11, 2003 at 11:11:45PM +0200, Adrian Bunk wrote:
> >
> >>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.
>...
> 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
--
"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 Seed
Timothy Miller wrote:
> 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.
Alan Cox wrote:
> On Llu, 2003-08-11 at 22:11, Adrian Bunk wrote:
>
>>+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.
> >>+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.
See the comments Linus made earlier this year on the same subject:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104457390406050&w=2
Alan, could Valgrind help us to profile cache hits/misses in different
parts of the kernel?
John.