# How to easily trim down kernel?

## nihilo

Does anybody know of an easy way of configuring the kernel (/usr/src/linux/.config) to get rid of unnecessary bloat?

The only way I know of is to `make menuconfig`, turn off a few things, reboot and see if it boots successfully and you can still do what you need to do. Sometimes it won't boot, and you'll have to use a livecd and revert the change you made and recompile, etc. This is way too much of a hassle.

Among the things that are compiled already as modules, you can pretty easily see which ones are used using `lsmod` and `modprobe -l`, but the stuff that is compiled in is much harder.

I'm hoping someone will say "there's this awesome program that you compile as a kernel module, and it monitors over a long period of time what parts of the kernel are not used and tells you which kernel options are not necessary for your machine and usage." Is there such a wonder?

Failing that, is there a faster method than the laborious tweak-reboot method?

----------

## didumos

 *nihilo wrote:*   

> The only way I know of is to `make menuconfig`, turn off a few things, reboot and see if it boots successfully and you can still do what you need to do. Sometimes it won't boot, and you'll have to use a livecd and revert the change you made and recompile, etc. This is way too much of a hassle.

 

I hate to state the obvious here but I always keep a known working kernel image in /boot/ just in-case something goes wrong when tweaking kernel config or upgrading.

As for removing bloat, I do pretty much what you suggested; run a livecd and see what modules are loaded. Good knowledge of your hardware also helps, i.e. having your motherboard manual handy   :Wink: 

----------

## MostAwesomeDude

lspci is your friend.

----------

## nihilo

 *didumos wrote:*   

> I hate to state the obvious here but I always keep a known working kernel image in /boot/ just in-case something goes wrong when tweaking kernel config or upgrading.

 

Yeah, you're right. I do keep a known working kernel image in /boot, but it tends to get out of date pretty quickly.

 *didumos wrote:*   

> As for removing bloat, I do pretty much what you suggested; run a livecd and see what modules are loaded. Good knowledge of your hardware also helps, i.e. having your motherboard manual handy  

 

The livecd won't tell you what is compiled into the kernel unnecessarily though. And even if you know your hardware reasonably well, there is still going to be lots of unnecessary stuff compiled in, because there are plenty of kernel options that don't relate directly to what hardware you have installed.

----------

## nihilo

 *MostAwesomeDude wrote:*   

> lspci is your friend.

 

```
gould ~ # grep -E '^[^#\t ]' </usr/src/linux/.config | wc -l

788

gould ~ # lspci | wc -l

23

gould ~ # 
```

lspci shows 23 items, and my kernel currently has 788 options selected. `lspci` is not much help.

[edit:] Granted, lots of the options are stuff that I want that requires many options (like various netfilter-related options), but even if you know your hardware, it's still difficult to determine whether that hardware requires certain kernel options or not (for the non-trivial cases where the option isn't just for the hardware itself).

----------

## pappy_mcfae

The only way you are going to get to your kernel Nirvana is to do lots of experimenting, and lots of rebooting. My general thought in tweaking kernels is start big, shave down until things stop working, then go back to the previous stage. It's not pretty. It takes a long time. Kernel revisions can start the process all over again.

Tweaking kernels is a learn as you go and trial and error process. The more you do it, the better you get.

Blessed be!

Pappy

----------

## tarpman

If you use make install to install your kernel to /boot, the image you just built will be installed as /boot/vmlinuz, and the one you had before that will be installed as /boot/vmlinuz.old.  That way, if vmlinuz doesn't boot, you can just change the GRUB command line to point at vmlinuz.old and reboot quickly without the hassle of a LiveCD.

----------

## nihilo

@pappy_mcfae: the tweak and reboot is what I was hoping to avoid  :Wink: .  A few years ago on a different machine, I did manage to trim it down to a reasonably minimal configuration, but after installing from scratch on a new machine, I started with the default again, and I don't want to tweak and reboot endlessly again.

I'm still holding out hope that somebody has a better system. If not something like I mentioned that monitors a running kernel, at least a script that automates the tweaking and booting in some kind of a virtual and/or chroot environment so I can use my computer the whole time and not have to spend too much time on it.

@tarpman: I do use make install to install new kernels, and I keep a few extras around including a vmlinuz.standby that is a known good configuration that doesn't get automatically updated. I configured grub to offer the new, the old, and the standby, so I'm actually not too worried about the livecd, despite what I said. I just object to the tediousness of having to reboot again and again and again. There must be a way of automating the process.

----------

## pappy_mcfae

I hope you find one. Since I'm now subscribed to this thread, if a better way shows up, I'll know.

Blessed be!

Pappy

PS. If you read the blurbs that show up while configuring the kernel, the default is usually pretty sufficient, at least I have found. Good luck.

----------

## tarpman

 *nihilo wrote:*   

> @tarpman: I do use make install to install new kernels, and I keep a few extras around including a vmlinuz.standby that is a known good configuration that doesn't get automatically updated. I configured grub to offer the new, the old, and the standby, so I'm actually not too worried about the livecd, despite what I said. I just object to the tediousness of having to reboot again and again and again. There must be a way of automating the process.

 

Ah, ok.  In that case, I'm afraid not; the best way to do it is simply to know exactly what hardware you have, and to make thorough use of the help text.  The good thing is that most of the options don't change very often, so the bulk of the learning only has to be done once.

----------

## depontius

 *MostAwesomeDude wrote:*   

> lspci is your friend.

 

This missing link is a piece of code that looks at the results of lspci, the currently running kernel, maybe asks a few questions, and generates a new kernel config.  Since it's such an obvious thing to do, and it hasn't been done yet, I'll presume that it's a real quagmire to implement.

----------

## Etal

Interesting... Since I first compiled my kernel 3 years ago, I got an unbootable kernel no more than once or twice on the three computers for which I built kernels...

Generally, my strategy is that I figure out what my hardware is (using lspci, mostly), and then I go through every option in menuconfig, and press H for a description. Then I ask myself, "Do I know what this is? Do I need this?" If I do know what it is, and I need it, I check it on. If it talks about some hardware which I don't have, I check it off. If I don't know what it is, I see if there is a recommendation, usually "You should probably set it to 'Y' unless you know what you're doing" or "If you don't know what this is, set it to 'N'". If it does not have a recommendation, I do a quick Google search and if nothing interesting comes up, I turn it off, unless it looks "important," in which case I leave it as-is.

My kernel is 2.1M on a laptop, btw, with everything except nvidia and wireless driver built-in.

----------

## Link31

```
lspci -v
```

can tell you which kernel drivers are currently used.

Then you can remove all the others drivers from your .config.

The others options, like the ones located in "Processor type and features", are often optimizations and are really up to you. Don't worry, the Kbuild system will prevent you to remove options required for the selected hardware drivers.

----------

## nihilo

 *AM088 wrote:*   

> ... if nothing interesting comes up, I turn it off, unless it looks "important," in which case I leave it as-is....

 

My intuition that prompted this question is that there's lots of stuff that "looks important", isn't obviously related to any particular hardware, but is unnecessary (aka BLOAT).

----------

## nihilo

 *Link31 wrote:*   

> 
> 
> ```
> lspci -v
> ```
> ...

 

THANKS! I've used lspci for many years but didn't realize the kernel information was in the verbose output. That's really helpful. I noted there's also -vv and -vvv which give even more output, but -v looks like the sweet spot.

I should probably browse the man pages more for programs that I use all the time, as I'm no doubt missing similar goodness with other programs too.

----------

## Etal

 *Link31 wrote:*   

> 
> 
> ```
> lspci -v
> ```
> ...

 Wow, I never knew that either!  :Smile: 

 *nihilo wrote:*   

> My intuition that prompted this question is that there's lots of stuff that "looks important", isn't obviously related to any particular hardware, but is unnecessary (aka BLOAT).

 

Could you give some examples of what looks important to you? Also, how small did you get your kernel?

----------

## nihilo

 *AM088 wrote:*   

> Could you give some examples of what looks important to you? Also, how small did you get your kernel?

 

My current kernel is quite bloated, because I started with the default and added what I thought I needed for my hardware. The last time I really tried to trim one down was a few years ago, and I don't remember how small it ended up being.

I just went through the first part of my config quickly looking for possible things to turn off, and here are a couple of candidates:

Message Signaled Interrupts (MSI and MSI-X) (PCI_MSI)

This allows device drivers to enable MSI (Message Signaled

Interrupts). Message Signaled Interrupts enable a device to

generate an interrupt using an inbound Memory Write on its

PCI bus instead of asserting a device IRQ pin.

Use of PCI MSI interrupts can be disabled at kernel boot time

by using the 'pci=nomsi' option. This disables MSI for the

entire system.

If you don't know what to do here, say N.

dmesg contains "assign_interrupt_mode Found MSI capability", which I think is referring to this, so I'm guessing this is being used. Is it required? If not, is it of benefit? I'm not sure, and it would take time to find out. I sure wish an automated tool would figure it out for me.

Interrupts on hypertransport devices (HT_IRQ)

This allows native hypertransport devices to use interrupts.

If unsure say Y.

My CPU is Intel, not AMD, but I do have an NVIDIA graphics card, and it seems some of those use hypertransport. My card is GeForce 7600 GT, using the nvidia kernel module. Based on http://en.wikipedia.org/wiki/Hypertransport, this card isn't one of the ones that uses hypertransport, but I'm not 100% sure.

----------

## eccerr0r

There's a lot of speed/size/functionality tradeoffs too, to consider.  An easy one is the full USB HID driver or use the boot-protocol USB HID driver.  There are others... I wonder if the EIDE driver or the libATA driver is smaller?

Speaking of bloat, I doubt a 300K kernel is possible anymore  :Sad:   Or is it?

Just recalling the olden days a 1.44M boot floppy can contain a zImage kernel, and uncompressed rootfs with regular libc and utils...  It was cramped, but it fit.

I normally just build the kernel and not care too much about bloat.  Yes, my computers' kernel images vary from 1MB to 4MB with another 20+ MB of kernel modules (I typically build a lot of the USB modules and other insertable kernel modules, just in case)...

----------

## MostAwesomeDude

"linux msi" in Google found this: http://lwn.net/Articles/44139/

----------

## depontius

In addition to speed/size/functionality, there is also value to "staying mainstream".  The more mainstream features will have more kernel developers, more eyeballs paying attention.  More varieties of hardware and software will be run against more mainstream kernels, and things are more likely to be well bugged out.  That's the main reason I use primarily ext3, because I know it's got their attention, and their data is stored on it, though I do use xfs for MythTV media, etc.

Another place for this thinking is the EIDE / libATA issue you mention.  The kernel devs hate the EIDE drivers because they think it's ugly, crufty, uncleanable code.  Their attention is on "doing it right" with libATA.  There is a hardware-dependent crossover point where libATA becomes good enough for you to use.  Once it's there for your hardware, it will be your best path forward, again because it's got the kernel developers' attention.

Every now and then I try to strip my kernel and modules down, if only to shorten build time.  Most of the time I just copy the old config into the new sources, tweak what's necessary, and go.  With this methodology the kernel will grow with time, because often new drivers are on by default, and my old config won't turn them off because the keyword didn't exist.

----------

## Etal

 *nihilo wrote:*   

> Interrupts on hypertransport devices (HT_IRQ)
> 
> My CPU is Intel, not AMD, but I do have an NVIDIA graphics card, and it seems some of those use hypertransport. My card is GeForce 7600 GT, using the nvidia kernel module. Based on http://en.wikipedia.org/wiki/Hypertransport, this card isn't one of the ones that uses hypertransport, but I'm not 100% sure.

 

If I understand it correctly, HyperTransport is used on the motherboard chipset, not the graphics card. So, unless your your motherboard has NVIDIA nForce chips (not related to graphics at all), or an AMD64 processor, you don't have HyperTransport. If there's no nForce (4 or greater) entries in your lspci, you may disable it.

----------

## Carnildo

 *eccerr0r wrote:*   

> Speaking of bloat, I doubt a 300K kernel is possible anymore   Or is it?

 

I don't know about 300k, but I've got a web/mail/ssh/fileserver running a 750k non-modular kernel.

----------

## IRQsRFun

Quoting depontius

 *Quote:*   

> 
> 
> ..
> 
> Every now and then I try to strip my kernel and modules down, if only to shorten build time. Most of the time I just copy the old config into the new sources, tweak what's necessary, and go. With this methodology the kernel will grow with time, because often new drivers are on by default, and my old config won't turn them off because the keyword didn't exist.
> ...

 

It is good to know that this is the behavior of the build scripts.  I typically use "make oldconfig" so that I am asked whether or not to build in new modules or built in functionality.  A graphical version of "make oldconfig" combined with one of the graphical makes like "make menuconfig"  may be interesting, but I do not currently conceive of  an obvious simple GUI.

----------

## Mad Merlin

 *nihilo wrote:*   

>  *didumos wrote:*   I hate to state the obvious here but I always keep a known working kernel image in /boot/ just in-case something goes wrong when tweaking kernel config or upgrading. 
> 
> Yeah, you're right. I do keep a known working kernel image in /boot, but it tends to get out of date pretty quickly.

 

There's no reason not to keep all of your previous kernels around, that's what I do. When I compile a new kernel, I just add it to the top of grub.conf. One of my older systems has kernels from 2.6.11 through 2.6.24 in /boot.

----------

## depontius

 *Mad Merlin wrote:*   

>  *nihilo wrote:*    *didumos wrote:*   I hate to state the obvious here but I always keep a known working kernel image in /boot/ just in-case something goes wrong when tweaking kernel config or upgrading. 
> 
> Yeah, you're right. I do keep a known working kernel image in /boot, but it tends to get out of date pretty quickly. 
> 
> There's no reason not to keep all of your previous kernels around, that's what I do. When I compile a new kernel, I just add it to the top of grub.conf. One of my older systems has kernels from 2.6.11 through 2.6.24 in /boot.

 

Disk space.  I frequently keep /boot and / both fairly small.  Kernels aren't that big, but especially if you don't keep the configuration trimmed, /lib/modules/2.6.xx.yy can add up.  Maybe I should just give in and buy more modern disks, instead of keeping and recycling everything until it dies.  Well, a drive smaller than 8.5G just isn't worth occupying a socked on an IDE cable.  Some might question the wisdom of so small a number, there.

----------

## RedSquirrel

 *Mad Merlin wrote:*   

> There's no reason not to keep all of your previous kernels around, that's what I do. When I compile a new kernel, I just add it to the top of grub.conf. One of my older systems has kernels from 2.6.11 through 2.6.24 in /boot.

 

Security/bug fixes might be something to consider with regard to older kernels. I generally keep the most recent one and its immediate predecessor.

----------

## Mad Merlin

 *depontius wrote:*   

>  *Mad Merlin wrote:*    *nihilo wrote:*    *didumos wrote:*   I hate to state the obvious here but I always keep a known working kernel image in /boot/ just in-case something goes wrong when tweaking kernel config or upgrading. 
> 
> Yeah, you're right. I do keep a known working kernel image in /boot, but it tends to get out of date pretty quickly. 
> 
> There's no reason not to keep all of your previous kernels around, that's what I do. When I compile a new kernel, I just add it to the top of grub.conf. One of my older systems has kernels from 2.6.11 through 2.6.24 in /boot. 
> ...

 

Well, for me at least, each kernel has about 12M of modules. 12M is a pretty trivial amount of space, even on my smallest working drive (30G), especially considering that none of my machines have more than 9 kernels + modules saved... Realistically I don't ever expect to run an older kernel again, I'm just a packrat.

----------

## benny1967

As stated before, the kernel options that obviously refer to some hardware ("...support for Kenwood blenders? [Y/n]") are simple and usually are not the problem when trying to slim down a kernel.

There are other option, though, that I simply don't understand (even though I do read the help texts) and therefore don't feel comfortable to change.

Can any of you recommend a site that explains all kernel options really well (like: what does it do? who would typically want to use it? any common applications that depend on it? typical use cases? situations in which you are absolutely safe to turn it off? ...?)? Reading such a documentation would be better than trial/error...

----------

## migol

kexec can also help you

----------

## asturm

 *pappy_mcfae wrote:*   

> My general thought in tweaking kernels is start big, shave down until things stop working, then go back to the previous stage. It's not pretty. It takes a long time. Kernel revisions can start the process all over again.

 

Imo that's redundant work. You only 'start big' with your very first kernel because things are pre-selected, then strip it down to your needs, and keep your .config until you or your system stop working. make oldconfig does the trick, and the occassional revision via menuconfig.

Hint: modularisation (because you then see which modules actually fail inserting or do nothing) and reading built-in information helps, <insert-search-engine-of-choice>ing kernel options too.

Writing this from a 1.83mb amd64-kernel.

Disk space can also be of concern on 1TB+ drives if you keep a separate 32M ext2 /boot partition.

----------

## Carnildo

 *Carnildo wrote:*   

>  *eccerr0r wrote:*   Speaking of bloat, I doubt a 300K kernel is possible anymore   Or is it? 
> 
> I don't know about 300k, but I've got a web/mail/ssh/fileserver running a 750k non-modular kernel.

 

Not 300k, but close: a minimal 2.4.36 kernel to boot my webserver as a functional computer is 390k.  570k if I want it to actually be useful as a webserver.  For selecting what to enable, I read the help for each option that sounds important, and if I still can't decide, I search Google.

----------

## pappy_mcfae

 *Quote:*   

> Imo that's redundant work. You only 'start big' with your very first kernel because things are pre-selected, then strip it down to your needs, and keep your .config until you or your system stop working. make oldconfig does the trick, and the occassional revision via menuconfig.

 

No kidding. The config that runs this machine has existed since I worked with Slackware. It has changed in many ways. And no, I don't start over every time I set up a kernel. I'm not that ambitious. I simply move the .config to the newest source and issue my script command that lets me do it all to the new source: oldconfig, xconfig, make, make modules_install.

So, you misunderstood. I probably was less than clear on my point. For that, I apologize.

Blessed be!

Pappy

----------

