I have compiled my own kernels for a while now. I started when I got my i7 processor and wanted its turbo boost to work properly. I've since bought an SSD so continue to benefit from a more recent kernel than the repo version.
With my most recent builds, I've started getting weird CPU spikes. While it could be a number of different things causing this, I'd like to focus on getting the kernel "right" and if possible, more optimised than ever.
I follow the "Old-Fashioned Debian" on the Kernel/Compile wiki. I do this because I'm building from a direct download from kernel.org. First questions: Should I get my source from somewhere else and should I use a different build method?
The guide suggests getting the current .config like so:
cp -vi /boot/config-`uname -r` .configThis is all well and good if your current configuration works well but I'm concerned mine contains a problem... Second question: Is there a good Ubuntu-friendly, i7-friendly default .config file I can download from somewhere?
There are a lot of kernel patches floating around at the moment. Some promise a more responsive system through patching IO bugs, some give "better" schedulers (BFS, et al) but it's hard to find decent benchmarks to see if these are worthwhile features of if they're just unstable junk. Third: Are there any patches you would apply to 2.6.35 to make it more compatible with Lucid?
I fear it's make menuconfig where I screw things up. I try to turn off drivers I don't need and select options that look like they'll optimise things but, truth be told, I'm not a kernel developer; I don't know for certain if an option will break everything or even help at all. Fourth: How would you optimise the .config/build-process for an i7 and SSD?
3 Answers
From my point of view kernel.org is the right place to get a kernel. Usually I clone the git repository from mainline. Maybe you could also use a recent vanilla kernel and apply the patches from Ubuntu. You'll find the diff at the linux-image package page. Be aware that there could be some conflicts which you have to resolve. So the first version is probably better.
I guess you wouldn't find any good .config in the wild. What I find helpful is make localmodconfig in the kernel source. First you copy your old config to /usr/src/linux-2.6 (or the place where your kernel sources are) and then you execute this command. It will disable all module which are not loaded. So you gain more customization in the first place.
I'm not aware of any patches which are good for Lucid.
I'm a member of a local LUG. We make from time to time kernel workshops. Here all members meet. We configure a kernel and talk about our knowledge of different entries. In the end all profit from it and this helps to build better kernels. So if I look for optimisation I would ask our members. If that is not an option, reading the Linux Kernel mailing list could also help to find a solution. You'll find often some discussion which are helpful.
1There is a mainline kernel PPA:
Unless you are trying to resolve a specific problem (that you experience with an Ubuntu stock ekernel) ou you are trying to use a specific feature/option not available on Ubuntu's kernel you will probably just be wasting your time.
If you do have a problem with your current kernel please file a bug report at launchpad.
4You don't mention which kernel version you are building. Because you've asked about patches to Lucid I'm going to assume that's what you are trying to tweak.
My suggestion is to not waste your time. The Ubuntu Kernel team applies all the patches that are released by the upstream stable release team to Lucid (and other releases as well). You might be able to get a little more performance from the kernel by hand tweaking configuration parameters but you'd have to spend a lot more time trying to measure the improvement if there really is one. You'd be much better off staying on a stock kernel and picking up the patched kernels from Ubuntu. These patches can contain performance improvements as bugs are found and fixed.
The reason you may be seeing CPU spikes may be due to some kernel bugs that have been recently been fixed upstream and the patches are working their way into Lucid right now.
Once you start building your own kernel, you are now assuming the responsibility for keeping it patched and rebuilt. That's what Canonical pays people to do so you don't have to. Your really do have better things to do with your time.
2
