# Kernel/Base compilation tweaks



## Pantu (May 20, 2011)

Hi everybody,

I am trying to get the most out of the system in terms of performance, as it seems for me pretty slow compared to other systems. This one is about getting the most out of the kernel.

My question is, will it be better to use the latest gcc to compile the kernel and the base system or should I stick to the standard compiler?

So far my make.conf looks like this, I haven't started yet, as I am still looking for more performance tweaks:

```
CC=  gcc45
CXX= g++45
CPP= cpp45

KERNCONF=		MYCUSTOM
CPUTYPE=		i386
CFLAGS=         	-O2 -pipe -fno-strict-aliasing
COPTFLAGS=      	-O2 -pipe -funroll-loops -ffast-math -fno-strict-aliasing

OPTIMIZED_CFLAGS=       YES
BUILD_OPTIMIZED=        YES
WITH_CPUFLAGS=          YES
WITHOUT_DEBUG=          YES
WITH_OPTIMIZED_CFLAGS=  YES
NO_PROFILE=             YES
BUILD_STATIC=         	YES

NO_BLUETOOTH=    	true    # do not build Bluetooth related stuff
NO_FORTRAN=     	true    # do not build g77 and related libraries
NO_GDB=         	true    # do not build GDB
NO_GPIB=         	true    # do not build GPIB support
NO_I4B=          	true    # do not build isdn4bsd package
NO_IPFILTER=     	true    # do not build IP Filter package
NO_KERBEROS=     	true    # do not build and install Kerberos 5 (KTH Heimdal)
NO_LPR=          	true    # do not build lpr and related programs
NO_MAILWRAPPER=  	true    # do not build the mailwrapper(8) MTA selector
NO_NIS=          	true    # do not build NIS support and related programs
NO_SENDMAIL=     	true    # do not build sendmail and related programs
NO_SHAREDOCS=    	true    # do not build the 4.4BSD legacy docs
NO_GAMES=        	true    # do not build games (games/ subdir)
NO_INFO=         	true    # do not make or install info files
NO_PROFILE=      	true    # Avoid compiling profiled libraries

### BIND OPTIONS
NO_BIND=           	true    # Do not build any part of BIND
NO_BIND_DNSSEC=         true    # Do not build dnssec-keygen, dnssec-signzone
NO_BIND_ETC=            true    # Do not install files to /etc/namedb
NO_BIND_LIBS_LWRES=     true    # Do not install the lwres library
NO_BIND_MTREE=          true    # Do not run mtree to create chroot directories
NO_BIND_NAMED=          true    # Do not build named, rndc, lwresd, etc
```

What else can I improve? Can I actually use *-O3*, and which other switches would you recommend to make the kernel and base run fastest.

Maybe there is even another compiler who does an even better job for everything. Any recommendations on that?

Thank you
Pantu


----------



## wblock@ (May 20, 2011)

Pantu said:
			
		

> So far my make.conf looks like this, I haven't started yet, as I am still looking for more performance tweaks:
> 
> ```
> ...
> ...



The CPUFLAGS settings and maybe the OPTIMIZED settings may cause mysterious failures to compile or run.  If you use them, expect problems.


----------



## DutchDaemon (May 20, 2011)

Leave the compilers and flags alone, or expect zero help on these forums. We've been over this dozens of times. It's invariably much more trouble than it's worth.


----------



## Pantu (May 21, 2011)

Hmm I see, thank you for the tip.

I am still wondering then, if it will be safe to leave at least those on:


```
BUILD_STATIC=         	YES
WITHOUT_DEBUG=          YES
NO_PROFILE=             YES

NO_BLUETOOTH=    	true    # do not build Bluetooth related stuff
NO_FORTRAN=     	true    # do not build g77 and related libraries
NO_GDB=         	true    # do not build GDB
NO_GPIB=         	true    # do not build GPIB support
NO_I4B=          	true    # do not build isdn4bsd package
NO_IPFILTER=     	true    # do not build IP Filter package
NO_KERBEROS=     	true    # do not build and install Kerberos 5 (KTH Heimdal)
NO_LPR=          	true    # do not build lpr and related programs
NO_MAILWRAPPER=  	true    # do not build the mailwrapper(8) MTA selector
NO_NIS=          	true    # do not build NIS support and related programs
NO_SENDMAIL=     	true    # do not build sendmail and related programs
NO_SHAREDOCS=    	true    # do not build the 4.4BSD legacy docs
NO_GAMES=        	true    # do not build games (games/ subdir)
NO_INFO=         	true    # do not make or install info files
NO_PROFILE=      	true    # Avoid compiling profiled libraries

### BIND OPTIONS
NO_BIND=           	true    # Do not build any part of BIND
NO_BIND_DNSSEC=         true    # Do not build dnssec-keygen, dnssec-signzone
NO_BIND_ETC=            true    # Do not install files to /etc/namedb
NO_BIND_LIBS_LWRES=     true    # Do not install the lwres library
NO_BIND_MTREE=          true    # Do not run mtree to create chroot directories
NO_BIND_NAMED=          true    # Do not build named, rndc, lwresd, etc
```


----------



## UNIXgod (May 21, 2011)

Pantu said:
			
		

> Hmm I see, thank you for the tip.
> 
> I am still wondering then, if it will be safe to leave at least those on:
> 
> ...



As it probably states in the manual or even the make.conf example file you wont be able to get help from upstream if you run into real problems. If you're attempting to build for an embedded system or system with low resources there is nothing stopping you from experimentation.


----------



## Pantu (May 21, 2011)

Ok, I understood! I am just curious about it. All the NO_XXX will just exclude stuff, why should I have problems with this? Another one, I cannot exactly figure out the meaning of this:


```
BUILD_STATIC=         	YES
NO_PROFILE=             YES
```

I try to state what I have understood
*BUILD_STATIC*
+ All code will go into the binary and will not be linked with libs, so the binaries will be very big, take some time to load (during slowness of the disk), but will be fast during executing. 
+ I am not sure what happens if I have to recompile a "static" port, do I have to recompile everything that has something to do with it or just the one port?

*NO_PROFILE*
It says: _avoid building profiled libraries_
Unfortunately I cannot get what is meant by _profiled_


----------



## xibo (May 21, 2011)

Static linking might in fact, under the condition that there is heavy load on the system, decrease performance. Under normal circumstances multiple users of a shared library(=programs) would share the code pages in memory, which means less memory usage. However if there are no runtime linked libraries being used, those 100MB KDE programms will use 100MB each on their own while normally they are about 20-30MB for each started programm while the remaining 70MB are shared with the other KDE programms.

When updating a statically linked programm nothing is different from updating a runtime-linking programm. When updating a statically linked library however, you need to recompile any program that uses that library in order to get the update effects.

Profiling is the term for compiling an application with special statistic features and running test samples while evaluating statistics on which end of your programm was running for how long, as well as how often each section in run, memory usage, and so on. A compiler might reorder code or put more costy optimization into more frequently used sections, while a programmer gains information. Compiling with profiling information and recompiling later after some tests ( done automatically in the FreeBSD build system iirc ) will drastically increase compile time (everything needs to be built twice) while the performance gain is probably only very small.

Also take care that in ports, next to any package that would profit noticably from -ffast-math actually enables it either by default or by config option, while in the system there is effectively no gain by that flag at all, so chances it breaks something in system are higher then the chances you'll speed up something


----------



## Pantu (May 21, 2011)

@xibo,
Thank you for your clear explanation. Unfortunately that makes me a bit frustrated, as I had thought I could tune it up to the max. So anyway, then I will try to make it proper and clear at least.

So that I got you right, I just leave the *CPUTYPE* and all the *NO_XXX* modules inside my make.conf and remove the rest, then I won't get any complications during build.

I will then need to look into some other edges where to improve the speed


----------



## SirDice (May 21, 2011)

For the base OS settings /etc/make.conf has been deprecated in favor of src.conf(5). Don't use those NO_* variables.


----------



## Pantu (May 21, 2011)

@SirDice, thanks for the hint, but the question is still open.
If I replace the NO_ with WITHOUT_ will those exclusions be OK?


----------



## SirDice (May 21, 2011)

Pantu said:
			
		

> If I replace the NO_ with WITHOUT_ will those exclusions be OK?


Read the src.conf(5) man page.


----------



## Pantu (May 21, 2011)

Obviously I have already looked at it, and it mostly just states what the statement itself reaveals, but no more, that's why I am asking.

This is not a very nice way to just point people always to so many directions without actually answering the questions itself. This is really frustrating me and doesnt show a warm welcome in this community. I just made a simple question.

Here is an example:

```
WITHOUT_PROFILE
	     Set to avoid compiling profiled libraries.
```
How should that help me?


----------



## troberts (May 21, 2011)

Pantu said:
			
		

> So that I got you right, I just leave the *CPUTYPE* and all the *NO_XXX* modules inside my make.conf and remove the rest, then I won't get any complications during build.
> 
> I will then need to look into some other edges where to improve the speed


When you include the CPUTYPE option in your make.conf file you should put the '?' mark before the '=' sign like so:

CPUTYPE?=athlon-mp

Replace "athlon-mp" with the type of CPU you are using. Also, to prevent system modules (i.e. BIND) from getting built you need to put those in /etc/src.conf and if you do not know what can be not included then 

`# man src.conf`


----------



## davidgurvich (May 21, 2011)

When you say slow is that an objective measure, like gcc takes 5 minutes to compile a program that takes 1 minute using X, or are you talking about desktop latency for networked applications, like firefox fails to resolve dns quickly and takes 10 times as long to start loading a website?

These sorts of problems are rarely fixed by tweaking kernel compile flags.  Most of the latency from using DEBUG features can be reduced by using sysctl but that is usually not much of an issue.  Optimized CFLAGS might give you a 1% or 2%  boost but are more likely to cause stability issues.


----------



## Pantu (May 21, 2011)

davidgurvich said:
			
		

> like gcc takes 5 minutes to compile a program that takes 1 minute using X.


I read this sentence so many times, but I don't get it - sorry :r

No, I am talking about X or Gnome being slow. It takes quite some time to start up and also for programs to open. I have compiled everything (base, kernel, Xorg, Gnome) by hand using an empty make.conf, so I thought I have to redo everything with optimization on.

But for the Gnome issue, I have opened another thread:
Gnome2 Performance

I also have to say, that I am running *9-CURR* and heard there's still quite some debug code integrated, that I also would like to turn off.

So that's why I have added all those NO_XXX and in the new syntax WITHOUT_ stuff to my make.conf which are now in src.conf.

As I didn't know that many options are not safe to set, my question is still about all the WITHOUT_XXX that I have stated earlier. Can I safely activate them?


----------



## razixx (Jun 3, 2011)

Pantu maybe read tuning(7) man page for extra ideas on tweaks you can use to squeeze out a little more performance.

As far as the kernel goes though, I would start out with a GENERIC config and start stripping out whatever is not needed.  According to the handbook, it recommends only concerning yourself with the CPUTYPE variable.  Messing with CFLAGS is just asking for trouble and not supported and also the reason why you are getting ambiguous answers.

When I was a Gentoo Linux nut, this sort of behavior was encouraged, but in the BSD world things are done a little differently.  The performance gained vs the time wasted just isn't worth it.


----------

