1 |
I've been using Gentoo for several months now, and I've learned, |
2 |
sometimes "the hard way", what to do and not to do. Here's the first |
3 |
draft of a mini-FAQ/HOWTO. It can stand alone. If there's another FAQ |
4 |
out there already, maybe the ideas here can be included in it... |
5 |
|
6 |
======================================================================== |
7 |
The secret of a fast and stable Gentoo is knowing what *NOT* to do, as |
8 |
much as knowing what to do. To use an automotive analogy, any idiot can |
9 |
floor the gas pedal, and keep it pressed down. But if you don't let off |
10 |
the gas pedal as the tachometer approaches the red line, your engine |
11 |
will blow up on you. In addition to hints about what to do, this |
12 |
document will point out some red lines that should not be crossed. |
13 |
Please remember, when I say do *NOT* do something, I have a reason. |
14 |
|
15 |
Commonsense disclaimer... cpu tweaks are *NOT* going to speed up a |
16 |
program that pounds away on the hard drive. But for cpu-intensive apps, |
17 |
the speedup can be significant. Properly optimizing Gentoo is a |
18 |
fill-in-the-blanks excercise. First, I'll deal with generic |
19 |
optimizations that are applicable to all architectures. |
20 |
|
21 |
1) In /etc/make.conf set the following entry... |
22 |
MAKEOPTS="-j1" |
23 |
Do *NOT*, I repeat, do *NOT* use higher numbers. You are begging |
24 |
for problems if you do so. This is one place where I diverge from |
25 |
official recommendation, ie. |
26 |
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part1_chap5__chap5_sect3 |
27 |
which says |
28 |
> With MAKEOPTS you define how many parallel compilations should occur |
29 |
> when you install a package. A good choice is the number of CPUs in |
30 |
> your system plus one, but this guideline isn't always perfect. |
31 |
|
32 |
Actually, that statement of fact is correct. The guideline is *NOT* |
33 |
always perfect. CPUs+1 *USUALLY* works, but "usually" isn't good |
34 |
enough. I have had compiles blow up on me on an old PII where I had set |
35 |
MAKEOPTS="-j2". Setting MAKEOPTS="-j1" solved the problem. I've seen |
36 |
reports of the same problem and solution on an AMD64. The root cause of |
37 |
the problem is that the combo of autoconf/make/gcc is not parallel-safe |
38 |
today. Future versions might be, but it will require major re-writes. |
39 |
Parallel programming is a world of its own. Parallel processes, by |
40 |
definition, are not guaranteed to finish in a specific order. In a |
41 |
situation where module "b" depends on module "a", you get stuff like the |
42 |
process which is supposed to delete module "a" executes before the |
43 |
compilation of module "b" begins... oops. |
44 |
|
45 |
Future versions may be declared parallel-safe, but for now, stick with |
46 |
j1. It slows down *THE COMPILATION PROCESS*. However, it does *NOT* |
47 |
slow down *THE COMPILED PROGRAM*. |
48 |
|
49 |
2) The generic portion of CFLAGS consists of those flags that do not |
50 |
begin with "-m". For that part, use "-O2 -pipe -fomit-frame-pointer" |
51 |
|
52 |
Please, do *NOT* use "-O3" (or higher!!!) or try to unroll every last |
53 |
loop or use every last exotic generic optimization. Your programs will |
54 |
*USUALLY* work, but they'll probably be flakier. They may be faster, or |
55 |
they may be slower. However, people will point their fingers at you and |
56 |
laugh. Developers will ignore you when a program blows up and you file |
57 |
a bug report. The only exception is if a developer specifically OK's |
58 |
special optimizations for specific modules or programs, and is willing |
59 |
to support those modules or programs with extra optimization. Things |
60 |
may change in future versions of gcc, but the 3.4.x series works best |
61 |
with the settings I've given. |
62 |
|
63 |
|
64 |
|
65 |
And now for the machine-specific flags in CFLAGS. I'll use my machine |
66 |
because it happens to be handy. *YOUR MACHINE WILL HAVE DIFFERENT FLAGS |
67 |
UNLESS YOU HAVE THE EXACT SAME MODEL AS ME*. Try to follow the logic I |
68 |
use, and apply it to your situation. |
69 |
|
70 |
Boot your machine with any linux distro, and execute... |
71 |
|
72 |
cat /proc/cpuinfo |
73 |
|
74 |
The two output lines we're interested in are "model name" and "flags". |
75 |
On my machine, they're... |
76 |
|
77 |
model name : Intel(R) Pentium(R) 4 CPU 1.80GHz |
78 |
|
79 |
That tells me what my CPU is. |
80 |
|
81 |
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm |
82 |
|
83 |
This one involves a bit of looking up. First execute "gcc --version" |
84 |
to find out which version of gcc you're running. Check the docs for your |
85 |
version at http://gcc.gnu.org/onlinedocs and look under "Hardware Models |
86 |
and Configurations" *FOR YOUR CPU*. Look for anything in there that |
87 |
matches anything in your flags line. For my machine that's |
88 |
"-march=pentium4 -mfpmath=sse -mmmx -msse -msse2". This gives me a the |
89 |
following combined CFLAGS line... |
90 |
|
91 |
CFLAGS="-O2 -fomit-frame-pointer -pipe -march=pentium4 -mfpmath=sse -mmmx -msse -msse2" |
92 |
|
93 |
Some of the flags are also valid in the USE variable as well. Check |
94 |
your flags line against the list in /usr/portage/profiles/use.desc (or |
95 |
online at http://www.gentoo.org/dyn/use-index.xml ). In my case, mmx |
96 |
and sse and sse2 are usable. My USE variable looks like so (I'll explain |
97 |
the "-*" later)... |
98 |
|
99 |
USE="-* a52 aac alsa apm audiofile dio encode exif ffmpeg flac foomatic fortran gb gif gstreamer gtk2 ieee1394 jpeg maildir mikmod mmap mmx mng ncurses offensive ogg opengl plotutil png posix quicktime sdl slang sse theora threads tiff truetype vorbis win32codecs wmf xv" |
100 |
|
101 |
Some programs have additional flags that don't show up in the main |
102 |
list. They're listed in /usr/portage/profiles/use.local.desc, e.g. |
103 |
mplayer has various additional flags. If you're running mplayer on an |
104 |
AMD64, the following entry in /etc/portage/package.use will help... |
105 |
|
106 |
media-video/mplayer custom-cflags i8x0 real sse2 3dnowext mmxext |
107 |
|
108 |
You can add these flags to your main USE variable, but it'll end up |
109 |
getting quite long. |
110 |
|
111 |
Additional Hints |
112 |
================ |
113 |
|
114 |
Things to make life easier when switching to Gentoo |
115 |
|
116 |
1) The flags line for my cpu mentions that I have "apic mtrr acpi". |
117 |
While these aren't for CFLAG or USE, knowing of them will be useful when |
118 |
you build your kernel, and need to know if you have these facilities. |
119 |
|
120 |
2) In my USE variable, I start with "-*" which turns off all flags, |
121 |
and then I enter the ones I want/need. Gentoo combines your USE |
122 |
variable with information from a few other locations to determine the |
123 |
final set of flags to use for builds. There are some flags specified in |
124 |
"make.defaults" which take effect *UNLESS YOU SPECIFICALLY TURN THEM |
125 |
OFF*. That's what I use "-*" for. For example, when the developers, in |
126 |
their infinite wisdom, decided to include "ipv6" as a default, the 95% |
127 |
of people who weren't using IPV6 found apps building with IPV6 support. |
128 |
That's bad simply from the point of view of bloat. What was really |
129 |
annoying was that apps would first try a URL or hostname via IPV6, sit |
130 |
for a minute until the IPV6 lookup timed out, and then finally get |
131 |
around to trying IPV4. *NOT FUN*. "-*" in USE should protect you |
132 |
against such surprises in future. The whole point of Gentoo is that |
133 |
*YOU* are in control. |
134 |
|
135 |
3) Avoid framebuffer unless you need it (non X86 architectures, etc) |
136 |
|
137 |
4) If you insist on framebuffer *PLEASE* avoid bootsplash, at least |
138 |
until you have a functional system. Yes, it's "cute" to see a penguin |
139 |
graphic at bootup, or a smiling paperclip if you're weird. But |
140 |
bootsplash problems seem to pop up a lot on the Gentoo mailing list. |
141 |
Worry about it after you have your system up and running. |
142 |
|
143 |
5) Have you used pam previously and know how to handle it? Good, use |
144 |
it in Gentoo. If you aren't familiar with pam, don't use it now. Gentoo |
145 |
has its own steep learning curve. So does pam. Trying to learn *BOTH* |
146 |
of them at once turns a steep learning curve into trying to climb up the |
147 |
side of a cliff. Once you've got Gentoo up and running, if you wish you |
148 |
can start reading up on pam, and use it next time you install Gentoo. |
149 |
|
150 |
6) You have an internal PCI modem that you know should work under |
151 |
Gentoo but your system can't even see it? Here's the scoop. Internal |
152 |
PCI modems do *NOT* work on the first 4 com ports, ttyS0-through-ttyS3 |
153 |
(COM1: through COM4: in DOS). They work on ttyS4 (COM5: in DOS) and |
154 |
higher. If you've built your kernel to only support 4 serial ports, PCI |
155 |
modems will not work. To enable ttyS4 and higher, you'll have to |
156 |
rebuild your kernel with support for 5 (or more) serial ports. Here's |
157 |
the hierarchy in "make menuconfig" |
158 |
|
159 |
Device Drivers ---> |
160 |
Character devices ---> |
161 |
Serial drivers ---> |
162 |
<*> 8250/16550 and compatible serial support |
163 |
(5) Maximum number of non-legacy 8250/16550 serial ports |
164 |
|
165 |
The (5) allows for 1 PCI modem. If you have 2 PCI modems, you need |
166 |
to set the number of ports to at least (6), etc. |
167 |
======================================================================== |
168 |
|
169 |
|
170 |
-- |
171 |
Walter Dnes <waltdnes@××××××××.org> |
172 |
My musings on technology and security at http://tech_sec.blog.ca |
173 |
-- |
174 |
gentoo-user@g.o mailing list |