1 |
Adam Carter <adamcarter3 <at> gmail.com> writes: |
2 |
|
3 |
> |
4 |
Some background: |
5 |
Wow!. |
6 |
|
7 |
Ok. Let me point out the obvious, that there are 2 basic ways |
8 |
to build a kernel: Natively on the local resources (CPU, ram etc) of the |
9 |
target system, and Cross Compiling. CrossCompiling is often much faster |
10 |
and even preferred, ymmv. |
11 |
|
12 |
Also it helps to know what your final (target) system will be? A security |
13 |
scanner, a firewall, a terminal server, web server? minimize portable |
14 |
workstation? |
15 |
|
16 |
This is important because, if you only want a firewall, there are several |
17 |
minimized standard C libraies that can be used in lieu of the standard LibC. |
18 |
ulibc, bionic, etc etc. A minimized sysetem involves much more, (usually) |
19 |
than a skinny, fast kernel. diffeent libraries need differnet kernel |
20 |
support (hooks). Staying with the x86 arch. first time down this path, is |
21 |
wise. |
22 |
|
23 |
|
24 |
If you want to build a minimized system, you need to first do a bit |
25 |
of reading. The best place to start is here: |
26 |
|
27 |
http://www.gentoo.org/proj/en/base/embedded/handbook/ |
28 |
|
29 |
The folks that inhabit embedded-gentoo, are leagues beyond my |
30 |
level of competency, just so you know. The gentoo embedded handbook |
31 |
will have lots of examples on building embedded (minimized) system. |
32 |
It's an interesting read too. |
33 |
|
34 |
|
35 |
> The CFLAGs used when building the kernel are set in the Makefile;# grep |
36 |
HOSTCFLAGS /usr/src/linux/MakefileHOSTCFLAGS = -Wall -Wmissing-prototypes |
37 |
-Wstrict-prototypes -O2 -fomit-frame-pointer |
38 |
|
39 |
I'd first avoid any changes to the /usr/src/linux/Makefile file, for now. |
40 |
|
41 |
Let's assume you are building kernels natively. First, minimize the system |
42 |
flags set in make.conf, and go thru the kernel options menu, or by hand, and |
43 |
removed as much stuff, particularly drivers, to a working bare minimum. |
44 |
|
45 |
Keep in mind what applications you will want to run eventuallly, as there |
46 |
is no point removing that relevant low-level codes, only to add them back in |
47 |
later. This process should lead to a radically reduced kernel size. I would |
48 |
leave the -O2 parameter set in the make.conf file. until you trim |
49 |
out all of the excess driver/firmware from the kernel, (/usr/src/linux/.config). |
50 |
|
51 |
|
52 |
Keep a copy of this kernel handy for booting/recovery. Because, as you go |
53 |
down the skinny path, you are going to get kernels that do not work, or |
54 |
do funky, undesirable things, imho. In fact in /boot, I keep many |
55 |
(experimental kernels), and copies of the system.map and the .config |
56 |
files too, matching them up by long names or date_stamps; particularly |
57 |
for refelection and deep analysis. |
58 |
|
59 |
|
60 |
> To build with other flags you set CFLAGS_KERNEL, so i've added a suitable |
61 |
-march to the standard ones for my system;export CFLAGS_KERNEL=" -Wall |
62 |
-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe |
63 |
-march=amdfam10" |
64 |
|
65 |
I'd hold off on trimming this file, for now. Set kernel params in |
66 |
make.conf, which sould override setting like the -O2 option to -Os. |
67 |
|
68 |
|
69 |
The next thing I would do is build a second kernel kernel, changing only |
70 |
one parameter in the make.conf file. Change "O2" to "Os". Get both kernels |
71 |
stable. Then find some benchmarks relevant to what you want to do and run |
72 |
those on both kernels. I/O measurements is you intend to run lots |
73 |
of threads simultaneously. (Hint: you may want to read up on |
74 |
TLS, or Thread Local Storage as it pertains to kernel <-> libraries |
75 |
and the anticipated needs of memory, related to what your final target |
76 |
system applications will need to do. |
77 |
|
78 |
> then make, install, reboot. In my case the riced kernel is the same size > |
79 |
as the regular one, but the md5 is different. Its been up for an hour with |
80 |
no obvious issues, and does seem snappier, but of course my brain is full of |
81 |
cognitive bias. Has anyone else played with this? Any good or bad outcomes? |
82 |
|
83 |
Same size? You did not change -02 to -Os. Did you go thru menuconfig |
84 |
and trim out all of the extra drivers and things not needed (or manually |
85 |
in the /usr/src/linux/.config file) ? |
86 |
|
87 |
Comparing these -O2 to -Os speed/benchmark rewsults will first tell |
88 |
you which path to go down for all of your future minimiztion efforts. |
89 |
|
90 |
|
91 |
I also want to reiterate here: Vapier, Solar, Armin76 and many others |
92 |
on gentoo-embedded group, know far more than I do, being a grasshopper in |
93 |
these matters...... The focus there is ARM arch, but the knowledge |
94 |
transcends architecture types. |
95 |
|
96 |
However those guys are really, really busy, and before they will |
97 |
interact with you, they will expect that you have done tons of reading |
98 |
and experimenting on your own. You can look at the archive to gentoo |
99 |
embedded, for relevant postings. x86 use to have lots of efforts, today |
100 |
you have to research the atom or newere AMD arch sites to find some |
101 |
particular details and ideas. And as you switch architectures, thing |
102 |
get complex, but, that is where the real fun is. Most folks that spent |
103 |
years learning to minimize x86 have moved on to Mips, ARM or such |
104 |
as the work/benefit is far greater. |
105 |
|
106 |
I'm also a bit scattered (my friends refer to me as an interrupt processor |
107 |
with no return vector)..... just so you know.... |
108 |
|
109 |
|
110 |
So compare -O2 to -Os with all else being the same and post back. |
111 |
|
112 |
hth, |
113 |
James |