Linux in Government: Optimizing Desktop Performance, Part I

Actually, very few general purpose Linux distributions use kernel.org stock kernels, and this has been the case for a long time. Execute 'uname -a' and you will see some distro-specific suffix on your kernel image that designates the patchset used.

On a similar note, not all 2.6.x kernels will export this vm control to the /proc interface. In general, the vm.swappiness variable is a control unique to the "O(1)" process scheduler used by default in the vanilla 2.6.x kernel. Readers should be aware that this is not the only option, and I will give some plugs to some of my favorite patchsets specifically crafted for desktop use:

ck: my favorite for mainstream desktop workloads, this patchset used Con Kolivas' Staircase process scheduler, which is designed to reduce latency in a concise and understandable manner. Read the website for more details, including its simple /proc variables:

http://members.optusnet.com.au/ckolivas/kernel/

cko: just like ck, but for those who can't sleep at night unless their kernel is dripping blood on the edges. This is what I use, because the Staircase + Reiser4 combo makes my Inspiron 500m sing. Also has vesa-tng framebuffer, Inotify kernelspace message passing, and the latest ALSA drivers built in. Also try the split-off Software Suspend 2 patch for cko, which allows for a suspend that resembles what Microsoft calls Hibernate.

http://kem.p.lodz.pl/~peter/cko/

nitro: similar to cko, but with genetic scheduling and some other goodies, and it's available as an ebuild for Gentoo.

love: Lovechild has his own ideas about low-latency linux kernels, based on Ingo Molnar's real-time preemption and Completely Fair Queing. In particular, he doesn't like Reiser4 for interactivity, and instead recommends a tweaked version of ext3:

http://forums.gentoo.org/viewtopic-t-333756-highlight-lovesources.html

I hope this was a useful introduction to desktop linux performance issues, and highlights the massive body of work that is being done to implement and test next-generation code that will speed-up desktop linux. It all starts with the kernel, and any multi-part guide to getting the most out of your desktop linux should start with picking a filesystem and picking a kernel source tree to work with. The differences can be night and day.

Of course, it is very easy to compile a kernel that will not boot or work correctly with your existing Linux system. If you don't know if your system uses devfs or udev, or what filesystem(s) your system lives on, or how to load a kernel module, then this guide will be a little over your head. If you want to learn about kernel configuration, check out what you're running on now:

# cd /usr/src/linux
# make menuconfig

Good luck!!