Linux Performance Tuning for the Faint of Heart

Recompiling your Linux kernel might not be as scary as you think. Clarence Smith gives us a good step-by-step process for building your own customized kernel.

Have you ever wondered why in the blazes someone would want to recompile a Linux system kernel? For some, that is a challenging question. Many new users to Linux are under the impression that when they install Linux, the installation itself is perfect. Don't assume that Linux is set up efficiently for your exact setup out of the box. Here's why (and how) to change it.

Let's say you have bought a new laptop, and you want to run Linux on it. You've got only 4MB of RAM, and you've got only 100MB of hard drive space. A finely tuned Linux kernel is key to having all possible memory space available on your system, and thus is the key to having a faster system for a small-time investment.

You are probably aware that Linux provides “virtual memory” (also known as swap space or paging space) that allows programs to use more memory than is really on the system by temporarily moving the contents of some of that memory to disk. You may not be aware, however, that no parts of the kernel can be paged out to disk. Every byte taken up by the kernel is a byte that can't be used by anything else.

If the kernel you are running has SCSI support, networking, and sound all compiled in, but you don't have or use SCSI, networking, or a sound card, you are wasting memory. This is probably the case if your kernel came with your Linux distribution, because those kernels are generally compiled to work with a very wide selection of devices, and are not tuned to your hardware.

If you only have 4MB of memory, you are also likely wasting a lot of time as other programs get swapped out to disk and then back into memory. By compiling a new kernel without the unnecessary pieces, you can make your Linux computer run a lot faster.

Fortunately, Linux makes this easy.

Think First

First of all, you need to consider the hardware you have. What types of peripherals do you have? What type of mouse do you have? Do you have a sound card?

To build and compile the best kernel for your system, you must be aware of your hardware make-up. You may find it helpful to sit down and list all the parts of your computer. Not only will this help you now, but it will also help you post good problem reports if you encounter a problem or bug, since you need the same information about your configuration when posting problem reports.

To configure your system, you first need to have the Linux source code installed on your system. This is available via ftp from in /pub/OS/Linux/PEOPLE/Linus, in the directory /pub/linux/sources/system, or in /pub/Linux/kernel, or other mirrors around the world. The directory name will depend on the kernel version: Linux versions 1.1.x are kept in the v1.1 directory, and have names like linux-1.1.45.tar.gz, with patch named like patch46.gz. You only need to get patches with numbers later than the version of the tar file you get.

Alternately, if you bought Linux from someone, they are required by Linux's GPL copyright to have provided the source, or to provide it (possibly for a nominal fee) upon request.

The source code should be unpacked into /usr/src/linux, because it expects to be there. See the sidebar “Unpacking the Linux Source” if you do not know how to do this.

After unpacking the source, you should apply any kernel patches that are needed to get the version you want. You should insert your patches (while they are still compressed, or gzipped) into /usr/src/linux. Then from /usr/src/linux, type:

gunzip -c patch?.gz | patch -s -p1gunzip -c patch??.gz | patch -s -p1

The ? gets patches 1-9 in order, and should be done only if you are using one of those patches. The ?? will get all patches (that exist, and that you have downloaded) between 10 and 99 in order. It is important that all the patches be applied in order. The -s argument to patch tells patch to work silently, and only complain about errors. The -p1 tells patch that we are in the /usr/src/linux directory, so that it knows how to find files, and puts new files in the right place. The -s flag is optional; the -p1 argument is mandatory.

Alternately, you can run each patch separately:

gunzip -c patch8.gz | patch -p1gunzip -c patch9.gz | patch -p1...gunzip -c patch46.gz | patch -p1

and so on.

Once you've completed the patches, you may want to remove any unnecessary files created by the patches. These files are the original versions of the files that are changed in any way, so they can take up a substantial amount of space. You can find and remove them by typing:

find /usr/src/linux -name '*.orig' -o -name '*~'-exec rm -f {} ;

You can look for any files that did not patch correctly, and thus find out in advance that there has been a problem that will likely make it impossible to compile your kernel, by typing:

find /usr/src/linux -name '*.rej' -print

That will list any files for which there were “rejected hunks”; patches that could not be fitted into the source correctly. If you find any of these files, start over. If you still see these files, ask someone for help; there are too many things that could be wrong to cover in this article.