Saturday, 30 May 2009

When and how to compile your own kernel

I've recently had a few debates containing pros and cons about compiling a Linux kernel, and I've decided to write a few thoughts about it.

First of all, when should you recompile your kernel? My humble opinion is - only when it is essential to you. This means, if you have some piece of hardware which requires recompiling of your kernel (not just adding a module or two), or a newer version that's available on your repositories, or if there is a feature in the kernel which you really need, and can't or don't want to switch to a different Linux distribution which has it out-of-the-box.

I'd like to say that you should, before anything else, pull the latest updates from your distro's repository. Sometimes there is a newer kernel in the repo which will make everything magically work. If it doesn't, download the kernel sources, configure them and compile.

I won't go into details about basics of compiling a kernel. This is actually pretty straightforward nowadays - you untar the archive, make menuconfig, make, make modules_install, mkinitrd or mkinitcpio -k -g , copy the initrd and kernel image to the /boot directory, edit the menu.lst in GRUB and you're ready to go. Ask google for details - the web is literally bursting with this stuff.

There is an important issue I'd like to talk about. Many people claim significant performance gains when they recompile their kernels. However, I've never seen any benchmarks on this. You will mostly gain some less boot time (if any), and the compiling process alone will be shorted (again, if any). However, if your distro's kernel is compiled well, you needn't worry about that. Nowadays openSUSE, Fedora and Slackware have their kernels compiled very well. Others are so-so, but they mostly all work.
So, if you're looking to compile your kernel in order to gain performance, you should give up right away. You mostly won't notice it.

On the other hand, there are (were) various patchsets which improve(d) performance of the overall system, depending on what you expect of it. Such were -viper (R.I.P.) or -ck (later -rt, but that one wasn't even a shadow of it's predcessor), and eventually most of the code got into the mainstream kernel.

So what gives?

If you like to experiment, you can "borrow" a kernel source from a different distro. I used the openSUSE kernel on my Arch Linux system for a long time, and will probably use it again, once it starts supporting ext4 filesystem. I'm just too lazy ATM to reinstall everything, after formatting back to ext3. OTOH, the Arch stock kernel works. Apart from openSUSE, good choices may be Fedora or Gentoo. All of their patchsets are interesting to play with. I repeat however, this is if you like to experiment. Do not count on something that will magically make your system faster, more stable and more secure.
One of the more interesting patchsets as well is the Zen patchset (I've mentioned it before) which can be obtained from It is claimed to be "stable and featureful", which is very true, and can give you a lot to tinker around with, as well as support for a lot of new hardware.

Ok, so how to compile?
Easy. Just untar the sources, make menuconfig, make and make install. :)
Seriously, there are things you need to look out for.

You want stability and small size of the kernel image? Look out for the stuff that's labelled as "EXPERIMENTAL" or "DEPRECATED". Disable it all. Unless you're absolutely positive (not just sure) that you need it.
Apart from that, you can also remove things that you don't need or use, such as the device drivers for the devices you don't have. But I hope you all know that by now (if from nowhere else, then from the articles some of you googled earlier).

How about moduling everything you can? The answer is simple: don't do it. The kernel image may be smaller, but it doesn't mean it will be faster. On the contrary, to be honest with you. You will lose performance if you module everything like crazy. Sure, you can compile the device drivers and things that you don't use all the time as modules, but that's it. Your main kernel features should stay inside the kernel.
This is something that was much debated. My answer to all this was - look at the Fedora and openSUSE kernels (both compiled by teams of engineers - and believe me, these guys know what they're doing). Their images weigh more than 2.5MB. You can easily cut it down to 1.5MB and, with a little effort, below 1MB. What's the point?

What if I'm not sure? Simply leave it at the default value. Or try moduling it, and see if it's already loaded in the minimal system environment. If it is, consider building it in the kernel.

To conclude, there's always a million choices - just like with every Linux thing you do. Just watch what you're doing, and read stuff.

Oh yeah, and backup. You never know when you're going to sKrew up your own best-kernel-in-the-world, and then the stock kernel might come quite handy :)

No comments: