From: James <wireless@tampabay.rr.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Kernel ricing
Date: Thu, 24 Oct 2013 16:22:32 +0000 (UTC) [thread overview]
Message-ID: <loom.20131024T182205-97@post.gmane.org> (raw)
In-Reply-To: CAC=wYCGsYfAm8x2XgxM2t6WCdRDYhMieeSRNYkQDE6TXd1svAA@mail.gmail.com
Adam Carter <adamcarter3 <at> gmail.com> writes:
>
Some background:
Wow!.
Ok. Let me point out the obvious, that there are 2 basic ways
to build a kernel: Natively on the local resources (CPU, ram etc) of the
target system, and Cross Compiling. CrossCompiling is often much faster
and even preferred, ymmv.
Also it helps to know what your final (target) system will be? A security
scanner, a firewall, a terminal server, web server? minimize portable
workstation?
This is important because, if you only want a firewall, there are several
minimized standard C libraies that can be used in lieu of the standard LibC.
ulibc, bionic, etc etc. A minimized sysetem involves much more, (usually)
than a skinny, fast kernel. diffeent libraries need differnet kernel
support (hooks). Staying with the x86 arch. first time down this path, is
wise.
If you want to build a minimized system, you need to first do a bit
of reading. The best place to start is here:
http://www.gentoo.org/proj/en/base/embedded/handbook/
The folks that inhabit embedded-gentoo, are leagues beyond my
level of competency, just so you know. The gentoo embedded handbook
will have lots of examples on building embedded (minimized) system.
It's an interesting read too.
> The CFLAGs used when building the kernel are set in the Makefile;# grep
HOSTCFLAGS /usr/src/linux/MakefileHOSTCFLAGS = -Wall -Wmissing-prototypes
-Wstrict-prototypes -O2 -fomit-frame-pointer
I'd first avoid any changes to the /usr/src/linux/Makefile file, for now.
Let's assume you are building kernels natively. First, minimize the system
flags set in make.conf, and go thru the kernel options menu, or by hand, and
removed as much stuff, particularly drivers, to a working bare minimum.
Keep in mind what applications you will want to run eventuallly, as there
is no point removing that relevant low-level codes, only to add them back in
later. This process should lead to a radically reduced kernel size. I would
leave the -O2 parameter set in the make.conf file. until you trim
out all of the excess driver/firmware from the kernel, (/usr/src/linux/.config).
Keep a copy of this kernel handy for booting/recovery. Because, as you go
down the skinny path, you are going to get kernels that do not work, or
do funky, undesirable things, imho. In fact in /boot, I keep many
(experimental kernels), and copies of the system.map and the .config
files too, matching them up by long names or date_stamps; particularly
for refelection and deep analysis.
> To build with other flags you set CFLAGS_KERNEL, so i've added a suitable
-march to the standard ones for my system;export CFLAGS_KERNEL=" -Wall
-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
-march=amdfam10"
I'd hold off on trimming this file, for now. Set kernel params in
make.conf, which sould override setting like the -O2 option to -Os.
The next thing I would do is build a second kernel kernel, changing only
one parameter in the make.conf file. Change "O2" to "Os". Get both kernels
stable. Then find some benchmarks relevant to what you want to do and run
those on both kernels. I/O measurements is you intend to run lots
of threads simultaneously. (Hint: you may want to read up on
TLS, or Thread Local Storage as it pertains to kernel <-> libraries
and the anticipated needs of memory, related to what your final target
system applications will need to do.
> then make, install, reboot. In my case the riced kernel is the same size >
as the regular one, but the md5 is different. Its been up for an hour with
no obvious issues, and does seem snappier, but of course my brain is full of
cognitive bias. Has anyone else played with this? Any good or bad outcomes?
Same size? You did not change -02 to -Os. Did you go thru menuconfig
and trim out all of the extra drivers and things not needed (or manually
in the /usr/src/linux/.config file) ?
Comparing these -O2 to -Os speed/benchmark rewsults will first tell
you which path to go down for all of your future minimiztion efforts.
I also want to reiterate here: Vapier, Solar, Armin76 and many others
on gentoo-embedded group, know far more than I do, being a grasshopper in
these matters...... The focus there is ARM arch, but the knowledge
transcends architecture types.
However those guys are really, really busy, and before they will
interact with you, they will expect that you have done tons of reading
and experimenting on your own. You can look at the archive to gentoo
embedded, for relevant postings. x86 use to have lots of efforts, today
you have to research the atom or newere AMD arch sites to find some
particular details and ideas. And as you switch architectures, thing
get complex, but, that is where the real fun is. Most folks that spent
years learning to minimize x86 have moved on to Mips, ARM or such
as the work/benefit is far greater.
I'm also a bit scattered (my friends refer to me as an interrupt processor
with no return vector)..... just so you know....
So compare -O2 to -Os with all else being the same and post back.
hth,
James
prev parent reply other threads:[~2013-10-24 16:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 8:58 [gentoo-user] Kernel ricing Adam Carter
2013-10-24 9:06 ` Alan McKinnon
2013-10-24 10:58 ` Adam Carter
2013-10-24 11:39 ` Alan McKinnon
2013-10-24 15:26 ` [gentoo-user] " James
2013-10-24 15:33 ` Alan McKinnon
2013-10-24 16:21 ` James
2013-10-24 17:03 ` Bruce Hill
2013-10-24 17:31 ` James
2013-10-24 17:50 ` Bruce Hill
2013-10-25 15:07 ` James
2013-10-24 17:36 ` Tanstaafl
2013-10-24 17:51 ` Bruce Hill
2013-10-24 17:55 ` Tanstaafl
2013-10-24 17:54 ` James
2013-10-25 6:39 ` Alan McKinnon
2013-10-30 7:22 ` Grant
2013-10-25 0:15 ` [gentoo-user] " Walter Dnes
2013-10-24 11:48 ` the
2013-10-24 16:22 ` James [this message]
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=loom.20131024T182205-97@post.gmane.org \
--to=wireless@tampabay.rr.com \
--cc=gentoo-user@lists.gentoo.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