how best to compile a kernel?

how best to compile a kernel?

which optimization is recommended to compile a kernel?

always put these optimizations, it gave error in compilation

Code:
CFLAGS=-Os -march=native -pipe -ftree-vectorize -ftracer
CXXFLAGS=-Os -march=native -pipe -ftree-vectorize -ftracer

I took when I had no more error in compilation

I am following this step-by-step

http://codesnippets.joyent.com/posts/show/14

but the way this compilation Handbook's different, things are less
 
has somehow ignoring my optimizations in kernel compilation?

not want to be editing the make.conf whenever compiling the kernel.
 
Leave the default flags alone for compiling world and kernel. This is repeated over and over again on the mailing lists and the forums. You will either spectacularly nuke your entire system or encounter weird and unexplainable little errors when deviating from the default flags. This is not Gentoo, and no optimisation will give you any discernible advantage.
 
Here's the right way to use those CFLAGS in make.conf:

Code:
#CFLAGS=-Os -march=native -pipe -ftree-vectorize -ftracer
#CXXFLAGS=-Os -march=native -pipe -ftree-vectorize -ftracer

Just put a "#" in front of them. It will give you all of the benefits, plus you'll be able to build and run more reliably.
 
if I put # in freight, there will not be worth anything Flags

see my make.conf

Code:
CPUTYPE="native"
#CFLAGS=-O2 -march=native -pipe -ftree-vectorize -ftracer 
#CXXFLAGS=-O2 -march=native -pipe -ftree-vectorize -ftracer 
MAKEOPTS=-j3
OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10
MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs
# added by use.perl 2010-08-06 20:00:25
PERL_VERSION=5.10.1

what should I change? the flags are not reliable?
 
douglasfim said:
if I put # in freight, there will not be worth anything Flags

Exactly. CFLAGS are the cardboard spoilers of the computer world, unhelpful at best.

Suggested make.conf with inline snarky comments:

Code:
# use ?= in case this has already been set
CPUTYPE?=native

# remove spoilers
#CFLAGS=-O2 -march=native -pipe -ftree-vectorize -ftracer 
#CXXFLAGS=-O2 -march=native -pipe -ftree-vectorize -ftracer 

# default is probably fine, but whatever.
MAKEOPTS=-j3

# remove overrides from outdated HOWTO
#OVERRIDE_LINUX_BASE_PORT=f10
#OVERRIDE_LINUX_NONBASE_PORTS=f10

# this is an example from the Handbook, not to be taken literally
#MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs

# added by use.perl 2010-08-06 20:00:25
PERL_VERSION=5.10.1
 
OK

I'll clean my make.conf

Code:
CPUTYPE?=native
MAKEOPTS=-j3
PERL_VERSION=5.10.1

I put something else?
There is some optimization that works?
 
I just compile the kernel

in the build I saw he was using some optimizations.

each program uses a different optimization? so it is not advisable to use a standard optimization?

in "Handbook 24.7.7.2 Compile the Base System" says to use -j4 for a single-CPU

I have a 'Athlon II x2', a two-core processor, I used -j10

how does that work? it increases the amount of processes? how it works in a two-core processor?
 
douglasfim said:
each program uses a different optimization? so it is not advisable to use a standard optimization?

in "Handbook 24.7.7.2 Compile the Base System" says to use -j4 for a single-CPU

I have a 'Athlon II x2', a two-core processor, I used -j10

how does that work? it increases the amount of processes? how it works in a two-core processor?

It's fine in world install as you see in instructions. In fact the number after -j can be higher than processor + thread * cores. It should be smart enough to limit it's own resource and just use what it has negative one thread.

I don't recommend it for global make settings as I know out of experimentation I have seen it fail first hand.

here is my servers make.conf:

Code:
CPUTYPE?=core2
CFLAGS= -O2 -fno-strict-aliasing -pipe
CXXFLAGS+= -fconserve-space
COPTFLAGS= -O -pipe

mind you the core2 actually converts to nocona. (still waiting for the future system compiler =) )
 
when compiling the kernel, I saw something

Code:
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -
Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys -
I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-
growth=100 --param large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -
mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror  /usr/src/sys/cam/ata/ata_all.c

being that the optimizations used are not the same shown in the file /usr/share/examples/etc/make.conf

remembering that I commented lines in /etc/make.conf
 
douglasfim said:
being that the optimizations used are not the same shown in the file /usr/share/examples/etc/make.conf
The example make.conf is just that, an example.
 
-j flags will work ok on make build{world|kernel} commands, but don't even think about setting them on make install{world|kernel} commands. In other words: don't set them in /etc/make.conf.

Oh, and leave the flags alone. Is that clear by now?
 
FORGET ABOUT OPTIMISING YOUR make.conf BEYOND CPUTYPE. Period. Stop. Never think about it again. :)

All of the Makefiles in the FreeBSD /usr/src/ tree include the optimisations that are known to be safe, reliable, and usable for those source files. Don't try to second-guess the collective wisdom of the FreeBSD developers. They've had many decades of experience getting these things right. Leave things alone.

If you really want to play around with compiler flags and optimisations to try and get .001% better performance, then install Gentoo. :) FreeBSD is (generally) about reliability, dependability, and reproducibility. Not about measuring sticks, flashy lights, "red makes it go faster" paint jobs. :)
 
I recall someone advising -O14 for kernel compiles in some slackware forum lo 10 or more years ago. I nearly choked on my kibble. Any physicist knows that optimizing above -O8 reduces all atomic operations to values below Planck's constant, thus creating micro-abrasions on the inner surface of the universe which leads to outgassing into non-integer space and overheating of your CPU.

What do they teach kids in school these days?
 
douglasfim said:
Code:
MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs
what should I change?
Code:
options   COMPAT_LINUX
options   LINPROCFS
options   LINSYSFS
options   NTFS
device    sound
device    snd_ds1
 
DutchDaemon said:
-j flags will work ok on make build{world|kernel} commands, but don't even think about setting them on make install{world|kernel} commands. In other words: don't set them in /etc/make.conf.
I'm not sure what problem you anticipate, but I can assure you -j>1 install{world|kernel} works fine. I can't explain the presence of the same advice in the handbook, and I suspect no one else can give solid technical reasons either.

On the other hand, the benefits of setting higher max jobs on install{world|kernel} really aren't great as it's largely IO bound at that point.
 
I've seen it fail a couple of times, presumably because directories were not created yet before files were written to them, or hardlinks were created to files that hadn't been created yet, or something to that effect. It's been too long to remember, so this is mostly a guess. I'm guessing install proceses are (were) designed rather sequentially.
 
I'm not sure what you saw but that's never happened to me through years of using multiple jobs on the install portion. Occasionally multiple jobs of a build{world|kernel} will break on STABLE, but I haven't seen it recently.

prior run to prime cache:
# /usr/bin/time make -j8 DESTDIR=/usr/tmpworld installworld
Code:
       68.36 real        16.41 user        18.44 sys
# cd /usr/tmpworld/
# chflags -R noschg *
# rm -rf *
# /usr/bin/time make DESTDIR=/usr/tmpworld installworld
Code:
       75.33 real        15.51 user        13.50 sys

As I said, there's not much point in doing it, but it is in general safe. That's actually the first time I'm timed it and maybe I'll quit using the multiple jobs on install now as it saves about at much time as it takes me to type the -j parameter.
 
Back
Top