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

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.

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.

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.

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.

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.

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.

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

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.

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.

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)

3.10.17 is getting a little long in the tooth. IMO it is worthwhile building the latest 3.10.y kernel, even if you build it using Pat's stock 'generic' kernel config file and make no other changes to it. I'm not suggesting one should build every 3.10.y that comes along, but I believe it prudent to catch-up every once in a while.

Thanks for all the replies. And yeah, I'm only really messing around for educational purposes.

I'll accept something like 'not particularly' as a solution here. I'll probably play with kernels still. Nothing will come from sitting around on my desktop waiting to be an expert, right? :)

Check out AlienBOB's wiki on how to build the kernel. I always just do some minor changes like Preemption model. I change it to Desktop. I've also started disabling the kernel debug as it could potentially make your kernel faster, but I don't have any concrete numbers to back that up.

A generic kernel is fine, and Pat's is top-notch....HOWEVER as he states, he does not impose his views by assuming he knows what users wish to do with their PCs. If you are building a DAW, or even merely heavily involved with multimedia, including gaming, there is very definitely advantage to be had in creating a low-latency and/or realtime kernel. "Huge" and "Generic" in Slackware's case are not just cute names, but rather functionally descriptive. Choose according to your taste, jobs, and skillset. "One man's meat......"

This may be useful:
http://docs.slackware.com/howtos:sla...git_repository

A "localmodconfig" kernel can be a pain in the arse, especially when introducing new devices. Unless you're really low on RAM building smaller kernels has little benefit. (being faster to build is the greatest benefit IMO)

localyesconfig kernels can be a bugger to get working on some hardware - I've always had trouble with framebuffer/display devices.

I've also had USB HID problems with both types of kernel and had to use an initrd anyway (no idea why).

I like the generic kernel and just base my kernels off that one with minimal changes.
It's good to experiment though.

I update my kernel regularly, so I need it to be stripped down. It's not that difficult, but is time-consuming. I'm not gonna stop doing just because of that tho. I set aside a few hours and do it once per system and maybe a bit when changing major kernel versions.

I update my kernel with each release,.. but it isn't time consuming anymore. I mean, I use the previous settings from the previous kernel, then look at the new CONFIG options and enable or ignore them.

The original config took a long time, but each new config might take me 10m to fly through.

You can get a well-working Linux install without compiling your own kernel. You can get an excellent-working Linux install only by compiling your own kernel.

It is an advanced task, but you don't necessarily need to know exactly what you are doing, you can get by with just having an idea of what you are doing without knowing in-depth. Although damaging your hardware cannot be excluded for legal disclaimer purposes, it is very rare. I've been compiling my own kernels for years, initially not knowing exactly what I was doing, and never had any hardware issues due to this.

It is a learning process, and fear is what keeps most people from learning (more than just computers). I have no fear, and I have learned a lot. The more you learn/understand the less you fear. If you don't face your fears and dive in, you'll be doomed to a life of fear and ignorance. Definitely worth it to dive in and learn.

EDIT:
It would be worthwhile to know how to recover the system in case the kernel doesn't boot. You should probably keep a known good kernel around and have a boot entry for it. If you forgot to do that, you can always boot the Slackware install disk, install the kernel and configure lilo, NO need for full re-install.

Indeed.

He he yeah. I get most of this and, while I do have regular questions, the links are almost always what's guiding me through whatever process when I ask. I planned on sticking to -current, and was trying to devise a reasonable way to keep from screwing up my boot beyond my ability to mount/repair. Experience has been a great teacher, but mostly I've learned how much trouble it all is. That aside, I haven't been completely wowed by the recent version of someapp since I've been at it. I think that I figured out what I needed to know. Stick with the stable upgrades and go through it annually or some such.