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: http://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: http://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: http://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: http://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: http://www.jaquet.dk/kernel/config_tiny/2.5.44-nohashes
o allinone: All of the above rolled up into one.
Patch at: http://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: http://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
On Wed, 30 Oct 2002, Rasmus Andersen wrote:
> This details some new patches I have done as part of my
> CONFIG_TINY exploration.
Nice! It also looks simple enough to be mergeable at any
time ;)
Rik
--
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>
On Wed, 30 Oct 2002, Rasmus Andersen wrote:
> Hi,
Hi Rasmus,
>...
> 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.old 2002-10-31 01:35:36.000000000 +0100
+++ Makefile 2002-10-31 01:49:10.000000000 +0100
@@ -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/
> Regards,
> Rasmus
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
On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> On Wed, 30 Oct 2002, Rasmus Andersen wrote:
>
> > Hi,
>
> Hi Rasmus,
>
> >...
> > 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:
-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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Wed, Oct 30, 2002 at 06:10:02PM -0700, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > 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:
> -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
--
[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/
On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
Hi Adrian,
>
> 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:
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
On Thu, Oct 31, 2002 at 09:32:05AM +0100, Jens Axboe wrote:
> On Wed, Oct 30 2002, Rasmus Andersen wrote:
> > 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: http://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)
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
On Wed, Oct 30 2002, Rasmus Andersen wrote:
> 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: http://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)
--
Jens Axboe
On Thu, Oct 31, 2002 at 03:05:12AM -0700, Erik Andersen wrote:
> 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
On Thu Oct 31, 2002 at 09:24:40AM +0100, Rasmus Andersen wrote:
> On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
>
> Hi Adrian,
> >
> > 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:
>
> 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.
--- orig/Makefile Tue Aug 20 06:44:25 2002
+++ linux-2.4.19/Makefile Tue Aug 20 06:44:25 2002
@@ -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--
On Thu Oct 31, 2002 at 11:08:34AM +0100, Rasmus Andersen wrote:
> On Thu, Oct 31, 2002 at 03:05:12AM -0700, Erik Andersen wrote:
> > 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--
On Thu, Oct 31, 2002 at 12:33:10AM -0500, Mark Mielke wrote:
> On Wed, Oct 30, 2002 at 06:10:02PM -0700, Tom Rini wrote:
> > On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > > 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:
> > -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...
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Matt Porter <[email protected]> wrote:
>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
In an ideal world there would be several options invidually
selectable.
Bernd
--
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
On Thu, Oct 31, 2002 at 07:33:01AM -0700, Tom Rini wrote:
> > 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.
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
--
[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/
On Thu, Oct 31, 2002 at 07:33:01AM -0700, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 12:33:10AM -0500, Mark Mielke wrote:
> > On Wed, Oct 30, 2002 at 06:10:02PM -0700, Tom Rini wrote:
> > > On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > > > 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:
> > > -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...
>
> 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.
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,
--
Matt Porter
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 11:51:13AM -0500, Mark Mielke wrote:
> > 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.
> 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
> ...
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
--
[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/
On Thu, Oct 31, 2002 at 11:51:13AM -0500, Mark Mielke wrote:
> On Thu, Oct 31, 2002 at 07:33:01AM -0700, Tom Rini wrote:
> > > 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.
>
> 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.
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 12:12:40PM -0500, Mark Mielke wrote:
> On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > On Thu, Oct 31, 2002 at 11:51:13AM -0500, Mark Mielke wrote:
> > > 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.
> > 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
> > ...
>
> 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.
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.
> 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.
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 10:24:05AM -0700, Tom Rini wrote:
> 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.
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
On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> 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.
> 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.
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.
On Thu, Oct 31, 2002 at 06:49:00PM +0100, Sam Ravnborg wrote:
> On Thu, Oct 31, 2002 at 10:24:05AM -0700, Tom Rini wrote:
> > 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.
> 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).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
> Matt Porter <[email protected]> wrote:
> >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
>
> 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.
Regards,
Rasmus
On Thu, Oct 31, 2002 at 01:26:07PM -0500, Kent Borg wrote:
> On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > 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.
> 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.
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..
> > 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.
>
> 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..
> 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.
Let's not pretend that changing > 1 tunable param with 1 CONFIG question
makes it any better than it is now.
> 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?)
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.
> 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.
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 12:15:35PM -0700, Tom Rini wrote:
> 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.
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
On Thu, Oct 31, 2002 at 07:43:48PM +0100, Rasmus Andersen wrote:
> On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
> > Matt Porter <[email protected]> wrote:
> > >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
> >
> > 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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Am Don, 2002-10-31 um 09.24 schrieb Rasmus Andersen:
> 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.
--
Servus,
Daniel
On Thu, Oct 31, 2002 at 08:33:21PM +0100, Daniel Egger wrote:
> Am Don, 2002-10-31 um 09.24 schrieb Rasmus Andersen:
>
> > 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
Mark Mielke wrote:
> On Thu, Oct 31, 2002 at 07:33:01AM -0700, Tom Rini wrote:
>
>>>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.
>
>
> 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
Rasmus Andersen <[email protected]> wrote:
>On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
[...]
>> 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
--
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
On Thu, 31 Oct 2002, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 12:12:40PM -0500, Mark Mielke wrote:
>
> > On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > > On Thu, Oct 31, 2002 at 11:51:13AM -0500, Mark Mielke wrote:
> > > > 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.
> > > 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
> > > ...
> >
> > 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.
>
> 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.
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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 30 Oct 2002, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > On Wed, 30 Oct 2002, Rasmus Andersen wrote:
> > >...
> > > 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:
>
> -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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Em Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini escreveu:
> 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.
CONFIG_TINY would be just a way to enable all the CONFIG_FINE_TUNE_WHATEVER
options that reduce image size.
- Arnaldo
On Fri, Nov 01, 2002 at 12:30:14AM +0100, Bernd Petrovitsch wrote:
> Rasmus Andersen <[email protected]> wrote:
> >On Thu, Oct 31, 2002 at 05:52:59PM +0100, Bernd Petrovitsch wrote:
> [...]
> >> 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.
>
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
On Thu, Oct 31, 2002 at 09:09:20PM -0500, Bill Davidsen wrote:
> On Thu, 31 Oct 2002, Tom Rini wrote:
>
> > On Thu, Oct 31, 2002 at 12:12:40PM -0500, Mark Mielke wrote:
> >
> > > On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > > > On Thu, Oct 31, 2002 at 11:51:13AM -0500, Mark Mielke wrote:
> > > > > 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.
> > > > 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
> > > > ...
> > >
> > > 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.
> >
> > 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.
>
> 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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 08:27:52PM +0100, Rasmus Andersen wrote:
> On Thu, Oct 31, 2002 at 12:15:35PM -0700, Tom Rini wrote:
> > 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.
>
> 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).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Oct 31, 2002 at 09:03:55PM -0500, Bill Davidsen wrote:
> On Wed, 30 Oct 2002, Tom Rini wrote:
>
> > On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > > On Wed, 30 Oct 2002, Rasmus Andersen wrote:
>
> > > >...
> > > > 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:
> >
> > -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.
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' ?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Rasmus Andersen <[email protected]> wrote:
>On Fri, Nov 01, 2002 at 12:30:14AM +0100, Bernd Petrovitsch wrote:
[...]
>> 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
--
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).
On Fri, Nov 01, 2002 at 11:05:13PM +0100, Bernd Petrovitsch wrote:
> 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.
> Sorry for the confusion.
On the contrary: I am sorry.
Regards,
Rasmus
On Friday 01 November 2002 14:15, Tom Rini wrote:
> > 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
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Thursday 31 October 2002 18:53, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 01:26:07PM -0500, Kent Borg wrote:
> > On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > > 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.
> > 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.
>
> 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.
> 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?
> 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.
> > > 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.
> >
> > 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.
> > 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.
>
> 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.
> 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.
> 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.
> 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".
> 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
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Mon, Nov 04, 2002 at 02:13:33AM +0000, Rob Landley wrote:
> On Thursday 31 October 2002 18:53, Tom Rini wrote:
> > On Thu, Oct 31, 2002 at 01:26:07PM -0500, Kent Borg wrote:
> > > On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > > > 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.
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.
> 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.
> > > 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.
> >
> > 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.
> > 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.
> > 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.
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.
> 2) Provide a patch. The CONFIG_TINY people 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.
> > > > 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.
> > >
> > > 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.
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.
> > Building a 'tiny' kernel should have nothing to do with any of this.
>
> Oh good, we agree on something.
:P
> > 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.
> > 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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
> On Friday 01 November 2002 14:15, Tom Rini wrote:
>
> > > 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.
Then we don't we always use -Os?
--
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.
On Monday 04 November 2002 19:51, Tom Rini wrote:
> On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
> > 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
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Monday 04 November 2002 20:34, Cort Dougan wrote:
> 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
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
---------------------------------------------------------
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.
---------------------------------------------------------
On Mon, 4 Nov 2002, Tom Rini wrote:
> On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
> > 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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 2002-11-05 at 19:26, Bill Davidsen wrote:
> > 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}
On Tue, Nov 05, 2002 at 02:26:08PM -0500, Bill Davidsen wrote:
> On Mon, 4 Nov 2002, Tom Rini wrote:
>
> > On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
>
> > > 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?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Tuesday 05 November 2002 19:56, Tom Rini wrote:
> On Tue, Nov 05, 2002 at 02:26:08PM -0500, Bill Davidsen wrote:
> > On Mon, 4 Nov 2002, Tom Rini wrote:
> > > On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
> > > > 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...
> 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
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
On Tue, Nov 05, 2002 at 05:55:56PM +0000, Rob Landley wrote:
> On Tuesday 05 November 2002 19:56, Tom Rini wrote:
> > On Tue, Nov 05, 2002 at 02:26:08PM -0500, Bill Davidsen wrote:
> > > On Mon, 4 Nov 2002, Tom Rini wrote:
> > > > On Mon, Nov 04, 2002 at 02:13:48AM +0000, Rob Landley wrote:
> > > > > 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...
>
> 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.
> Reason 3, 5, and 6 were about performance gains, when the point of CONFIG_TINY
> is, 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.
> > So why do we want to force it on for CONFIG_TINY?
>
> 1) The point of CONFIG_TINY is 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.
> 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.
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Tue, 5 Nov 2002, Rob Landley wrote:
> 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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.