CONFIG_TINY
Hi,
This details some new patches I have done as part of my CONFIG_TINY exploration. Executive summary: Nothing earth- shattering covered. I have made a few new patches and brought acme's initstr stuff forward (I hope. Most of it anyway.)
Patches:
o Notes: noswap, noscript, noinline, hashes kernels have been boot tested. 'all' haven't, only so much time for fun in a day.
o config: Patches arch/i386/config.in to allow selection of the patches below. Note that the noinline stuff is not configurable.
Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-config
o noswap: Disabling swap by stubbing out all of swapfile.c, swap_stat.c, page_io.c, highmem.c and some of memory.c. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-noswap
o noscript: Removing binfmt_script from the kernel. I had expected my machine to have severe difficulties booting with this one but there was no problems at all... Some think required here (for me, at least).
Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-noscript
o noinline: Same patch as last time (a forward port of an old Andrew Morton patch). I tried to do some mindless, aggressive uninlining but that expanded my kernel, so I need to think a bit more about this (yet again). Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-noinlines
o nohashes: Minimises the VFS hashes and makes the network hashes 1/16 of their former size (down to a single page). These numbers are arbitrarily chosen. Comments welcome. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-nohashes
o allinone: All of the above rolled up into one. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-allinone
o initstr: Marks strings from __init functions as __initdata. Only some of the kernel covered so far. Large patch. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-initstr
Below is a table with a 2.5.44 kernel constrasted with 2.5.44 kernels patched with the named patch (only compile time ones are listed). Size of vmlinux along with the four first columns from 'size vmlinux' are displayed.
The .config is 'allnoconfig'.
vmlinux size fields
size text data bss dec
base kernel 681405 481005 50913 252512 784430 noswap 667644 469197 50945 250144 770286 noscript 681150 480541 50877 252512 783930 noinlines 678345 476733 50913 252512 780158 allinone 664329 464445 50909 250144 765498
Note that the reason the all patch doesn't accumulate the gains from the noswap and the noinlines is that the noinlines patch touches a lot of stuff that the noswap patch subsequently disables.
As before, your comments and suggestions will be appreciated.
Regards,
Rasmus
Quoted 2 lines · Rasmus Andersen
This details some new patches I have done as part of my
CONFIG_TINYexploration.
Nice! It also looks simple enough to be mergeable at any time ;)
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Quoted 1 line · Rasmus Andersen
Hi,
Hi Rasmus,
Quoted 3 lines
...
As before, your comments and suggestions will be
appreciated.
could you try to use "-Os" instead of "-O2" as gcc optimization option when CONFIG_TINY is enabled? Something like the following (completely untested) patch:
Makefile renamed from Makefile.old +9 -1
@@ -155,8 +155,9 @@ NOSTDINC_FLAGS = -nostdinc -iwithprefix include CPPFLAGS := -D__KERNEL__ -Iinclude -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \ +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs\ -fomit-frame-pointer -fno-strict-aliasing -fno-common + AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS) export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
@@ -207,6 +208,13 @@ endif +ifdef CONFIG_TINY +CFLAGS += -Os +else +CFLAGS += -O2 +endif + + include arch/$(ARCH)/Makefile core-y += kernel/ mm/ fs/ ipc/ security/
Quoted 2 lines
Regards,
Rasmus
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 6 lines · Adrian Bunk
Quoted 1 line · Rasmus Andersen
Hi,
Hi Rasmus,
Quoted 7 lines
Quoted 3 lines
...
As before, your comments and suggestions will be
appreciated.could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:
-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 7 lines · Tom Rini
Quoted 3 lines · Adrian Bunk
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Sure CFLAGS should be configurable, but CONFIG_TINY should always prefer -Os over -O2. From 'man gcc':
-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza- tions designed to reduce code size.
If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 12 lines · Mark Mielke
Quoted 7 lines · Tom Rini
Quoted 3 lines · Adrian Bunk
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Sure CFLAGS should be configurable, but
CONFIG_TINYshould always prefer -Os over -O2. From 'man gcc':
Quoted 6 lines
-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza- tions designed to reduce code size.If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
It's not that it does regularly, it's that it can, and if it does, it's not really a gcc bug from what I recall. So I don't think CONFIG_TINY should prefer -Os over -O2 but instead we should just ask the user what level of optimization they want. Remember, one of the real important parts of embedded systems is flexibility.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 17 lines · Tom Rini
Quoted 16 lines · Mark Mielke
Quoted 7 lines · Tom Rini
Quoted 3 lines · Adrian Bunk
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Sure CFLAGS should be configurable, but
CONFIG_TINYshould always prefer -Os over -O2. From 'man gcc':-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza- tions designed to reduce code size.
Quoted 8 lines
Quoted 2 lines
If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
It's not that it does regularly, it's that it can, and if it does, it's not really a gcc bug from what I recall. So I don't think
CONFIG_TINYshould prefer -Os over -O2 but instead we should just ask the user what level of optimization they want. Remember, one of the real important parts of embedded systems is flexibility.
Thank you. This is exactly why in the last CONFIG_TINY thread I made it clear that a one-size-fits-all option is not all that helpful for serious embedded systems designers.
Collecting these parameters in a single tweaks.h file and perhaps using things like CONFIG_TINY, CONFIG_DESKTOP, CONFIG_FOO as profile selectors into tweaks.h would be a lot more effective. His collection of (hopefully) size-optimizing tweaks can all be selected via CONFIG_TINY, but have them collected at a single point like tweaks.h such that they can be individually modified by an end system integrator.
Regards,
Signature · 3 lines
Matt Porter [email protected] This is Linux Country. On a quiet night, you can hear Windows reboot.
Quoted 6 lines · Matt Porter
Thank you. This is exactly why in the last
CONFIG_TINYthread I made it clear that a one-size-fits-all option is not all that helpful for serious embedded systems designers.Collecting these parameters in a single
tweaks.hfile and perhaps using things likeCONFIG_TINY,CONFIG_DESKTOP,CONFIG_FOOas profile selectors
In an ideal world there would be several options invidually selectable.
Bernd
Signature · 4 lines
Bernd Petrovitsch Email : [email protected] g.a.m.s gmbh Fax : +43 1 205255-900 Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe LUGA : http://www.luga.at
Quoted 10 lines · Bernd Petrovitsch
Quoted 6 lines · Matt Porter
Thank you. This is exactly why in the last
CONFIG_TINYthread I made it clear that a one-size-fits-all option is not all that helpful for serious embedded systems designers.Collecting these parameters in a single
tweaks.hfile and perhaps using things likeCONFIG_TINY,CONFIG_DESKTOP,CONFIG_FOOas profile selectorsIn an ideal world there would be several options invidually selectable.
But there is? Please look at 2.5.44-config. Or did I misunderstand you. Anyways, this work is far from the point where how this is selected is a major concern.
Regards,
Rasmus
Quoted 9 lines · Rasmus Andersen
Quoted 8 lines · Bernd Petrovitsch
Quoted 6 lines · Matt Porter
Thank you. This is exactly why in the last
CONFIG_TINYthread I made it clear that a one-size-fits-all option is not all that helpful for serious embedded systems designers.Collecting these parameters in a single
tweaks.hfile and perhaps using things likeCONFIG_TINY,CONFIG_DESKTOP,CONFIG_FOOas profile selectors
Quoted 6 lines
Quoted 2 lines
In an ideal world there would be several options invidually selectable.
But there is? Please look at 2.5.44-config. Or did I misunderstand you. Anyways, this work is far from the point where how this is selected is a major concern.
There currently isn't a CONFIG_TINY / CONFIG_DESKTOP / CONFIG_FOO. The idea is that all of these changes you're working on to make a smaller kernel shouldn't all be under CONFIG_TINY, but which ones are on / off are read from some sort of template and there's a default 'tiny' template, 'desktop' 'foo', etc template which has some on and some off.
And this is a major concern since many of us who would have to deal with this when it enters the kernel want it to done in a flexible manner initially, not later on.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 9 lines · Tom Rini
There currently isn't a
CONFIG_TINY/CONFIG_DESKTOP/CONFIG_FOO. The idea is that all of these changes you're working on to make a smaller kernel shouldn't all be underCONFIG_TINY, but which ones are on / off are read from some sort of template and there's a default 'tiny' template, 'desktop' 'foo', etc template which has some on and some off.And this is a major concern since many of us who would have to deal with this when it enters the kernel want it to done in a flexible manner initially, not later on.
OK. This certainly makes sense and I'll be happy to redo my stuff to match such a framework. This is not something I have thought a lot about until now, though.
How would you go about implementing this? A central .h file with tweakables and a number of templates setting these?
Regards,
Rasmus
Quoted 11 lines · Rasmus Andersen
Quoted 9 lines · Tom Rini
There currently isn't a
CONFIG_TINY/CONFIG_DESKTOP/CONFIG_FOO. The idea is that all of these changes you're working on to make a smaller kernel shouldn't all be underCONFIG_TINY, but which ones are on / off are read from some sort of template and there's a default 'tiny' template, 'desktop' 'foo', etc template which has some on and some off.And this is a major concern since many of us who would have to deal with this when it enters the kernel want it to done in a flexible manner initially, not later on.
Quoted 6 lines
OK. This certainly makes sense and I'll be happy to redo my stuff to match such a framework. This is not something I have thought a lot about until now, though.
How would you go about implementing this? A central .h file with tweakables and a number of templates setting these?
I'm still trying to figure out exactly how to do this so that we don't clutter up the more generic code. But some sort of tweaks.h, which would include <asm/tiny_tweaks.h> or <asm/desktop_tweaks.h> (and maybe an asm-generic/tiny_tweaks.h for non arch-specific parts).
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 1 line · Rasmus Andersen
On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
[...]
Quoted 4 lines
Quoted 2 lines
In an ideal world there would be several options invidually selectable.
But there is? Please look at 2.5.44-config. Or did I misunderstand
ACK. Ooops, sorry, this part of the world is ideal. Hmm, which of the 2.5.44 patches (from
http://www.jaquet.dk/kernel/config_tiny/) are to be applied? Applying all seem to work but some config options are duplicated.
Bernd
Signature · 4 lines
Bernd Petrovitsch Email : [email protected] g.a.m.s gmbh Fax : +43 1 205255-900 Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe LUGA : http://www.luga.at
Quoted 6 lines · Bernd Petrovitsch
Quoted 1 line · Rasmus Andersen
On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
[...]
Quoted 3 lines
Quoted 2 lines
In an ideal world there would be several options invidually selectable.
Quoted 7 lines
Quoted 1 line
But there is? Please look at 2.5.44-config. Or did I misunderstand
ACK. Ooops, sorry, this part of the world is ideal. Hmm, which of the 2.5.44 patches (from
http://www.jaquet.dk/kernel/config_tiny/) are to be applied? Applying all seem to work but some config options are duplicated.
Could you provide a little more detail? This is not by design :) Keep in mind that the 'allinone' patch encompasses all of the others. And that only 2.5.44-* are of interest.
Regards,
Rasmus
Quoted 1 line · Rasmus Andersen
On Fri, Nov 01, 2002 at 12:30:14AM +0100, Bernd Petrovitsch wrote:
[...]
Quoted 7 lines
Quoted 3 lines
Hmm, which of the 2.5.44 patches (from
http://www.jaquet.dk/kernel/config_tiny/) are to be applied? Applying all seem to work but some config options are duplicated.Could you provide a little more detail? This is not by design :) Keep in mind that the 'allinone' patch encompasses all of the others. And that only 2.5.44-* are of interest.
I see on http://www.jaquet.dk/kernel/config_tiny/ the following list of 2.5.44 patches:
---- snip ----
2.5.44-allinone 30-Oct-2002 23:15 23k 2.5.44-config 30-Oct-2002 23:15 1k 2.5.44-initstr 30-Oct-2002 23:11 183k 2.5.44-nohashes 30-Oct-2002 23:11 3k 2.5.44-noinlines 30-Oct-2002 23:19 14k 2.5.44-noscript 30-Oct-2002 23:11 1k 2.5.44-noswap 30-Oct-2002 23:10 6k
---- snip ----
Just looking at the patch sizes, I thought all are independent (though "allinone" indicates something different). So I applied all to one tree (which gave the above mentioned result).
Now playing around with the patches shows that 2.5.44-allinone apparently contains all others _except_ 2.5.44-initstr which is completely independent.
Sorry for the confusion.
Bernd
Signature · 4 lines
Bernd Petrovitsch Email : [email protected] g.a.m.s gmbh Fax : +43 1 205255-900 Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe LUGA : http://www.luga.at
(Trimmed CC down, this is getting specific).
Quoted 6 lines · Bernd Petrovitsch
Just looking at the patch sizes, I thought all are independent (though "allinone" indicates something different). So I applied all to one tree (which gave the above mentioned result).
Now playing around with the patches shows that 2.5.44-allinone apparently contains all others _except_ 2.5.44-initstr which is completely independent.
Yes. Sorry for not stating that more explicitly in my original mail.
Quoted 1 line
Sorry for the confusion.
On the contrary: I am sorry.
Regards,
Rasmus
Quoted 7 lines · Tom Rini
Quoted 2 lines
If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
It's not that it does regularly, it's that it can, and if it does, it's not really a gcc bug from what I recall. So I don't think
CONFIG_TINYshould prefer -Os over -O2 but instead we should just ask the user what level of optimization they want. Remember, one of the real important parts of embedded systems is flexibility.
Not to stretch this point too long, but turning off inlined functions 'can' make code bigger too. It usually doesn't.
I have no problem with the other suggestion that CONFIG_TINY specify a template for a set of build options, but if CONFIG_TINY is used (either as an option, or a template of options) -Os should always be preferred over -O2. Whether the user can still override this or not is a different issue from whether -Os should be preferred over -O2 when CONFIG_TINY is specified.
Or specified more clearly: If the compiler optimization flag is configurable, choosing CONFIG_TINY should default the optimization flag to -Os before it defaults the optimization flag to -O2.
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 19 lines · Mark Mielke
Quoted 7 lines · Tom Rini
Quoted 2 lines
If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
It's not that it does regularly, it's that it can, and if it does, it's not really a gcc bug from what I recall. So I don't think
CONFIG_TINYshould prefer -Os over -O2 but instead we should just ask the user what level of optimization they want. Remember, one of the real important parts of embedded systems is flexibility.Not to stretch this point too long, but turning off inlined functions 'can' make code bigger too. It usually doesn't.
I have no problem with the other suggestion that
CONFIG_TINYspecify a template for a set of build options, but ifCONFIG_TINYis used (either as an option, or a template of options) -Os should always be preferred over -O2. Whether the user can still override this or not is a different issue from whether -Os should be preferred over -O2 whenCONFIG_TINYis specified.
Quoted 3 lines
Or specified more clearly: If the compiler optimization flag is configurable, choosing
CONFIG_TINYshould default the optimization flag to -Os before it defaults the optimization flag to -O2.
You're still missing the point of flexibility remark. Changing the optimization level has nothing to do with CONFIG_TINY, and is a generally useful option, and should be done seperate from CONFIG_TINY. In fact people seem to be getting the wrong idea about CONFIG_TINY. We don't need a CONFIG_TINY, we need CONFIG_FINE_TUNE. Different 'tiny' projects need different things. And when you take into account that the embedded world is a whole lot of !i386, the fact that -Os hasn't been as well tested on !i386, you introduce the possibility of compiler bugs sneaking in as well.
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up. Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier CONFIG_TINY threads, his Athlon could benefit from some of these 'tiny' options too.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 9 lines · Tom Rini
Quoted 3 lines · Mark Mielke
Or specified more clearly: If the compiler optimization flag is configurable, choosing
CONFIG_TINYshould default the optimization flag to -Os before it defaults the optimization flag to -O2.You're still missing the point of flexibility remark. Changing the optimization level has nothing to do with
CONFIG_TINY, and is a generally useful option, and should be done seperate fromCONFIG_TINY. In fact people seem to be getting the wrong idea aboutCONFIG_TINY. We
...
Please read it again... even if the optimization flag was configurable, choosing CONFIG_TINY should *default* the optimization flag to -Os before it defaults the optimization flag to -O2.
In the case where CONFIG_TINY is an option on its own, it means using -Os instead of -O2. In the case where CONFIG_TINY is a template *not an option*, the configurable "optimization flag" gets initialized to -Os. You could still override -Os to be -O2 if you wanted to, or if CONFIG_TINY was not specified, you could still override -O2 to be -Os... the default is -Os for CONFIG_TINY.
K... I don't think this needs any more time.
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 11 lines · Mark Mielke
Quoted 9 lines · Tom Rini
Quoted 3 lines · Mark Mielke
Or specified more clearly: If the compiler optimization flag is configurable, choosing
CONFIG_TINYshould default the optimization flag to -Os before it defaults the optimization flag to -O2.You're still missing the point of flexibility remark. Changing the optimization level has nothing to do with
CONFIG_TINY, and is a generally useful option, and should be done seperate fromCONFIG_TINY. In fact people seem to be getting the wrong idea aboutCONFIG_TINY. We
...
Quoted 3 lines
Please read it again... even if the optimization flag was configurable, choosing
CONFIG_TINYshould *default* the optimization flag to -Os before it defaults the optimization flag to -O2.
Yes, and I'm saying that CONFIG_TINY shouldn't exist. It should be CONFIG_FINE_TUNE (or so), to allow anyone to fine tune the optimization level. Changing optimization levels is a speed / size tradeoff (if it wasn't, there wouldn't be -O2 / -Os, they would do the same thing) which you cannot pick a sane default for.
Quoted 6 lines
In the case where
CONFIG_TINYis an option on its own, it means using -Os instead of -O2. In the case whereCONFIG_TINYis a template *not an option*, the configurable "optimization flag" gets initialized to -Os. You could still override -Os to be -O2 if you wanted to, or ifCONFIG_TINYwas not specified, you could still override -O2 to be -Os... the default is -Os forCONFIG_TINY.
You're still falling into the 'embedded must mean small!' trap. The template should default to the well tested -O2, not the less tested -Os.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 3 lines · Tom Rini
Yes, and I'm saying that
CONFIG_TINYshouldn't exist. It should beCONFIG_FINE_TUNE(or so), to allow anyone to fine tune the optimization level.
If the flexibility is wanted then it should be something like:CONFIG_TINY_GCCOPTFLAG
default 2
It should be a string so the developer can choose freely the optimisation level.
Sam
Quoted 9 lines · Sam Ravnborg
Quoted 3 lines · Tom Rini
Yes, and I'm saying that
CONFIG_TINYshouldn't exist. It should beCONFIG_FINE_TUNE(or so), to allow anyone to fine tune the optimization level.If the flexibility is wanted then it should be something like:
CONFIG_TINY_GCCOPTFLAG
default 2
It should be a string so the developer can choose freely the optimisation level.
Except that it has nothing to do with TINY.
This is where the templates idea that Matt Porter has mentioned comes in nicely. Not just 'embedded' can make use of tweaks, everyone can. And the default template would be the defaults now, and can be tweaked easily (and maybe something to select a basic set of defaults, etc).
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 17 lines · Tom Rini
Quoted 11 lines · Mark Mielke
Quoted 9 lines · Tom Rini
Quoted 3 lines · Mark Mielke
Or specified more clearly: If the compiler optimization flag is configurable, choosing
CONFIG_TINYshould default the optimization flag to -Os before it defaults the optimization flag to -O2.You're still missing the point of flexibility remark. Changing the optimization level has nothing to do with
CONFIG_TINY, and is a generally useful option, and should be done seperate fromCONFIG_TINY. In fact people seem to be getting the wrong idea aboutCONFIG_TINY. We
...Quoted 3 lines
Please read it again... even if the optimization flag was configurable, choosing
CONFIG_TINYshould *default* the optimization flag to -Os before it defaults the optimization flag to -O2.
Quoted 5 lines
Yes, and I'm saying that
CONFIG_TINYshouldn't exist. It should beCONFIG_FINE_TUNE(or so), to allow anyone to fine tune the optimization level. Changing optimization levels is a speed / size tradeoff (if it wasn't, there wouldn't be -O2 / -Os, they would do the same thing) which you cannot pick a sane default for.
By that reasoning there shouldn't be -O2 either, everyone should be forced to diddle everything for their architecture, cache size, gcc revision, patch level... does that sound as unrealistic to you as it does to me? -Os is a default, just like -O2, and if you want small -Os is probably a better starting point.
As noted in another note, anyone good enough to make those decisions is probably able to find a string in a Makefile.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 25 lines · Bill Davidsen
Quoted 17 lines · Tom Rini
Quoted 11 lines · Mark Mielke
Quoted 9 lines · Tom Rini
Quoted 3 lines · Mark Mielke
Or specified more clearly: If the compiler optimization flag is configurable, choosing
CONFIG_TINYshould default the optimization flag to -Os before it defaults the optimization flag to -O2.You're still missing the point of flexibility remark. Changing the optimization level has nothing to do with
CONFIG_TINY, and is a generally useful option, and should be done seperate fromCONFIG_TINY. In fact people seem to be getting the wrong idea aboutCONFIG_TINY. We
...Quoted 3 lines
Please read it again... even if the optimization flag was configurable, choosing
CONFIG_TINYshould *default* the optimization flag to -Os before it defaults the optimization flag to -O2.Quoted 5 lines
Yes, and I'm saying that
CONFIG_TINYshouldn't exist. It should beCONFIG_FINE_TUNE(or so), to allow anyone to fine tune the optimization level. Changing optimization levels is a speed / size tradeoff (if it wasn't, there wouldn't be -O2 / -Os, they would do the same thing) which you cannot pick a sane default for.
Quoted 5 lines
By that reasoning there shouldn't be -O2 either, everyone should be forced to diddle everything for their architecture, cache size, gcc revision, patch level... does that sound as unrealistic to you as it does to me? -Os is a default, just like -O2, and if you want small -Os is probably a better starting point.
You're making the assumption that the biggest problem facing embedded Linux developers is that the kernel is too big and that the size must be reduced at all costs. It's not. It's that trying to tweak things which aren't trivial to do (unlike changing the optimization level) require an indepth knowledge of the subsystem. It doesn't have to be this way.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 2 lines · Tom Rini
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up.
Please, no. Keep this simple.
I don't want a bunch of configs that abstract out everything I might want to tamper with to make a small system. The only way I am going to make sense out of them will be to look at the source controlled by each anyway. I would rather search the source for CONFIG_TINY and see a single, coherent, and sensible set of concrete changes that make things smaller. Let me mangle and customize from there, it will be much easier for me to understand what I am doing.
Quoted 3 lines
Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier
CONFIG_TINYthreads, his Athlon could benefit from some of these 'tiny' options too.
Certainly, if there are potential config options that would be truly useful to general folks, then by all means, yes!, make them separate options. (Isn't that what has been going on all along?) But let us not put in a config for every imaginable tuning and then pretend that hiding them behind a CONFIG_FINE_TUNE somehow doesn't make them any less a groady mess.
Isn't there an attempt with the current config process to set up dependencies so that any config from "make config" or "make xconfig" has a crack at being at least self-consistent, if not otherwise sensible? Won't this CONFIG_FINE_TUNE become a bloating ground for every obscure special interest config, related to size or not, whether it builds or not, whether it runs of not? (And be so confusing as to still not help me build a tiny kernel?)
If something is worth a config, give it a config. (And if it isn't, don't!) But not every component of making a tiny system is worth a standalone config. Let me grep for CONFIG_TINY and hack my nonstandard things from there.
-kb, the Kent who thinks the language in which the kernel is written should remain C and not drift toward being the config file.
P.S. This reminds me of not littering the code with type defs that reduce to simple types. Abstraction for abstraction's sake seems silly. Keep it simple.
Quoted 5 lines · Kent Borg
Quoted 2 lines · Tom Rini
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up.
Please, no. Keep this simple.
We can keep it simple, as long as we keep it flexible.
Quoted 7 lines
I don't want a bunch of configs that abstract out everything I might want to tamper with to make a small system. The only way I am going to make sense out of them will be to look at the source controlled by each anyway. I would rather search the source for
CONFIG_TINYand see a single, coherent, and sensible set of concrete changes that make things smaller. Let me mangle and customize from there, it will be much easier for me to understand what I am doing.
Templates would help out here. Right now, if something isn't a config option, you have to dig into the source to tune things. This isn't really nice since to tweak most things you only need to change a few constants. The problem is finding all of these constants, and the places where maybe someone used a number derrived from the constant, and so on..
Quoted 7 lines
Quoted 3 lines
Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier
CONFIG_TINYthreads, his Athlon could benefit from some of these 'tiny' options too.Certainly, if there are potential config options that would be truly useful to general folks, then by all means, yes!, make them separate options. (Isn't that what has been going on all along?)
I would hope it was, but it doesn't seem like that's been what's going on..
Quoted 4 lines
But let us
not put in a config for every imaginable tuning and then pretend that hiding them behind aCONFIG_FINE_TUNEsomehow doesn't make them any less a groady mess.
Let's not pretend that changing > 1 tunable param with 1 CONFIG question makes it any better than it is now.
Quoted 7 lines
Isn't there an attempt with the current config process to set up dependencies so that any config from "make config" or "make xconfig" has a crack at being at least self-consistent, if not otherwise sensible? Won't this
CONFIG_FINE_TUNEbecome a bloating ground for every obscure special interest config, related to size or not, whether it builds or not, whether it runs of not? (And be so confusing as to still not help me build a tiny kernel?)
Building a 'tiny' kernel should have nothing to do with any of this. Don't think 'tiny' think 'flexible'. And I'm not necessarily saying it has to be N CONFIG options (Matt Porter's template idea is rather tempting), just that things have to be:
a) Flexible enough such that someone who wants to tweak param X doesn't have to know every intricate detail of subsystem Y just to tune things.
b) Done in a way that doesn't clutter up the code in question (ideally s/some_constant/SOME_DEFINE).
c) Be simple enough such that people don't shoot their feet off, at least not unintentionally.
Quoted 4 lines
If something is worth a config, give it a config. (And if it isn't, don't!) But not every component of making a tiny system is worth a standalone config. Let me grep for
CONFIG_TINYand hack my nonstandard things from there.
By that token, if it's not worth it's own CONFIG, don't mask it under 1 CONFIG either. That doesn't make it easier to tune one param if you have to check N occurances of CONFIG_TINY to make sure you got all of the correct places.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 8 lines · Tom Rini
Quoted 5 lines · Kent Borg
Quoted 2 lines · Tom Rini
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up.
Please, no. Keep this simple.
We can keep it simple, as long as we keep it flexible.
If having the source isn't enough flexibility for you, it's not possible TO have enough flexibility for you.
The point of CONFIG_TINY is that anybody interested in looking at how to trim the fat on their kernel has something to grep for, and it's als a quick and dirty way to say "this kernel will go on boot floppy or eprom boot image" without having to spend two days micro-managing.
Having "config_8_million_tweaks" is actually counter-productive. It's quite possible to give people so many buttons and levers they can't find the two they're interested in, and there will ALWAYS be instances where you have to go diddle the source.
Are you seriously suggesting that every single #defined constant should be editable from make menuconfig? If not, you acknowledge that there IS a line that needs to be drawn. And the place it has CURRENTLY been drawn (what IS in make menuconfig) is a darn good starting point for discussion of where it should be.
Quoted 10 lines
Quoted 7 lines
I don't want a bunch of configs that abstract out everything I might want to tamper with to make a small system. The only way I am going to make sense out of them will be to look at the source controlled by each anyway. I would rather search the source for
CONFIG_TINYand see a single, coherent, and sensible set of concrete changes that make things smaller. Let me mangle and customize from there, it will be much easier for me to understand what I am doing.Templates would help out here. Right now, if something isn't a config option, you have to dig into the source to tune things.
More or less by definition, yes.
Quoted 3 lines
This isn't
really nice since to tweak most things you only need to change a few constants.
You're against people having to modify the source at all, then. That argument's not going far around here, you realise this don't you?
Quoted 3 lines
The problem is finding all of these constants, and the places where maybe someone used a number derrived from the constant, and so on..
1) This is a seperate argument. Your'e trying to bolt your personal pet project on to the CONFIG_TINY discussion, and they have nothing to do with each other.
2) Provide a patch. The CONFIG_TINY people have a patch. You do not. You lose.
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier
CONFIG_TINYthreads, his Athlon could benefit from some of these 'tiny' options too.Certainly, if there are potential config options that would be truly useful to general folks, then by all means, yes!, make them separate options. (Isn't that what has been going on all along?)
I would hope it was, but it doesn't seem like that's been what's going on..
Because you haven't personally done it, and nobody else seems to be interested.
Quoted 7 lines
Quoted 4 lines
But let us
not put in a config for every imaginable tuning and then pretend that hiding them behind aCONFIG_FINE_TUNEsomehow doesn't make them any less a groady mess.Let's not pretend that changing > 1 tunable param with 1 CONFIG question makes it any better than it is now.
Let's not pretend having one config option for every #define in anything more than a semantic difference as far as the #defines are concerned, and on top of that it lowers the value of menuconfig by polluting it with stuff that very few people should ever have to care about.
Quoted 1 line
Building a 'tiny' kernel should have nothing to do with any of this.
Oh good, we agree on something.
Start a new thread then, and stop objecting to CONFIG_TINY.
Quoted 1 line
Don't think 'tiny' think 'flexible'.
Nobody's working on CONFIG_FLEXIBLE. You're trying to hijack a project with a different agenda because it doesn't do something totally unrelated that you think should be done.
Quoted 5 lines
And I'm not necessarily saying it
has to be N CONFIG options (Matt Porter's template idea is rather tempting), just that things have to be:
a) Flexible enough such that someone who wants to tweak param X doesn't have to know every intricate detail of subsystem Y just to tune things.
And the universe in general should be easily manipulated by people who don't understand how it actually works. This is called "magic".
Quoted 4 lines
b) Done in a way that doesn't clutter up the code in question (ideally s/some_constant/SOME_DEFINE).
c) Be simple enough such that people don't shoot their feet off, at least not unintentionally.
It should also have the ability to turn lead into gold and make people younger. I don't think you'll find anybody who disagrees that these would be great things for it to be able to do.
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 10 lines · Rob Landley
Quoted 8 lines · Tom Rini
Quoted 5 lines · Kent Borg
Quoted 2 lines · Tom Rini
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up.
Please, no. Keep this simple.
We can keep it simple, as long as we keep it flexible.
Quoted 7 lines
If having the source isn't enough flexibility for you, it's not possible TO have enough flexibility for you.
The point of
CONFIG_TINYis that anybody interested in looking at how to trim the fat on their kernel has something to grep for, and it's als a quick and dirty way to say "this kernel will go on boot floppy or eprom boot image" without having to spend two days micro-managing.
With the way CONFIG_TINY is now you still have to have a good deal of knowledge of the source and look at N different files and hope that you did manage to catch all of the places that CONFIG_TINY really did effect the area you want. And that the author of new subsystem Y takes advantage of CONFIG_TINY and works things out appropriately. I want (and I will try and get working this week if I have time) 1 place where you have to change things.
Quoted 10 lines
Having "
config_8_million_tweaks" is actually counter-productive. It's quite possible to give people so many buttons and levers they can't find the two they're interested in, and there will ALWAYS be instances where you have to go diddle the source.Are you seriously suggesting that every single #defined constant should be editable from make menuconfig? If not, you acknowledge that there IS a line that needs to be drawn. And the place it has CURRENTLY been drawn (what IS in make menuconfig) is a darn good starting point for discussion of where it should be.
No, I have been talked out of doing config options as a better solution, the problem with doing templates (which I'm trying to figure out how to do now) is how to do it in a manner which doesn't uglify the source.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
I don't want a bunch of configs that abstract out everything I might want to tamper with to make a small system. The only way I am going to make sense out of them will be to look at the source controlled by each anyway. I would rather search the source for
CONFIG_TINYand see a single, coherent, and sensible set of concrete changes that make things smaller. Let me mangle and customize from there, it will be much easier for me to understand what I am doing.
Quoted 4 lines
Quoted 2 lines
Templates would help out here. Right now, if something isn't a config option, you have to dig into the source to tune things.
More or less by definition, yes.
Which leads to missing places where the original coder used SOME_CONST / 4 directly instead of (SOME_CONST / 4). We had this problem on PPC for a while when people would want to get 1gb of RAM w/o using CONFIG_HIGHMEM. We've since solved this quite nicely.
Quoted 6 lines
Quoted 3 lines
This isn't
really nice since to tweak most things you only need to change a few constants.You're against people having to modify the source at all, then. That argument's not going far around here, you realise this don't you?
I'm against making it harder to tweak things than needed.
Quoted 7 lines
Quoted 3 lines
The problem is finding all of these constants, and the places where maybe someone used a number derrived from the constant, and so on..
1) This is a seperate argument. Your'e trying to bolt your personal pet project on to the
CONFIG_TINYdiscussion, and they have nothing to do with each other.
CONFIG_TINY is an attempt to make it 'easier' on the embedded world. I work in the embedded world. I'm trying to point out that kernel size is not the biggest problem facing embedded linux people. It's making the kernel flexible enough, without being a guru of every subsystem you need to change.
Quoted 2 lines
2) Provide a patch. The
CONFIG_TINYpeople have a patch. You do not. You lose.
bk://ppc.bkbits.net/linuxppc-2.5, CONFIG_ADVANCED_OPTIONS (or !) is sort-of how I want the code to look (I just don't have templates yet since doing that, without massive modifications to the code (except for changing 0x1234 into a define) is non-trivial). If you want to change HIGHMEM/LOWMEM/KERNELLOAD, etc it's quite trivial and it didn't require any real uglification of the code.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier
CONFIG_TINYthreads, his Athlon could benefit from some of these 'tiny' options too.Certainly, if there are potential config options that would be truly useful to general folks, then by all means, yes!, make them separate options. (Isn't that what has been going on all along?)
Quoted 5 lines
Quoted 2 lines
I would hope it was, but it doesn't seem like that's been what's going on..
Because you haven't personally done it, and nobody else seems to be interested.
Well, Alan did mention in the original thread that lots of desktop boxes could make use of some of these things too, and I was hoping that it would be picked up on myself. But yes, this is on my todo list, along with school and other things.
Quoted 3 lines
Quoted 1 line
Building a 'tiny' kernel should have nothing to do with any of this.
Oh good, we agree on something.
:P
Quoted 5 lines
Quoted 1 line
Don't think 'tiny' think 'flexible'.
Nobody's working on
CONFIG_FLEXIBLE. You're trying to hijack a project with a different agenda because it doesn't do something totally unrelated that you think should be done.
CONFIG_TINY aims at producing a kernel because that's seen as the largest problem facing embedded linux people. I'm trying to convince people that it is not. It's being flexible enough to easily adapt the kernel for any systems use.
Quoted 8 lines
Quoted 5 lines
And I'm not necessarily saying it
has to be N CONFIG options (Matt Porter's template idea is rather tempting), just that things have to be:
a) Flexible enough such that someone who wants to tweak param X doesn't have to know every intricate detail of subsystem Y just to tune things.And the universe in general should be easily manipulated by people who don't understand how it actually works. This is called "magic".
If you don't understand how something generally works, you can't reasonably expect to be able to change it, I agree. But if you do understand how something works in general, you shouldn't need to be a subsystem guru of kernel version X.Y.Z to tweak things for your application.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
I'm with you on that. People who clammer ignorantly about image size without looking at what they actually need should have opened their eyes in the last few years. Flash and RAM sizes under 32M are nearly unheard of now-a-days.
It would be a real disaster to construct a screwy and hard-to-maintain config system in order to achieve something that isn't necessary. Image size does matter sometimes but a _maintainable_ and easy to use config system is far more important.
There are cases where squeezing the image is necessary for extremely specific applications of the system but those are darn rare now.
} CONFIG_TINY is an attempt to make it 'easier' on the embedded world. I } work in the embedded world. I'm trying to point out that kernel size is } not the biggest problem facing embedded linux people. It's making the } kernel flexible enough, without being a guru of every subsystem you need } to change.
Quoted 4 lines · Cort Dougan
I'm with you on that. People who clammer ignorantly about image size without looking at what they actually need should have opened their eyes in the last few years. Flash and RAM sizes under 32M are nearly unheard of now-a-days.
How much power does flash eat? I was under the impression half the reason for tiny amounts of memory was to increase battery life in things that really should last weeks or months instead of hours (wristwatches, cell phones on standby, etc), but I guess that's mostly a question of dram and sram, not flash. (I take it you can read the heck out of it without wearing it out, it's just writes that are a problem... Then again you don't want rapidly rewritten bookkeeping stuff in flash, do you? (Jiffies, scheduler stuff, etc, should not be in flash...))
Not my area, I'm afraid...
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 9 lines · Rob Landley
Quoted 4 lines · Cort Dougan
I'm with you on that. People who clammer ignorantly about image size without looking at what they actually need should have opened their eyes in the last few years. Flash and RAM sizes under 32M are nearly unheard of now-a-days.
How much power does flash eat? I was under the impression half the reason for tiny amounts of memory was to increase battery life in things that really should last weeks or months instead of hours (wristwatches, cell phones on standby, etc), but I guess that's mostly a question of dram and sram, not flash. (I take it you can read the heck out of it without wearing it out, it's just writes that are a problem... Then again you don't want rapidly rewritten bookkeeping stuff in flash, do you? (Jiffies, scheduler stuff, etc, should not be in flash...))
There a couple of kinds of flash memory that have different properties in the writes...
The one I'm more familiar with allows you to change any '1' bit to a '0' bit on a bit-by-bit basis, but it is, ehm, a tad slow. But if you want to change a '0' bit to a '1' bit, you have to erase a 16 or 32 kB block to all '1' bits, and that is, well, very slow. (Storing 'jiffies' in flash, given that updating the jiffies would take multiple jiffies would be, well, 'fun'. ;) I could, however, see some sense in running the read-only parts of the kernel directly from flash...) It's been a while since I looked at read times, but I expect it to be essentially memory speeds.
Quoted 3 lines
Not my area, I'm afraid...
Rob
Just an FYI, in case you're curious.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
---------------------------------------------------------
Confidentiality Notice: This e-mail transmission may contain
confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you.
Inet Technologies, Inc.
---------------------------------------------------------
Em Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini escreveu:
Quoted 5 lines
In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about anything / everything which might want to be tuned up. Then this becomes a truely useful set of options, since as Alan pointed out in one of the earlier
CONFIG_TINYthreads, his Athlon could benefit from some of these 'tiny' options too.
CONFIG_TINY would be just a way to enable all the CONFIG_FINE_TUNE_WHATEVER options that reduce image size.
- Arnaldo
Quoted 12 lines · Mark Mielke
Quoted 8 lines · Tom Rini
Quoted 2 lines
If gcc regularly generates larger code with -Os the answer is to talk to the gcc people, not to avoid using -Os...
It's not that it does regularly, it's that it can, and if it does, it's not really a gcc bug from what I recall. So I don't think
CONFIG_TINYshould prefer -Os over -O2 but instead we should just ask the user what level of optimization they want. Remember, one of the real important parts of embedded systems is flexibility.
Quoted 3 lines
Not to stretch this point too long, but turning off inlined functions 'can' make code bigger too. It usually doesn't.
GCC's -finline-limit=n should help to control this.
--
Luc Van Oostenryck
Yes, madam, I am drunk.
But in the morning I will be sober and you will still be ugly.
-- Winston Churchill
Quoted 7 lines · Tom Rini
Quoted 6 lines · Adrian Bunk
Quoted 3 lines · Rasmus Andersen
...
As before, your comments and suggestions will be
appreciated.
Quoted 7 lines
Quoted 3 lines
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Sure, and unrolling loops can cause cache misses and be slower than that jmp back in a loop. The point is this is a string, the people who think they're able to hand diddle the options can change it. And more to the point anyone who can't find a string in a makefile shouldn't be second guessing the compiler anyway.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 17 lines · Bill Davidsen
Quoted 7 lines · Tom Rini
Quoted 6 lines · Adrian Bunk
Quoted 3 lines · Rasmus Andersen
...
As before, your comments and suggestions will be
appreciated.Quoted 7 lines
Quoted 3 lines
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:-Os can produce larger binaries, keep in mind. If we're going to go this route, how about something generally useful, and allow for general optimization level / additional CFLAGS to be added.
Quoted 5 lines
Sure, and unrolling loops can cause cache misses and be slower than that jmp back in a loop. The point is this is a string, the people who think they're able to hand diddle the options can change it. And more to the point anyone who can't find a string in a makefile shouldn't be second guessing the compiler anyway.
Yes, so why can't those who still need a few more kB after trying some of the other options go and find '-O2' and replace it with '-Os' ?
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 8 lines · Tom Rini
Quoted 5 lines
Sure, and unrolling loops can cause cache misses and be slower than that jmp back in a loop. The point is this is a string, the people who think they're able to hand diddle the options can change it. And more to the point anyone who can't find a string in a makefile shouldn't be second guessing the compiler anyway.
Yes, so why can't those who still need a few more kB after trying some of the other options go and find '-O2' and replace it with '-Os' ?
Because the point of CONFIG_TINY is to make the kernel smaller and this is something that makes the kernel smaller? (In fact telling the compiler "optimize for size" is one of the most OBVIOUS things to do?)
I've used -Os. I've compiled dozens and dozens of packages with -Os. It has always saved at least a few bytes, I have yet to see it make something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 11 lines · Rob Landley
Quoted 8 lines · Tom Rini
Quoted 5 lines
Sure, and unrolling loops can cause cache misses and be slower than that jmp back in a loop. The point is this is a string, the people who think they're able to hand diddle the options can change it. And more to the point anyone who can't find a string in a makefile shouldn't be second guessing the compiler anyway.
Yes, so why can't those who still need a few more kB after trying some of the other options go and find '-O2' and replace it with '-Os' ?
Quoted 8 lines
Because the point of
CONFIG_TINYis to make the kernel smaller and this is something that makes the kernel smaller? (In fact telling the compiler "optimize for size" is one of the most OBVIOUS things to do?)I've used -Os. I've compiled dozens and dozens of packages with -Os. It has always saved at least a few bytes, I have yet to see it make something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.
Then we don't we always use -Os?
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 8 lines · Tom Rini
Quoted 4 lines · Rob Landley
I've used -Os. I've compiled dozens and dozens of packages with -Os. It has always saved at least a few bytes, I have yet to see it make something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.
Then we don't we always use -Os?
I normally do, actually. Works For Me (tm). Dunno about all possible architectures or all kernel versions, but then compiling WITHOUT -O2 apparently produces an unusable kernel due to some missing needed inlines, so...
There's also a drive to "inline less stuff" underway, which I consider vaguely related...
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 8 lines · Tom Rini
Quoted 4 lines · Rob Landley
I've used -Os. I've compiled dozens and dozens of packages with -Os. It has always saved at least a few bytes, I have yet to see it make something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.
Then we don't we always use -Os?
1 - I'm not sure all versions of gcc support it, as in "it generates correct code."
2 - I'm not sure how (if) it works on non-Intel systems.
3 - The performance gain is related to cache size and performance. The obvious case is unrolling loops, you win if they fit in cache. If you have a Celeron, P-III with 256k, P-4 with HT on, all have different cache behaviour. And SMP or memory speed changes the penalty for a cache miss to main memory.
4 - inertia, minimal gain and experience. Maybe no one sees enough gain to justify the chance that some version of gcc is really broken.
5 - placebo effect. People just think it's faster because it's different.
6 - quantum effects, like Schroedinger's (sp?) cat it's only faster or slower if you measure it.
Pick one or more of these as pleases you. My mind say 4, my heart says 5+6.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines · Bill Davidsen
Quoted 1 line
Then we don't we always use -Os?
1 - I'm not sure all versions of gcc support it, as in "it generates correct code."
2.95 built with -Os was I believe used by Caldera and turned out faster code than -O2. For 3.2 -O2 appears faster {yes I know microbenchmarking is not the full picture}
Quoted 11 lines · Bill Davidsen
Quoted 8 lines · Tom Rini
Quoted 4 lines · Rob Landley
I've used -Os. I've compiled dozens and dozens of packages with -Os. It has always saved at least a few bytes, I have yet to see it make something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.
Then we don't we always use -Os?
[snip 6 good reasons]
So why do we want to force it on for CONFIG_TINY?
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 11 lines · Tom Rini
Quoted 8 lines · Bill Davidsen
Quoted 7 lines · Tom Rini
Quoted 4 lines · Rob Landley
I've used -Os. I've compiled dozens and dozens of packages with -Os.
It has always saved at least a few bytes, I have yet to see it make
something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.Then we don't we always use -Os?
[snip 6 good reasons]
Reasons 1 and 2 were that you can't be sure it works on all compiler versions and all platforms until you'e tried it, which you could say about anything.
Reason 3, 5, and 6 were about performance gains, when the point of CONFIG_TINY is, in fact, size.
Reason 4 is inertia. You are explicitly considering inertia a good reason, then? I remember back around 1998, the argument over "-fno-strength-reduce" which accomplished nothing whatsoever (and was in fact disabled in gcc 2.7.x for i386) but was in the kernel compile for a long time becaue nobody could be bothered to remove it...
Quoted 1 line
So why do we want to force it on for
CONFIG_TINY?
1) The point of CONFIG_TINY is size?
2) Why is any change a "force" when you have the source code? Isn't "force" an intentionally loaded word? I could just as easily say your objection still boils down to "I don't want a switch that actually does something, I want somebody to print out a to-do list and mail it to me so I can go through the kernel by hand and remove support for floppy drives other than the actual type I have from the legacy boot sector at the start of the kernel image." If you want to get into loaded words.
The setting in question is a default value. CONFIG_TINY sets a lot of defaults at once, and gives you something grep for if you don't like them. I realise this isn't what you want, but objecting to patches because they're completely unrelated to what you want is kind of silly.
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 4 lines · Rob Landley
Quoted 3 lines · Tom Rini
Quoted 2 lines · Bill Davidsen
Quoted 1 line · Tom Rini
On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
I've used -Os. I've compiled dozens and dozens of packages with -Os.
It has always saved at least a few bytes, I have yet to see it make
something larger. And in the benchmarks I've done, the smaller code actually runs slightly faster. More of it fits in cache, you know.Then we don't we always use -Os?
[snip 6 good reasons]
Okay, let's just call it 5 then...
Quoted 3 lines
Reasons 1 and 2 were that you can't be sure it works on all compiler versions and all platforms until you'e tried it, which you could say about anything.
Not every kernel person wants to, knows how to, or should have to debug the compiler as well.
Quoted 2 lines
Reason 3, 5, and 6 were about performance gains, when the point of
CONFIG_TINYis, in fact, size.
CONFIG_TINY is in fact about asking questions which should reduce the size, and allowing the user to determine space / speed tradeoffs.
Quoted 3 lines
Quoted 1 line
So why do we want to force it on for
CONFIG_TINY?1) The point of
CONFIG_TINYis size?
The point of CONFIG_TINY, as in the current patches is to offer a bunch of tunables. From what I read of the patch, nothing actually uses CONFIG_TINY, except for config.in bits. Therefore the point of CONFIG_TINY is not about size, it's about asking questions. So ask another question.
Quoted 4 lines
The setting in question is a default value.
CONFIG_TINYsets a lot of defaults at once, and gives you something grep for if you don't like them. I realise this isn't what you want, but objecting to patches because they're completely unrelated to what you want is kind of silly.
CONFIG_TINY sets no default values right now. Go look at
http://www.jaquet.dk/kernel/config_tiny/2.5.44-allinone and tell me where CONFIG_TINY sets defaults.
Anyhow, I hope to have enough time to finish up a rough cut of my template work this week and post something for comments. I've just got to figure out how to get TWEAK_XXX to work in the Makefiles like CONFIG_XXX does now.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 5 lines · Rob Landley
Reason 4 is inertia. You are explicitly considering inertia a good reason, then? I remember back around 1998, the argument over "-fno-strength-reduce" which accomplished nothing whatsoever (and was in fact disabled in gcc 2.7.x for i386) but was in the kernel compile for a long time becaue nobody could be bothered to remove it...
However, there were versions of gcc which generated bad x86 code if you didn't use it. It stayed until that version would no longer compile the kernel.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
Hi Adrian,
Quoted 4 lines
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:
I tried -Os once, and it didn't boot for me. So I dumped it. However, reading a mail from Zwane <somethingorother> about booting 2.5.x on a 4MB system I got the impression that he used Os, so I might give it another shot. Dropping down to i386 support, perhaps.
Thanks for reading,
Rasmus
Quoted 9 lines · Rasmus Andersen
On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
Hi Adrian,
Quoted 4 lines
could you try to use "-Os" instead of "-O2" as gcc optimization option when
CONFIG_TINYis enabled? Something like the following (completely untested) patch:I tried -Os once, and it didn't boot for me. So I dumped it.
I build all my kernels with -Os and it works just fine for me.
Makefile +1 -1
@@ -88,7 +88,7 @@ CPPFLAGS := -D__KERNEL__ -I$(HPATH) -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \ +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -Os \ -fno-strict-aliasing -fno-common ifndef CONFIG_FRAME_POINTER CFLAGS += -fomit-frame-pointer
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Quoted 1 line · Erik Andersen
I build all my kernels with -Os and it works just fine for me.
Right then, I guess I'll give it an another shot. Do you have any numbers in terms of saved space etc. to share? Other impressions?
Regards,
Rasmus
Quoted 6 lines · Rasmus Andersen
Quoted 1 line · Erik Andersen
I build all my kernels with -Os and it works just fine for me.
Right then, I guess I'll give it an another shot. Do you have any numbers in terms of saved space etc. to share? Other impressions?
Here are some numbers for you. Using 2.4.20-pre-10-erik (the hacked up kernel I happen to be using on my desktop) using gcc 2.95.4 (from Debian testing) and my stock kernel configuration:
bzImage compiled -O2: 1268158 bzImage compiled -Os: 1251431
vmlinux compiled -O2: 3457737 vmlinux compiled -Os: 3437257
/lib/modules/kernel size -O2: 2472629/lib/modules/kernel size -Os: 2463661
text data bss dec hex filename
2354620 316768 258136 2929524 2cb374 vmlinux.O2 2336016 316768 258136 2910920 2c6ac8 vmlinux.Os
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Am Don, 2002-10-31 um 09.24 schrieb Rasmus Andersen:
Quoted 5 lines
I tried -Os once, and it didn't boot for me. So I dumped it. However, reading a mail from Zwane <somethingorother> about booting 2.5.x on a 4MB system I got the impression that he used Os, so I might give it another shot. Dropping down to i386 support, perhaps.
If you meant removing special support for faster processors this might be a gain, if it was something along the lines of "-mcpu=i386 -mtune=i386" this would be pretty sure a loss resulting in bigger code.
Signature · 2 lines
Servus,
DanielQuoted 11 lines · Daniel Egger
Am Don, 2002-10-31 um 09.24 schrieb Rasmus Andersen:
Quoted 5 lines
I tried -Os once, and it didn't boot for me. So I dumped it. However, reading a mail from Zwane <somethingorother> about booting 2.5.x on a 4MB system I got the impression that he used Os, so I might give it another shot. Dropping down to i386 support, perhaps.
If you meant removing special support for faster processors this might be a gain, if it was something along the lines of "-mcpu=i386 -mtune=i386" this would be pretty sure a loss resulting in bigger code.
I was just wondering aloud if my boot problem would go away if I did -Os and -mcpu=386. Just a wonder, though.
Regards,
Rasmus
Quoted 3 lines · Rasmus Andersen
o noswap: Disabling swap by stubbing out all of
swapfile.c,swap_stat.c,page_io.c,highmem.cand some ofmemory.c. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-noswap
You can't stub out all of highmem.c, it's also used for bounce io (highmem as well as isa for > 16mb adresses)
Signature · 1 line
Jens Axboe
Quoted 7 lines · Jens Axboe
Quoted 3 lines · Rasmus Andersen
o noswap: Disabling swap by stubbing out all of
swapfile.c,swap_stat.c,page_io.c,highmem.cand some ofmemory.c. Patch at: www.jaquet.dk/kernel/config_tiny/2.5.44-noswapYou can't stub out all of
highmem.c, it's also used for bounce io (highmem as well as isa for > 16mb adresses)
OK, I missed the ISA > 16MB stuff. I have a look at it again. I don't think that people is going to have CONFIG_HIGHMEM and CONFIG_TINY on at the same time anyways (could be expressed explicitly, though).
Thanks for your comments,
Rasmus