* Less generic kernels
@ 2003-12-04 3:18 Ralf Baechle
0 siblings, 0 replies; only message in thread
From: Ralf Baechle @ 2003-12-04 3:18 UTC (permalink / raw)
To: linux-mips
A side effect of cleaning the processor specific code a while ago was that
every system was carrying every bit of cpu-specific code such as cache
code with it that Linux only had to offer. I cleaned that, this are the
savings for two default configurations:
text data bss dec hex filename
2388266 275076 92456 2755798 2a0cd6 vmlinux defconfig old
2385522 275076 92456 2753054 2a021e vmlinux defconfig new
-> 2744 bytes saved
2197189 641168 128048 2966405 2d4385 vmlinux defconfig-ip27 old
2190310 641168 128048 2959526 2d28a6 vmlinux defconfig-ip27 new
-> 6879 bytes saved
Of course this also means faster, more efficient code.
How to make use of this for a particular system?
Just provide a include/asm-mips/mach-<system>/cpu-feature-overrides.h file.
Any values you don't define in that file will receive default values from
include/asm-mips/cpu-features.h.
That means if a particular macro isn't a constant for a particular system,
just don't define the cpu_* macro that tests for it. Better even, if you
don't know every little detail about your processor, just don't define the
test macro and Linux will
Who gains most?
Obviously the most restrictive configurations gain most. Generally that's
the case for typical embedded systems. Most of the size reduction can be
achieved by knowing the cache line size in advance. This means the kernel
will only carry one version for a particular processor around.
Oh, and this is a 2.6 only ...
Ralf
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2003-12-04 3:18 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-04 3:18 Less generic kernels Ralf Baechle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox