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.

  • There no point in having a slimmer kernel for that laptop, unless you have a specific reason. You will almost definitely not gain any performance by doing so. Since the kernel is modular anyway, if you are doing this for "performance" reasons, my advice would be not to bother, you won't see any increase in performance. Even if it wasn't modular, you wouldn't really see any increase in performance (only in boot-time, but that would be minimal anyway). You'll spend more time doing this than you'll get out of increased speed (which will be negligible).
    – Chris Down
    Nov 6, 2011 at 14:23
  • I understand that. My objective is just to see how far I can strip down the fat. Perhaps by studying how much stuff a normal user can throw out, we can help users with slower laptops? Nov 6, 2011 at 14:37
  • 3
    Even on slower laptops, the only place you will see a benefit is in boot time.
    – Chris Down
    Nov 6, 2011 at 14:39
  • 4
    I agree with Chris, this will be premature optimization at best. The kernel is only a few megs and you won't be able to pare out more than a few dozen k without sacrificing usability. Since you tagged this ubuntu, I'll suggest you use a slimmer distro, you'll gain a great deal more space. I suggest Archlinux if you don't want to compile everything, gentoo if you do, and Linux from scratch if you really want to learn about compiling and have a few days to spare.
    – Kevin
    Nov 6, 2011 at 14:43
  • I've done this on memory constrained systems (by "memory constrained" I mean 64-128 MB of RAM (and yeah, I booted linux on a 16 MB system once without a GUI and with a 1.2 series kernel)), though as others have mentioned most of it is modular, so you can't gain a lot. But long before I got around to chopping down the kernel I'd ditched the fancy desktop environment in favor of a lightweight window manager, replaced heavy terminals with rxvt and so on. Nov 6, 2011 at 19:44

4 Answers 4


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, …).


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.


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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.