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.

1 members found this post helpful.

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

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.

4 members found this post helpful.

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.

3 members found this post helpful.

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.

1 members found this post helpful.

Even the ones, you don't own yet?
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.
Why, that's a real waste of memory.
That also loses some functionality, which is only available as a module.
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.

1 members found this post helpful.

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.

1 members found this post helpful.

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.

2 members found this post helpful.

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.

1 members found this post helpful.

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?

Teal'c would've said: "That is most unlikely."

1 members found this post helpful.

That allegation is unfounded.
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.

1 members found this post helpful.

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

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.

4 members found this post helpful.

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)

2 members found this post helpful.