Stripped down Kernel for a Laptop

Question

I am a Linux noob, but I am willing to learn. My immediate objective is to compile a small kernel for my laptop without sacrificing usability. I am familiar with the kernel compilation steps (don't necessarily understand the process). What are the options I can get rid of in menuconfig for a faster, slimmer kernel? I have been using the trial and error method, i.e uncheck unused filesystems and drivers, but this is a painfully slow process. Can somebody point me towards things I should not touch or a better way of going about this process? This little "project" is for recreation only.

System Specs and OS:
i7 580M, Radeon HD5850, 8Gb DDR3, MSI Motherboard x86_64 Ubuntu 11.10.

Answer 1

Unchecking filesystems and drivers isn't going to reduce the size of the kernel at all, because they are compiled as modules and only the modules that correspond to hardware that you have are loaded.

There are a few features of the kernel that can't be compiled as modules and that you might not be using. Start with Ubuntu's .config, then look through the ones that are compiled in the kernel (y, not m). If you don't understand what a feature is for, leave it alone.

Most of the kernel's optional features are optional because you might not want them on an embedded system. Embedded systems have two characteristics: they're small, so not wasting memory on unused code is important, and they have a dedicated purpose, so there are many features that you know you aren't going to need. A PC is a general-purpose device, where you tend to connect lots of third-party hardware and run lots of third-party software. You can't really tell in advance that you're never going to need this or that feature. Mostly, what you'll be able to do without is support for CPU types other than yours and workarounds for bugs in chipsets that you don't have (what few aren't compiled as modules). If you compile a 64-bit kernel, there won't be a lot of those, not nearly as many as a 32-bit x86 kernel where there's quite a bit of historical baggage.

In any case, you are not going to gain anything significant. With 8GB of memory, the memory used by the kernel is negligible.

If you really want to play around with kernels and other stuff, I suggest getting a hobbyist or utility embedded board (BeagleBoard, Gumstix, SheevaPlug, …).

Answer 2

Slimming down the kernel is not going to result in any noticeable gain. The time would be better spent trimming down userspace applications.

To see how quickly the kernel comes up and how much memory a very bare system uses, you can load up just a pure shell. To do this, reboot the computer and stop grub. Edit the entry that would normally boot (it should already be highlighted, and it's usually 'e' to edit it) and find the line that starts with "linux". This line lets you give the kernel some parameters. Add to the end of that line "init=/bin/sh", then boot your edited entry (there will probably be on-screen instructions for how to do that).

It should boot pretty rapidly. Once it's up, you can use free to see how much memory is available.

You might also want to take a look at bootchart, which gives you information about what processes are doing as they boot.

Answer 3

I complete disagree with all the answers given here. Compiling your own kernel will give you a faster system overall, and faster boot times are very apreciated in laptops systems. It matters. It's just that if you want a custom kernel, you will have to work for it. And not all of the people are willing to do that. If you don't have problems with taking the time to learn how to do it, then it's the perfect solution for you.

About the .config step, an easy trick is to start with your current working kernel .config and start stripping from there incrementally as your understanding of the options increase. Just do "make menuconfig" go to the bottom and select "load an alternate config file", then find the current kernel .config from there (cat /proc/config.gz > .config-current for easy finding).

Answer 4

Stripping out a kernel is not likely to matter on any modern PC. The few megabytes you can save will be neither here nor there. Kernel tuning was relevant in the days of a VAX 11/750 where you genuinely might only have had a machine with 1-2MB of RAM. Tuning buffer pools, process table size and suchlike did involve making significant tradeoffs against machine RAM on a machine that small, so there was a time where it got a sort of mythical status as something a 'unix guru' should understand.

Realistically, any PC made in the last 15 years probably has enough memory for this not to matter.