What is the benefit of compiling your own linux kernel?

Question

What benefit could I see by compiling a Linux kernel myself? Is there some efficiency you could create by customizing it to your hardware?

Answer 1

In my mind, the only benefit you really get from compiling your own linux kernel is:

You learn how to compile your own linux kernel.

It's not something you need to do for more speed / memory / xxx whatever. It is a valuable thing to do if that's the stage you feel you are at in your development. If you want to have a deeper understanding of what this whole "open source" thing is about, about how and what the different parts of the kernel are, then you should give it a go. If you are just looking to speed up your boot time by 3 seconds, then... what's the point... go buy an ssd. If you are curious, if you want to learn, then compiling your own kernel is a great idea and you will likely get a lot out of it.

With that said, there are some specific reasons when it would be appropriate to compile your own kernel (as several people have pointed out in the other answers). Generally these arise out of a specific need you have for a specific outcome, for example:

• I need to get the system to boot/run on hardware with limited resources
• I need to test out a patch and provide feedback to the developers
• I need to disable something that is causing a conflict
• I need to develop the linux kernel
• I need to enable support for my unsupported hardware
• I need to improve performance of x because I am hitting the current limits of the system (and I know what I'm doing)

The issue lies in thinking that there's some intrinsic benefit to compiling your own kernel when everything is already working the way it should be, and I don't think that there is. Though you can spend countless hours disabling things you don't need and tweaking the things that are tweakable, the fact is the linux kernel is already pretty well tuned (by your distribution) for most user situations.

Answer 2

Most users do not need to compile their own kernel, their distribution has done this work for them. Usually distributions will include a set of patches to either integrate with certain parts of the way the distribution works, backports of device drivers and fixes from newer, but unreleased versions of the kernel or features that they are pioneering with their users.

When you compile your own kernel, you have a couple of options, you can compile an official Linus Torvalds kernel, this will not include any of the patches or customizations that were added by your distribution (which can be good or bad) or you can use your distribution rebuild tool to build your own kernel.

The reasons you might want to rebuild your kernel include:

• Patching bugs or adding a specific feature to a production system, where you can not really risk upgrading the whole kernel for a single fix or two.
• To try out a particular device driver, or a new feature
• To extend the kernel, work on it
• testing some of the "Alpha" modules or features.

Many developers use it to create also custom versions of the kernel for embedded systems or settop boxes where they need special device drivers, or they want to remove functionality that they do not need.

Answer 3

Compiling the kernel yourself allows you to only include the parts relevant to your computer, which makes it smaller and potentially faster, especially at boot time. Generic kernels need to include support for as much hardware as possible; at boot time they detect which hardware is attached to your computer and loads the appropriate modules, but it takes time to do all that and they need to load dynamic modules, rather than having the code baked directly into the kernel. There's no reason to have your kernel support 400 different CPUs when there's only one in your computer, or to support bluetooth mice if you don't have one, it's all wasted space you can free up

Answer 4

I can't believe the accepted answer here starts out saying "It's not something you need to do for more speed / memory / xxx whatever."

This is totally false. I routinely custom build my Kernels to both remove unneeded code as well as including performance enhancing code mostly related to hardware. For example, I run some older hardware and can eek out some performance gains by enabling rarely enabled Kernel drivers such as HPT36x chipset support on some older MoBos that have this built-in.

Another example, BIG SMP under Slackware is the default and on a Dell 2800, for example, will consume a sizeable foot print to run things like GFSD (not as a kernel module) that, also by the way, consumes CPU ticks for something I don't need. Likewise for NFSD and other catch-all to please all mentalities which is fine if you're just trying to get a Linux on a box and running but if you do care about "speed / memory / xxx whatever" then these things matter and work.

All my production boxes are custom Kernels. If I'm on common hardware such as a Dell series (2800, 2850, 2900, etc...) hardware, it's simple matter of copying the kernel's .config file around to each box and compiling the kernel and installing.

Answer 5

Here are some situations where compiling your own kernel will benefit you:

• A kernel with module loading disabled is more secure. This will require you to select the modules you know you need and include them as part of the kernel, as opposed to compiling them as modules.

• Disabling support for /dev/kmem, or crippling it with the appropriate compiler option is a good thing for security. I think most distros do this by default now.

• I prefer not to use initrd's when possible. Customizing your kernel to the hardware it boots from eliminates the initrd.

• Sometimes a later kernel version will have features you need, but this is very rare today. I remember when I first started using Debian, it was using 2.4 kernels, but I needed a 2.6 kernel for udev support.

• Disabling networking protocols/options you don't need can speed up your TCP/IP performance.

• Disabling options you don't need lowers the memory footprint of the kernel, which is important in low RAM environments. When you are using a 256MB RAM system as a router, this helps.

• I find all the "tty" devices in /dev annoying on systems where I generally only log in via serial or ssh.

Answer 6

I second gabe.'s answer (my comment is too long so I'm posting as an answer).

Unless you have a highly specialized purpose (e.g. embedded machines, strict security profiling), I see no practical benefit to compiling your own kernel other than to see how it's done. By methodically reviewing the options, seeing how they interact with each other to build the system is a great way to understand how your system works. It's amazing what you find out when you try to remove components that don't appear to have any purpose for the tasks you're trying to accomplish.

Be warned however--why jumping down the rabbit hole is undoubtedly exhilarating, it will suck back more nights and weekends than you thought possible!

Answer 7

Compiling your own kernel allows you to participate in the kernel development process, whether that is simple stuff such as supplying PCI/USB device IDs for an existing driver that may make a newer device work for you, to getting deeply involved in the fray of core kernel development.

It also allows you to test development kernels on your hardware and provide feedback if you notice any regressions. This can be particularly helpful to you and others if you have an uncommon piece of hardware. If you wait for a distro kernel, it can take some time for fixes from your problem reports to filter into a new distro kernel release.

I also personally like to compile my own kernels to include support for only the hardware that I have. When you run distro kernels and look at the output of lsmod(8), you see lots of modules loaded for hardware you don't have. This can pollute the module list, /proc, /sys and your logs such that when you're searching for something it can get hidden amongst the noise; You also cannot be 100% sure that those modules are not contributing to a problem you are trying to diagnose.

Answer 8

At work, we use hand-rolled kernels in order to apply out-of-tree patches such as vserver and unionfs.

At home, I am compiling hand-rolled kernels in order to find which commit introduced a bug I am experiencing. Once I've finished that, I will probably stick to a hand-rolled kernel until the bug is fixed in my distribution (Debian), at which point I would revert to their kernels again.

Answer 9

I'm surprised that no one mentioned this reason for compiling a custom kernel:

because you want to use a different C/c++ compiler. GCC is pretty good for compiling the linux kernel. But there are vastly superior compilers out there! GCC's optimizations are a bit behind Intel's C/C++ compiler. And Intel supplies the performance primitives libraries, and the vtune tool, both of which are indispensable in producing a high-performance linux kernel. You can only get so far with GCC and G++. Practically no matter what you do the result will be limited by the compiler. So, I use the Intel compiler and performance libraries It's a bit big--1.5GB download, but that gives a bit of an idea of what is all contained in a good compiler.

Intel's C/C++ compiler is available free for noncommercial use. But it's easier to google the noncommercial license Intel c++ compiler download page that to search Intel's website. I don't usually use GCC/G++ for anything. And you don't need to be a programmer. You just set your environment and change two lines in the make file to point to Intel's compiler.

Then you can get some serious speed!

Answer 10

This thread is age old and yet still is valid today as it was when the question was asked!

The answer is: You compile the linux kernel of your choice as per your need and requirements.

Many scenarios are valid:

1. You are an engineer and requires your build to meet the performance and security requirements/demands for your system, you recompile to meet and/or surpass the specified criterias.

2. You are a normal user and have an old system that you want to keep going for as long as you can, you recompile to add/remove components to keep your old system optimised.

3. You are a normal user with the latest fastest hardware and it has more than enough memory/RAM. No need to recompile but you still can if you are interested in learning a bit more about your system.

4. You just want to be like a Microsoft and/or Mac everyday user, don't recompile and just go with the updates from your upstream distro.

5. Keep the scenarios coming :-)

Unlike Mac/Windows users, what Linux provides is choice. The choice to take it easy or optimise the system to your requirements.

Answer 11

For most uses generic kernels are good for virtually any hardware. Additionally they usually contain(ed) distribution-specific patches so compiling your own kernel may (might) cause problems.

The reson to compile your own kernel are:

• You are using source-based distro so there is no 'generic' kernel
• You are kernel developer and you develop kernel
• You must customize kernel for example for embedded device with very limited hard drive
• Some driver is not compiled in (very rare case)
• You want to patch kernel AND you know what you are doing
• You want to learn how to compile kernel

If I wasn't using source-based distro I wouldn't compile kernel at all.

Answer 12

If you want to install Linux on very specific hardware, say more exotic than a DS, you will have to cross-compile your own kernel.

Answer 13

Another case besides the many mentioned here for having custom compiled kernels is setting up specialized network boot environments where module loading is not feasible and you have to pass out fully working kernels to specific machines for specific tasks.