Why build kernel for minimum size?
Nifty Hat Mitch
mitch48 at sbcglobal.net
Mon Aug 23 08:08:46 UTC 2004
On Fri, Aug 20, 2004 at 01:07:11AM +0100, James Wilkinson wrote:
> Steve Snyder wrote:
> > I notice that the FC2 kernels are built for size, not speed. (The config
> > option for compiling for size is selected.)
> >
> > What is the thinking behind this? Is the configuration biased toward
> > low-memory systems? Are there CPU cache considerations that effective
> > make a small build (-Os) faster than a more optimized (-O2) build?
>
> The latter: plus the kernel is a rather specialised application, that is
> tuned with (at least) one eye on what gcc produces, which mean that
> there isn't the opportunity for -O2 to do much good (but it will bulk
> out the code).
If I think about this
$ time something
real 0m2.023s
user 0m1.328s
sys 0m0.005s
In this case I am using the kernel for 0.005s and the application
is busy for 1.328s In general one does not optimize something that
takes 0.2% of the run time when the 99.7% of the problem is more
productive turf for optimization efforts.
Since the kernel is for the most part static in memory I am happy that
the 0.2% of my application is minimized in memory letting me to use
that memory to advantage for my applications.
In this case I was computing 5000! And if I give some attention to my
method the run time changes drastically. Clearly I should focus on
the 99.7% not the 0.2%. The result now times out as follows:
real 0m0.466s
user 0m0.052s
sys 0m0.005s
It is true that the kernel is full of functions. Any single function
or small set of functions could be optimized if it was found that
optimization helps. In fact individual code fragments are optimized and
in some cases hand coded in assembler. The .asm for the various copy
(bzero(), bcopy(), memcpy() and such are. For examples see:
/usr/src/linux-2.6.8-1.521/include/asm-i386/string.h
For an application a general rule it that it is valuable to keep as
much work in user space and minimize what the kernel does.
--
T o m M i t c h e l l
Just say no to 74LS73 in 2004
More information about the fedora-list
mailing list