Chapter 4: Kernel Games

Overview

The first step in optimizing FreeBSD is to configure the kernel. If you're new to UNIX administration, the word kernel might be intimidating. After all, the kernel is one of those secret parts of the system that mere mortals are not meant to dabble in. In fact, in some versions of UNIX, such as Solaris, going in and tampering directly with the kernel is unthinkable. In the open−source UNIX world, however, meddling with the kernel is the best way to improve your performance. (It would probably be the best way to tune other operating systems as well, if you were allowed to.)

The FreeBSD kernel can be dynamically tuned, or changed on the fly, and most aspects of system performance can be changed as needed. We'll discuss the kernel's sysctl interface, and how you can use it to alter a running kernel.

At the same time, some parts of the kernel cannot be altered while running, and some kernel features require extensive reconfiguration. Also, you might want to reduce the size of your kernel by removing unneeded components. The best way to do this is to build your own kernel, and I'll show you how.

Finally, we'll discuss loadable kernel modules—kernel subsystems that can be turned on or off as needed.

What Is the Kernel?

You'll hear many different definitions of kernel. Many are just flat−out confusing. The following definition isn't complete, but it's good enough for our purposes, and it's comprehensible: The kernel is the interface between the hardware and the software.

The kernel allows you to write data to disk drives and the network. It handles CPU and memory operations. It translates an MP3 to a stream of zeros and ones that your sound card understands, and tells your monitor where to put the little colored dots. The kernel provides interfaces to programs that need access to the hardware.

While the kernel's job is easy to define (at least in this simplistic manner), it is difficult to actually perform. Different programs expect the kernel to provide different interfaces to the hardware, and pieces of hardware provide their resources in varying ways. The kernel has to cope with all of this. For example, your kernel controls memory usage, and if you have a program that demands that memory be allocated in a way your kernel doesn't support, you're in trouble. (Programs request memory in a variety of ways.) Too, if your kernel doesn't know how to talk to your network card, the network card won't work. The way your kernel investigates some hardware during the boot sequence defines how the hardware behaves, so you have to control that. Some network cards identify themselves in a friendly manner, while others lock up hard if sent a simple query.

The actual kernel is a file on disk: /kernel. Kernel modules—the kernel code that can be loaded and unloaded after boot—lives in /modules. Kernel modules are required in this day of detachable hardware, such as PC Cards and USB, and they can also provide additional functionality that you don't want to permanently add to the kernel. Every file you see outside of /kernel and /modules is not part of the kernel; these files and programs as a group are called the user−land, meaning they're meant for users. But at the same time, these programs and data use the kernel facilities.

70