As most very experienced Linux users know, a custom-compiled kernel is a very good thing if done well. Your performance can double sometimes, because you are setting up a kernel optimized for your CPU. But it can be difficult to get it right. There are a number of different ways to do it, and every major distro has a distro-specific way. Here is a distro-irrelevant process I use to build my running kernel. I prefer this, because sometimes distro-specific kernel tools do not work as expected and/or documented.
This procedure includes the Real-Time Linux additions, and other configurations which are very good to keep latency — the time between MIDI controller keyhit and MIDI synth output — as low as possible, while keeping overall horsepower as high as possible. 10ms of latency (as reported by jackd) can be a liability when playing live; 5ms is often OK. With 2GHz-plus multicore hardware and 2G RAM, plus a realtime kernel, plus a good $100 sound card, you’ll be good to between one and three ms, which is not humanly detectable.
Much of this is in root-permissions command shell; and if you delete anything you shouldn’t, it can be dangerous to your system 
You have been warned
Our first step, is to prepare a compilation environment. We’ll stay in normal user command shell for now, change to the user home directory, create a directory for compilation, and get the source code for the new kernel. Here are commands:
cd ~ mkdir kernel cd kernel wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.6.tar.bz2 wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31.6-rt19.bz2
We also need the source for the kernel we are running right now. This depends on the distro. On Debian, I used the default GUI packager (Synaptic), and I retrieved package “linux-source” according to the version I found using the command:
uname -a
showed me I was using kernel 2.6.30-2 provided by Debian; I therefore installed package linux-source-2.6.30.
The next step is to go back to the above user-level command line shell, make sure we’re still in the right directory, unpack the source code package, and add the rtlinux additions:
cd ~/kernel tar xf linux-2.6.31.6 cd linux-2.6.31.6 bzip2 -cd ../patch-2.6.31.6-rt19.bz2 | patch -p1
Now we add the tools we need to compile a kernel, to the machine. There are quite a few bits needed, and I don’t know the simplest way to do it under anything not Debian-based. But under Debian, Ubuntu, or relatives, this works straightforwardly, in a root command shell; it uses the command-line packaging tools to get everything needed (the deps, dependencies) for building the currently running kernel. You may need to put the version number on the end.
apt-get build-dep linux-image
Now we configure the source code, to set it up to build the special kernel we want. The kernel builder looks at config file ‘.config’ (with dot first), so we’ll make that file, tell the builder to look at it, and then build and start the configurator. We’re back in the user-level command shell:
make menuconfig
The above gets us into the full-screen kernel source configurator. There are several things we need to add and change. First we’ll go into the “General Setup” section:
- Make an add-on name for your new kernel. This is very important, because if we don’t do it, we risk overwriting the current kernel. We very much want to keep the current kernel available, as a fallback. It’s in the “General Setup”, in the “Local version” area second from the top. The word “custom” is perfectly fine. It will be added to the end of the default name. No spaces or strange characters please!, because all sorts of Linux system functions will be reading this.
- By default, the kernel is optimized for size. This is quite helpful, unless you’re running lots and lots of RAM (for example, 4G RAM as in my case). Then we want the compiler to optimize for speed and not worry about size. This option is near the bottom of the list.
- Turn profiling off. Profiling can hurt performance, it’s used by kernel developers.
Now hit Esc and Esc again, to get back to the main menu. We’ll choose CPU now, under “Processor type and features”.
- Turn off “Tickless System (Dynamic Ticks)”.
- Turn on “High Resolution Timer Support”.
- Move down to “Processor Family”, and open it up. Choose the processor which is closest to yours. This can get tricky, especially on 32-bit systems where there are lots of options to cover the entire range from 386 all the way through the last of the 32-bit Intel Xeon server CPUs. You’ll want to know your CPU, whether it’s Intel or AMD, whether it has 3DNow, sse, or sse2 support, et cetera. If you get this right-on, you’ll get more horsepower than you dreamed was in your machine; if you undershoot, you’ll lose performance; if you overshoot too much, you will have built a perfectly good kernel which won’t run on your machine at all So choose VERY carefully here. Your best first clue comes by running this command:
cat /var/log/messages | grep CPU0
which on my system yields four lines reading:
Dec 25 23:04:44 jebslinux kernel: [ 0.014874] CPU0: AMD Phenom(tm) 9950 Quad-Core Processor stepping 03
As you will see, this is a good clue — but especially on 32-bit platforms there will still be some homework to do, to figure out how your CPU matches up to the kernel’s options.
- Now hit Esc Esc again to go up one level, and move down to “Preemption Mode”. Enter that section, and choose “Complete Preemption (Real-Time)”. Then Esc Esc to go up again.
- Move down fairly far, until you find “Timer frequency”. Make sure this one is set to 1000 Hz. Then Esc Esc to go up.
- Move down to “Device Drivers”, and go in. Move all the way to the second-to-last, “Staging Drivers”, and uncheck. Staging drivers are experimental, beta, even alpha; we don’t want them at all, they can destabilize things. Esc Esc.
- Just one more. We’ll speed up the system, by turning off some debugging code we don’t need. Move down to “Kernel Hacking”, and go in. Move pretty far down, to “Tracers”, and uncheck. This takes care of a lot.
Now we’re ready to build! Run these commands one at a time. They will both take a while. If you see “fatal error” at the end of either, you have done something sufficiently wrong, that it didn’t work This part is still for the user-level comand shell.
make bzImage make modules
And now we’re ready for installation. We’re now in root-level shell. First steps are straightforward:
make modules_install make install
Depending on the distro, the next step may be optional. Let’s find out like this:
ls /boot/initr*
If there is anything listed, and nothing there matches your new kernel’s name, we need to create an initrd, also called an initramfs. As of kernel 2.6.33.1 built on RedHat 12+CCRMA, this was automatic; as of Debian Testing recent, I had to make one! This is a big file which the kernel uses during boot, containing basic hardware information needed during the boot process. If you have something like this, you may need to install the package for the application which can build you a new one:
apt-get install mkinitrd
To create an initrd, the first step is to move (in root command-shell) to /boot, where the kernels are stored, and look at the kernel file installed by ‘make install’ just previously. In my case, my kernel file is “vmlinuz-2.6.31.6-rt19custom4″, because the add-on name I set was “custom4″. Knowing you will have to replace “custom4″ with the add-on name you chose, here are the next steps:
cd /boot update-initramfs -c -k 2.6.31.6-rt19custom4
We have just one big step left: adding the new kernel (and initrd if it exists) to the boot loader. There are three boot loaders in common use today: grub, grub legacy, and LILO. At this writing (12/26/2009), I believe that the majority of current distributions are still using so-called “grub legacy”; one thing for which I am grateful in Debian Testing, is that it uses the current grub. I will cover grub and grub legacy below; in my own experience LILO has failed inexplicably often enough that I won’t recommend it.
If you are running grub and not grub legacy, the following command will work from a root-level command shell:
ls /boot/grub/grub.cfg
You will need to edit this file. Be very careful; if this file is bad enough, your system will reboot into a crash next time, you’ll have to rescue your system by reinstalling grub from a LiveCD, which can get sticky.
In grub.cfg, the areas of greatest importance to us will look much like this:
menuentry "Debian GNU/Linux, with Linux 2.6.30-2-amd64" {
insmod jfs
set root=(hd0,1)
search --no-floppy --fs-uuid --set 91694db0-2061-498d-9ada-09e767954bae
linux /boot/vmlinuz-2.6.30-2-amd64 root=UUID=91694db0-2061-498d-9ada-09e767954bae ro quiet
initrd /boot/initrd.img-2.6.30-2-amd64
}menuentry "Debian GNU/Linux, with Linux 2.6.30-2-amd64 (recovery mode)" {
insmod jfs
set root=(hd0,1)
search --no-floppy --fs-uuid --set 91694db0-2061-498d-9ada-09e767954bae
linux /boot/vmlinuz-2.6.30-2-amd64 root=UUID=91694db0-2061-498d-9ada-09e767954bae ro single
initrd /boot/initrd.img-2.6.30-2-amd64
}For every kernel you have installed, there will be at least one of those curly-bracket sets, and possibly two; the second one on my system (from which the above came) is a single-user-mode boot option, like a safe mode boot for emergency fixes. In my grub.cfg, near the top, I also have a line:
set default=0
This means that the first (#0) curly-bracket “menuentry” specification, will be automatically engaged by default. There is also:
set timeout=5
which sets how long in seconds grub should pause, to permit you to choose the kernel you will boot. Regardless of these two, you will want to duplicate the menuentry in use, making sure to replace both the vmlinuz and initrd filenames with the new ones. It is best to place the new menu entries in the bottom of the list if your automatic setting is for the first; your first kernel very well may not work perfectly hint, hint. You can always edit your grub.cfg after you prove that your new kernel is good to go.
If you have grub legacy, you won’t have a grub.cfg; you will have a /boot/grub/menu.lst or occasionally a /boot/menu.lst:
ls /boot/grub/menu.lst ls /boot/menu.lst
In menu.lst, the areas of greatest importance to us will look much like this:
title Debian GNU/Linux, kernel 2.6.30.1-avlinux-lowlatency-pae root (hd0,0) kernel /boot/vmlinuz-2.6.30.1-avlinux-lowlatency-pae root=UUID=6ebe6c59-a06a-458f-8f33-8f2a2124865e ro initrd /boot/initrd.img-2.6.30.1-avlinux-lowlatency-pae
title Debian GNU/Linux, kernel 2.6.30.1-avlinux-lowlatency-pae (single-user mode) root (hd0,0) kernel /boot/vmlinuz-2.6.30.1-avlinux-lowlatency-pae root=UUID=6ebe6c59-a06a-458f-8f33-8f2a2124865e ro single initrd /boot/initrd.img-2.6.30.1-avlinux-lowlatency-pae
For every kernel you have installed, there will be at least one of the “title” items a la the above, and possibly two; the second one on my old AVLinux system (from which the above came) is a single-user-mode boot option, like a safe mode boot for emergency fixes. There are some hacks out there automating the creation of menu.lst files; these often use comment lines like “### BEGIN AUTOMAGIC KERNELS LIST” and “### END DEBIAN AUTOMAGIC KERNELS LIST” to surround automatically installed kernels. You will need to duplicate your existing title items, replacing default kernel and initrd filenames with your new ones; and you should put the new ones outside of any automatic lists. There are also lines like this:
default 0
which specify which “title” item to run automatically, and also
timeout 5
which specifies how long in seconds to wait until the automatic choice is started.
There are bells and whistles in both grub legacy and grub; some of these can cause the list to be hidden behind images, etc., and it is possible to turn off that timeout altogether so there is no choice. I definitely recommend that you keep the timeout set to at least 3 seconds, and make sure no graphics hide the boot options from you.
And after you have edited your grub.cfg or menu.lst, you are ready to try a reboot. Be brave! If it works perfectly, you’re done. If not, reboot into your original kernel, and try, try again.