Anything I can do to make compiling a kernel worthwhile?
In an effort to stop needing to make an initrd, I downloaded the kernel source and the newest config, built in ext4 and jbd2, and watched while my computer slowly made all the modules. It seems like a good thing to know, but for all the extra effort I'd be happy to keep my initrd and rock the generic kernels. Anything more I can do like slimming it down or basically anything to make it worth my time? Frankly, looking through the menuconfig I didn't know if I needed any of the options or not. Is there a way to find out or tell where I can hack large chunks out for a minor performance increase?
|
I've learned to look at the hardware lists and disable any drivers you don't use or need. After you trim enough out you should be okay. Just archive your config well.
|
The slack kernels are well built, it's not easy to best them. (It is fairly easy to do worse in fact.)
If you are trying to pull out a performance gain, you really have to look at your hardware in some depth. As Reaper said, you can start by disabling any drivers you dont need. The only time this will hurt is if you change hardware, remember to leave the huge kernel as a boot option so you dont brick your box! But it's unlikely to result in much of a performance gain. It will reduce the memory footprint a little, which cant hurt, and in an edge case might really help. Profiling your use would help. Improving performance is mostly about greasing bottlenecks, so you need to know where the bottlenecks are. I've seen significant improvements from *disabling* compiler optimizations aside from size, and I have seen the same treatment reduce performance on another machine. Optimizing for size can really help if it makes the difference between a common routine fitting in cpu cache or not, for example, or on a machine that is starved for memory, or one where the particular thing you are optimizing gets loaded and unloaded often and the I/O bandwidth bottlenecks, and so forth. In other cases it might actually slow you down though. If you really want to hot rod and dont mind to put in a lot of time for a small game I would suggest working out a cross-tab of possibilities and compiling each one, then benchmarking them as realistically as possible and tabulating the results. |
This a continuation of your UEFI adventure ?.
Building kernels takes time - no way out of that (I once - only once - did one on an Atom). But for custom kernels you shouldn't need any (or very few) modules. Saves a bunch of time - especially from a normal Slack config. Have a look at the build target "localyesconfig" . |
Quote:
@ymf331 If you wan't to get rid of initrd, just use the Slackware default installation (huge) kernel. There is no need of disabling modularized drivers, because udev won't load them anyway. Nowadays there are only a few reasons for recompiling a Slackware kernel: 1. Optimize it for an exotic CPU architecture (non-Intel, non-AMD) 2. Change a single configuration option, which isn't runtime configurable (PAE, APM, some debugging options etc.) In neither of these cases it is required, that you go through the entire configuration. Just load the Slackware huge or generic .config into menuconfig, change the one configuration option and rebuild the thing. If your machine runs fine, there is no point in bothering with kernel compilation. |
actually there is an easy way to build a minimal kernel, which makes the effort worthwhile:
1. plug in all devices you will ever need (forcing the kernel to load the modules) 2. use "make localmodconfig" ("update current config disabling modules not loaded") to remove all unneeded modules from the config. 3. if you like: "make localyesconfig", ("update current config converting local mods to core"). 4. if you did step 3. and you don't use blob drivers like nvidia you can even disable loadable module support now. 5. compile & install; will be *much* faster as you have fewer modules to compile. |
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Your description perfectly supports the point I was making. |
Rubbish.
I've never had one of my custom (Slack) kernels that wasn't smaller and faster (in all senses of the word) than the shipped kernels. Not knocking the team - generic builds are exactly that, and need to be. Every distro provides them, even gentoo. Custom builds are another matter - they won't work on someone elses machine, but aren't intended to. |
Quote:
i almost never bother compiling a kernel by myself, and if i do, i do it for fun, not for performance. |
Quote:
Creating custom kernels is an advanced task for people, who exactly know what they are doing. There is a even a possibility to damage hardware or firmware by wrong kernel settings. So if someone doesn't know why he should compile a kernel, he usually doesn't need to. |
Quote:
Basically we all are using Linux because we like the freedom it provides us, right? :) Quote:
|
Quote:
Quote:
|
Quote:
Quote:
In addition, the OP didn't ask "How can I make a custom kernel" and rightly so as this information is easily found in many places, including this forum, AlienBOB's blog and SlackDocs. PS jtsn answered while I was typing. I of course agree with what he said. |
Compiling a custom kernel is fairly easy:
- Download the source and unpack it - make mrproper - Select everything you need It took me a few attempts but then I got all sorted out (did this on Gentoo, LFS and Slackware) |
All times are GMT -5. The time now is 10:09 AM. |