LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Anything I can do to make compiling a kernel worthwhile? (https://www.linuxquestions.org/questions/slackware-14/anything-i-can-do-to-make-compiling-a-kernel-worthwhile-4175507801/)

ymf331 06-12-2014 12:08 AM

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?

ReaperX7 06-12-2014 12:12 AM

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.

Arkerless 06-12-2014 12:33 AM

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.

syg00 06-12-2014 12:51 AM

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" .

jtsn 06-12-2014 01:46 AM

Quote:

Originally Posted by Arkerless (Post 5186778)
The slack kernels are well built, it's not easy to best them. (It is fairly easy to do worse in fact.)

Indeed.

@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.

dederon 06-12-2014 03:55 AM

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.

Didier Spaier 06-12-2014 04:04 AM

Quote:

Originally Posted by dederon (Post 5186872)
2. use "make localmodconfig" ("update current config disabling modules not loaded") to remove all unneeded modules from the config.

I'd suggest the localmodconfig target instead then (and don't forget to first run "make oldconfig" against the current .config before), but in any case I agree with jtsn: but in some cases that's not worthwhile.

jtsn 06-12-2014 04:42 AM

Quote:

Originally Posted by dederon (Post 5186872)
actually there is an easy way to build a minimal kernel

1. plug in all devices you will ever need (forcing the kernel to load the modules)

Even the ones, you don't own yet?
Quote:

2. use "make localmodconfig" ("update current config disabling modules not loaded") to remove all unneeded modules from the config.
There are a lot of modules loaded on demand, which aren't related to any device drivers: especially network support (PPP, VPN, packet filters and protocol helpers) and audio/video related (i. e. ALSA/OSS/V4L) and so on. You can't disable these support modules without crippling a lot of important functionality.
Quote:

3. if you like: "make localyesconfig", ("update current config converting local mods to core").
Why, that's a real waste of memory.
Quote:

4. if you did step 3. and you don't use blob drivers like nvidia you can even disable loadable module support now.
That also loses some functionality, which is only available as a module.
Quote:

5. compile & install; will be *much* faster as you have fewer modules to compile.
Indeed, compiling will be much faster, but the result will be inferior to Pat's well-crafted work.

Your description perfectly supports the point I was making.

syg00 06-12-2014 04:52 AM

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.

dederon 06-12-2014 05:04 AM

Quote:

Originally Posted by jtsn (Post 5186894)
Your description perfectly supports the point I was making.

calm down. my intention was to show the thread opener an easy way to bake his own kernel *if he really wants to*.

i almost never bother compiling a kernel by myself, and if i do, i do it for fun, not for performance.

jtsn 06-12-2014 05:23 AM

Quote:

Originally Posted by dederon (Post 5186907)
calm down. my intention was to show the thread opener an easy way to bake his own kernel *if he really wants to*.
i almost never bother compiling a kernel by myself, and if i do, i do it for fun, not for performance.

You have to consider beginners reading threads like these, following the instructions (especially if they are advertised as "easy way") and ending up with a sub-par or non-working configuration. There are enough people out there believing that you must compile a kernel to get a well-working Linux installation due to the community representing the topic from a very narrow point of view.

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.

schmatzler 06-12-2014 05:52 AM

Quote:

Originally Posted by jtsn (Post 5186912)
So if someone doesn't know why he should compile a kernel, he usually doesn't need to.

But if someone just wants to, he should be allowed to do that without being called a dumbass on the internet.

Basically we all are using Linux because we like the freedom it provides us, right? :)

Quote:

There is a even a possibility to damage hardware or firmware by wrong kernel settings.
Teal'c would've said: "That is most unlikely."

jtsn 06-12-2014 06:57 AM

Quote:

Originally Posted by schmatzler (Post 5186919)
he should be allowed to do that without being called a dumbass on the internet

That allegation is unfounded.
Quote:

Teal'c would've said: "That is most unlikely."
That may have been right in 1998. Especially with UEFI, ACPI, NVRAM/flash memory everywhere and software-programmed clock/voltage/fan controllers there are now numerous ways to brick your hardware.

Didier Spaier 06-12-2014 07:07 AM

Quote:

Originally Posted by schmatzler (Post 5186919)
But if someone just wants to, he should be allowed to do that without being called a dumbass on the internet.

Who did that? Please quote the offending post. I couldn't find any statement in this thread that despise the OP in any way

Quote:

Basically we all are using Linux because we like the freedom it provides us, right? :)
THe OP just asked Anything I can do to make compiling a kernel worthwhile? and some of us (me included) answered "no", jtsn stating a rationale to support this answer. How does this restrict the OP's freedom?

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.

moisespedro 06-12-2014 08:24 AM

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.