# What is the benefit of compiling your own linux kernel?

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

-

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.

-
I'd argue that if you want to build your own kernel simply for the learning experience, that you do it with a source-based Linux distribution like Gentoo or Linux From Scratch. The Gentoo stage 2 install documentation is an excellent guide to understanding what it means to build Linux from the kernel up. –  Sandy Aug 20 '10 at 17:04
Agreed... those two projects are built for this type of thing. –  gabe. Aug 20 '10 at 18:08
Of course you know you actually contradict yourself in your answer. If the only benefit of compiling the kernel was to learn how to do it, then it would be useless - have no value. But then a few words later you say it is a valuable thing... –  rozcietrzewiacz Aug 1 '11 at 18:14
@rozcietrzewiacz Knowledge is of the utmost value. Compiling a kernel helps you extend your knowledge. If you don't buy that, then here's this - knowledge is power, and people pay good money to get power, and money holds value in today's world, so by the transitive property.... :P –  lunchmeat317 Sep 2 '11 at 19:38
I agree, It is worth it only for the knowledge gained. –  1100110 Jan 25 '12 at 11:07

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.

-

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.

-
All true. However, removing module loading can cause problems on boot: most, if not all, distributions today just assume that modules will need to be loaded. Last time I turned off modules, it caused a litany of error messages to pop out during the Red Hat boot process. –  Mei Feb 4 '12 at 0:58

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.

-
I think the main point of the accepted answer is that for most hardware, the performance gained by compiling your own kernel are not worth the time required to learn how to do it (and learn what the options mean). That is probably experiential: it would be great to find some numbers on this. –  Andres Riofrio May 5 '12 at 2:31
well then that it's disingenuous to not state this in the original question and then accept the answer that is on the grounds you allege. –  Eric May 10 '12 at 2:20
Well, it's not my fault my answer was accepted. And while yes there are cases where compiling your kernel will help you "eek out some performance" or get up and running on a low power machine, I made the assumption that the original question was being asked by someone who didn't have a specific need ahead of time, and was just curious in the general sense what the benefit of compiling a kernel was. I would argue that only people with specific requirements in mind benefit from kernel tweaks. Since my answer was accepted I'll improve it to address the more power-user reasons for custom kernels –  gabe. Feb 6 '14 at 13:45

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.

-

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.

-

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.

-

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.

-

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

-
I agree with most of your answer, but I'd be curious for some hard facts on "considerably faster". I wouldn't want to give a new user the impression that their desktop will run generally faster with a hand-built kernel (from my experience with Gentoo, this is simply not true). Can you quantify the gains in boot speed? –  Sandy Aug 20 '10 at 17:02
+1 to Sandy's comment, I definitely agree with smaller, but not sure about it being significantly faster. I'd also like to see some data on this if you can provide it. –  David Z Aug 20 '10 at 17:26
@Michael if it's an unverified assumption, I think replacing "considerably faster" with "potentially faster" in your answer might be a good idea...just to make sure no n00bs are misled. :-) –  Sandy Aug 20 '10 at 19:30
@Sandy Agreed, since it looks like I am one of those n00bs :). Fixed –  Michael Mrozek Aug 20 '10 at 21:36
I think "considerably" faster is actually justified with the caveat that we are talking about boot times. The stock distro kernels take easily 5 - 10 seconds longer to boot up that one I have stripped down to not look for any hardware I don't plan on using. The run time speed is probably negligible, I can't actually measure that reliably. –  Caleb Jun 17 '11 at 21:03

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.

-
+1. Kids these days, they don't even know what 'make menuconfig' means and never had to patch their kernel network code to prevent being pwned by script kiddies. Fortunately those days are mostly gone. –  axel_c Aug 20 '10 at 23:21
you should add bisecting to find where a bug was introduced... –  xenoterracide Aug 22 '10 at 12:10
amazing how this comment is up voted when it has nothing to do with the OP's question. "Most users do not...." c'mon now. OP's question is very clear about wanting to know benefits; not your opinion of what "most users" do here and there. –  Eric Sep 30 '10 at 18:24

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!

-

Bragging rights :)

-
I had a friend that was often bragging about compiling to the latest kernel. I responded that I don't need more reasons to procrastinate; the internet is enough. –  lamcro Sep 25 '10 at 14:24