Most distributions provide a “one-size-fits-all” kernel, compiled with the most generic options, so everybody can use it. If you have an Athlon XP CPU instead of an Intel 386 family processor, or lots of RAM, or a certain graphics card, you can tweak the kernel and compile it for optimum performance on your specific hardware. In the process, you can also probably free some memory by getting rid of unneeded options, shorten boot time, and increase responsiveness.
An almost dry run
Compiling your kernel isn’t very hard, but there’s a distinct chance you could hose your machine and transform it into a paperweight (ask me how I know!), so you will have to take some precautions. Have a backup kernel available; that way, should you really muck things up, you can reboot your computer and start again. I use openSUSE, on which it’s easy to install two or more kernels: by using the YAST administration tool or the Smart package manager, install two different versions of your kernel. For example, I have both 2.6.18.8-0.3 and 2.6.18.8-0.5, and my boot page shows:
openSUSE 10.2 - 2.6.18.8-0.5 Failsafe -- openSUSE 10.2 - 2.6.18.8-0.5 openSUSE 10.2 - 2.6.18.8-0.3 Failsafe -- openSUSE 10.2 - 2.6.18.8-0.3
By default, my machine is set to boot with the third option; I leave that version alone (so I can fall back on it if needed) and experiment with the first one. After building and being satisfied with your new kernel, you can use the standard tools (such as YAST for openSUSE) to set it as a default; more adventurous people could resort to editing GRUB or LILO boot configuration files by hand.
You will also have to install some specific packages: kernel-source (the source code you compile), gcc (the compiler), bzip2 (needed internally), and ncurses (for the configuration menus).
If you want to optimize your kernel, you need to know about your machine’s hardware. By using the commands below, you can note what kind of processor you have, the RAM in your machine, and more details. I suggest printing this information out and keeping it by your side while you work.
lspci -v cat /proc/cpuinfo cat /proc/meminfo
If you want to be sure you have everything that you can need, you can rebuild your kernel without touching anything. Working as root, enter the commands:
cd /usr/src/linux make clean make make modules_install make install reboot
The make process will run for a while, and might produce some warnings, but it shouldn’t show any errors. If, after you reboot, everything is still fine, you are set for your kernel rebuilding adventure; in fact, you have just done your first such build! (And if something did go seriously wrong, for example because you were missing some package, reboot with the backup kernel, fix the problem, and try a “dry run” again.)
Just say “M”!
Now, let’s compile a kernel for true. Once again, su in order to work as root, and enter:
cd /usr/src/linux make clean make menuconfig
You will see a screen showing a menu full of hundreds of options (so many ways to mess up!) but we will change just a few. Of course, if you feel adventurous, you can change anything you desire, as long as you set up an extra kernel just in case. If you want to disable an option, unmark it and it won’t get compiled. To navigate the menus and see the available options, use the cursor keys; press “H” to see help at any time.
The Linux kernel is monolithic, which loosely means that it’s just one big piece of software with everything thrown in. However, you can extend it by using modules, which are loaded on demand and only if needed. Thus, if you were to compile all possible functions as modules, the kernel would be as small as possible, and you would only suffer a small performance hit the first time a module was loaded. However, you don’t want to make everything a module, because some functions need be available at boot: for instance, you couldn’t read the partition that holds the modules if you didn’t already have the needed code in the kernel. But whenever it’s reasonable, set things up to be modules.
There’s another argument in favor of modules. Removing support for every seemingly unused piece of hardware can cause some strange problem: for example, I removed the option about LVM AND RAID DEVICES, and later found out this caused a needed module not to be built, which then caused lots of other problems. The safest approach is to mark undesired options with “M” (so they will be compiled as modules) and not leave out anything unless you are completely sure you won’t need it; cards or disk partition types you do not have, for example, are usually safe to remove. However, there are no guarantees that removing any option won’t have a secondary, hidden, undocumented effect, which might end up in some kind of problem. In that case, reboot with the backup kernel, and just mark the option in question again.
Some options you can study, in order to save some memory:
- In Networking, uncheck Amateur Radio Support unless you connect your PC to amateur radio. The other options are usually marked as “M”; leave them that way.
- In File Systems, verify that everything is marked “M.” If you are sure you won’t be needing, say, JFS, you could uncheck the corresponding option, or better yet leave it as a module.
- Also in File Systems, see Partition Types and uncheck everything that doesn’t apply to you. In my case, since I have Windows disks in my machine, I kept the Windows-related partitions.
- In Device Drivers, examine each section, and either uncheck or mark as “M” any device you do not have. SCSI or ISDN are options you are likely to be able to drop.
- In Bus Options, disable EISA and MCA support unless your motherboard uses these kinds of buses; check the manufacturer specs if you are not sure.
Full speed ahead!
Depending on whether you use your PC as a server or as a desktop machine, you can pick several options to enhance responsiveness. I recommend the following for a desktop machine:
- At Code Maturity Level Options, uncheck “Prompt for development and/or incomplete code/drivers”; you need this option only if you are developing or testing something in the kernel.
- At General Setup, uncheck “Cpuset support” unless you have more than one processor; dual and quad-core processors count as more than one.
- At Block Layer, uncheck everything unless you have disks that are larger in size than 2TB.
- At Processor Type and Features, uncheck “Symmetric multi-processing support” unless you have more than one processor, or a Duo or Quad one. Pick the right processor at Processor Family, and the amount of RAM you have at High Memory Support. At Preemption Model, pick the “Preemptible Kernel (Low Latency Desktop)” option. Finally, check “Preempt the Big Kernel Lock,” and at “Timer Frequency” pick 1000Hz.
- At Kernel Hacking, uncheck everything — you won’t be doing kernel development, will you?
After you have finished picking options, exit the configuration program (say “YES” when asked about saving your new kernel configuration) and then run:
make make modules_install make install
Pay particular attention to unexpected error messages that might show a problem with your new kernel. Be prepared to wait; on my laptop, the make process takes more than half an hour. If get an error message, you can either go back to the menu to try and fix whatever was wrong, or just reboot with your backup kernel. If you cannot figure out what happened (quite possible: it’s not always easy to relate an error to your menu choices) you can always reinstall your kernel (use YAST or Smart, as above) and start again.
If there were no error messages, reboot and try your new kernel.
In my case, I shaved about 10 seconds off the boot time, and also freed a couple of megabytes of RAM. The boot speedup isn’t really noticeable, but the laptop now feels a bit more agile — though that could of course be a placebo effect. Anyway, I learned a bit more about the kernel, optimized it for my own use, and gained a new tool in my search for speed.
In conclusion
If you want the swiftest possible Linux, don’t be afraid to compile the kernel. You can learn a lot, and in the end you should get better system performance.
