Published on (
 See this if you're having trouble printing code examples

OpenBSD Explained

OpenBSD Kernel Compilation and Optimization


As a completely open source system, OpenBSD benefits from the innate ability to be totally recompiled from scratch. This, of course, also includes the ability to rebuild the kernel, which is the "heart" of any operating system. Recompiling a kernel with specific options and parameters will provide not only driver support, but also powerful optimization and speed enhancements for your entire system.

To recompile, you need a full syssrc tree, which can be downloaded via either CVS or FTP. CVS will provide you with a bleeding-edge -CURRENT source tree, while a "release" kernel source tree can be downloaded via FTP.

To download via CVS:

export CVS_RSH="/usr/bin/ssh"

This sets CVS to run over SSH, which provides encryption and compression.


This sets the CVS server from which to download the tree. You can also view a full list of servers and syntax options.

cd /usr && cvs checkout -z9 src/sys

This downloads, with -z9 (high grade) compression, the entire kernel source tree for all architectures.

To download via FTP, simply point a browser or ftp client at:

Then put this into /usr/src and extract:

cp srcsys.tar.gz /usr/src ; tar -xzf /usr/src/srcsys.tar.gz

From this point, the process of kernel configuration and compilation is roughly a three step process.

Step 1

OpenBSD kernels, as opposed to Linux's kernel configuration utilities, draw their options entirely from a single configuration file, which resides in /usr/src/sys/arch/$ARCH/conf/ ($ARCH being your system architecture - each architecture has some options specific to it). Several example files are included for each architecture, but I find GENERIC the best for a first-time user to hack up. A lot of options are required for that particular architecture and should not be changed, and a lot are quite complex and extremely unlikely to be changed, so it's highly suggested to tinker, yet not expect a kernel to work properly if unknown options are changed. I'll run through a series of recommended tweaks to improve specific performance, some of which are i386 specific:

Processor & I/O:

option          I686_CPU

Select only one CPU option (this, if you have an i686) and hash out the rest. (Hash out means to comment out by putting a # at the front of the line.)

#option         GPL_MATH_EMULATE
Hash this option out unless you have a very old machine with no FPU.

option         DUMMY_NOPS
General speed hack.

option          UVM
Advanced Virtual Memory system. Speeds up a machine when swapping.

option          MFS
Memory File System. Can be used to create RAMDISK partitions for extremely fast data access.


option NMBCLUSTERS="8192"
Speeds up network operations under heavy traffic and prevents kernel panics under these conditions. A value of 1024 or 2048 is more suitable for systems with less traffic.

ef*     at isapnp?         # 3C515 PnP ethernet
This line and all those surrounding it in the GENERIC config file denote Ethernet chipset drivers. Hash out ALL unused drivers to speed up boot and free up memory.

Disk/Block Device:

ahc*    at pci? dev ? function ?    # Adaptec 2940 SCSI controllers
This line and all those surrounding it in the GENERIC config file denote SCSI and other block device drivers. Hash out ALL unused drivers to speed up boot and free up memory.

Reserves 45% of system memory as a filesystem buffer. A lower value is recommended, depending on how much free memory your system has. This is a good way to squeeze extra performance from large areas of idle memory.

Step 2

Once you've added/hashed out the options listed above and are satisfied with your kernel configuration, it's time to configure a build from your kernel config file and compile it into a kernel. This is done by performing the following commands:

cd /usr/src/sys/arch/$ARCH/conf ; config MYFILE

where $ARCH is your system architecture and MYFILE is the kernel config file you have written.

cd ../compile/MYFILE ; make depend && make

This will build your kernel dependencies and the kernel itself. This takes anywhere between five minutes and five hours depending on the speed and architecture of your system.

cp /bsd /bsd-original ; cp bsd /bsd

Installs your kernel and keeps the original kernel still bootable as bsd-original.

Step 3

With your new ultra-speedy kernel now in place, you're ready to reboot and make sure the kernel boots correctly and supports all the devices it's supposed to. After issuing a "halt" or otherwise resetting the system, the boot> prompt should appear. Your new kernel, if built using the exact instructions above, should boot automatically, but if not or if you wish to revert to the backed-up original kernel, you'll need to dictate the kernel to boot manually. This is in the simple format of device:/kernel-location, for example:

boot> boot wd0a:/bsd-original

boot> boot fd0a:/bsd

These commands boot the /bsd-original kernel from the first partition of the first IDE hard drive, or the /bsd kernel from the first floppy drive respectively. Should problems be encountered with the new kernel, a facility called the UKC (User Kernel Config) can perform boot-time configuration to attempt to debug it. The UKC can be invoked from the boot> prompt by using the -c flag. For example:

boot> boot wd0a:/bsd -c

Commands such as list, change, enable, disable, and of course help can be used within the UKC to configure devices and their I/O parameters and IRQ addresses. The UKC is quite complex, so I won't go into it in detail here. More information on the UKC can be found in the official kernel configuration how-to.

With the new optimized kernel working, you might be interested in benchmarking it against your previous kernel for performance. There are several benchmarking utilities available, but I find lmbench (available in the ports tree) to be a good indication of optimization. It provides scores for memory latency, CPU speed, and loopback network latency. In an age of exponential hardware growth and shortening life span of systems, it's good to see you can milk every last drop out of the hardware you have before going out and replacing it.

David Jorm has been involved with open source and security projects for several years, originally with OpenBSD and Debian GNU/Linux, now with the development team at

Read more OpenBSD Explained columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.


Copyright © 2009 O'Reilly Media, Inc.