What's the benefit of compiling kernel modules into the kernel (instead of as loadable modules)?
Benefit of kernel module compiled inside kernel
kernelkernel-modules
Related Solutions
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.
A patch or a git pull request is submitted with a request for comments. This is sometimes done to the kernel mailing list, but is frequently done on other lists pertaining to the subject of the patch first. Sometimes discussion about a proposed module is brought up before any code is even written. People ask why the patch is necessary, state their objections, and point out improvements that could be made. This is an iterative process. When the author is comfortable, he submits it to the Linux kernel mailing list during a time called the merge window.
The moment an official release is made, the opening of the merge window for the next version begins. As part of the closing of the merge window, a patch is either accepted or not. If the patch is accepted, the only further changes to that section of code that are allowed are bug fixes. Also as part of the closing of the merge window, a new RC (release candidate) version of the kernel is released. Almost always, people will have problems with the patch and bugs will need to be fixed or the patch will be reverted.
Best Answer
It depends. If you have a small amount of memory, the use of modules may improve the resume as they are not reloaded every time (I found it significant on 2 GiB of RAM but not on 4 GiB on traditional harddrives). This is especially true when due to some bug in the battery module (regardless of being compiled-in or as module), it took very long to start (several minutes). Even without bug on gentoo I managed to shorten time (reported by
systemd-analysis) from 33s to 18s just by changing from statically compiled kernel to modules - 'surprisingly' the start of kernel changed from 9s to 1.5s.Also, when you don't know what hardware are you going to use, modules are clearly beneficial.
PS. You can compile even vital drivers as modules as long as you include them in initrd. For example, distros will include the filesystem of /, drivers of harddrive etc. in initrd on installation.