From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Less generic kernels
Date: Thu, 4 Dec 2003 04:18:19 +0100 [thread overview]
Message-ID: <20031204031818.GA7212@linux-mips.org> (raw)
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
reply other threads:[~2003-12-04 3:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031204031818.GA7212@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox