Others have expressed similar concerns. Andi Kleen has brought this
up in the past, and highlighted another aspect of this that I think
is important - fragmenting the configuration space for testing.
That is, if different combinations of options are used, then the
testing results from different users may not be directly comparable.
This makes it harder to track down bugs.
In practice, I think these types of switches tend to get turned
on/off together. This tends to ameliorate the testing and maintenance
issues. It might be worthwhile to coalesce these into fewer
options. I'd be fine with overloading this particular
onto CONFIG_BASE_FULL, but I don't know what other people think.
Keeping the option separate means you have more flexibility - so
that you can, for example, turn off all but one feature that's
important to you. (This seems like a pretty common
These are certainly nice, but there's a limited number of whole-kernel
reduction options. Kernel size accumulates by both wasteful
compiler output, and by the introduction or preservation of individual
features that are useless for embedded devices. I think it's worthwhile
to attack both problems.
Well, an initial comparison is at:
http://www.selenic.com/bloatwatch/?cmd=compare&part=%2F&v1=2.6.16&v2=2.6.25-rc2
This shows a size difference of 1.8 meg, but I'm pretty sure this
is with a default config (not optimized) and is not controlled very well
for changes in the config.
I can do a more controlled comparison if you're interested.
I'm not sure that's a good comparison, since Linux-tiny hasn't been
very active in that time period. I would guess only about 3 or 4
Linux-tiny patches have made it into the kernel since 2.6.16.
The big wins for Linux-tiny were in the 2.6.10/11 kernels, where
most of the low-hanging fruit (size-wise) was gleaned.
But to address your point, you're right that no existing Linux-tiny
patch gets 2.5% reduction for the kernel.
In my own testing at Sony, the 30 or so Linux-tiny patches that
I use get me about 110k of reductions. For me, this is about 5% of
my kernel size. Note that my choice of options to achieve
reductions is pretty conservative.
There are diminishing returns here, and at some point it doesn't make
sense to continue. I have a nagging feeling, though, that there
are a few more things where the bloat is pronounced (glances at
procfs and sysfs).
It *does* feel a bit like fighting the tide with a teaspoon.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
--
