Linux in Government: Optimizing Desktop Performance, Part I

A new series offering tips and tweaks to speed up your Linux desktop performance.

In his article, "Linux for Suits: The No-Party System", Doc Searls makes an observation about Linux that can help us understand why we might want to tweak the performance of Linux desktops. Referring to Linux as raw material with which people can build distributions, he says:

As one Linux programmer once told me, "Linux can't sue anybody." In fact, Linux isn't even a platform of the sort defined by Windows and Mac OS. Instead, Linux is a form of building material that grows in the wild and naturally is suited for making foundations and frameworks. The wild in this case is fertile human mentation, which is why it evolves and improves in the course of being put to use.

People distribute Linux rather than build it. Unlike traditional operating systems, anyone with some knowledge of Linux can pull the pieces together and create a distribution. So, although many different distributions of Linux are available, they come from the same building materials. The differences among distributions take the form of tweaks here and there or various ways in which users perform the same tasks and what kind of themes are used. But as many have said, "Linux is Linux"--and it has flavors. Distributors create those flavors, and underlying these flavors are default configurations.

For most of its existence, people have distributed Linux as a workstation or a server rather than as a desktop. In effect, the default workstation that has evolved has existed mostly for developers. So, when you install a Linux distribution with a graphical interface, it generally looks like what a developer might want. It performs similar to many UNIX workstations, which can seem slow for many knowledge workers.

In this article, we look at the Linux desktop in a slightly different light. We think of it as a computer system that maximizes its strength as a consumer product. When we optimize Linux for the consumer, it becomes a fast interface.

If you have complained about the speed of or Firefox or about the amount of time Linux takes to boot up, this set of optimizations should change your perception. Linux can boot up quickly, the word processor can spring open and the browser can fly. So, let's make these adjustments so your computer can fly.

Note: We use the two most popular Linux distributions for this article, Fedora Core 3 and Ubuntu 5.04. Red Hat builds and releases Fedora using an RPM-based package management system. The Ubuntu developers base their distribution on the deb package management system. Mandriva, SUSE and Red Hat Enterprise Linux, among others, use the RPM package management systems. Linspire and Xandros, among others, use the deb package management system.

Where the Speed Goes

Many points exist in a PC where an operating system can bottleneck and slow down. One of the most common places for this to happen lies between random access memory (RAM) and the hard drive. Even if your system does have an ample supply of fast RAM, it might decide to conserve it and use virtual disk memory, which is contained in the swap file on the hard drive. The hard drive runs 100 times slower than RAM, so that's one place system speed goes.

You can fix this problem with system speed by adding more RAM. A few years ago, I often bought computers and added memory that doubled and tripled the price of the base system. I had to do this because as a writer I used graphics programs, and they used a lot of RAM. Fortunately, RAM doesn't cost much any more. You can buy a 1GB stick of generic RAM for most desktop computers for about $150. If you use a laptop, the memory costs more. Still, the increased performance of your computer makes the cost seem insignificant.

If you have enough RAM available, Linux uses that instead of the hard drive. In Figure 1, you can see a screenshot of Fedora's performance monitor on a system containing 768MB of RAM. Notice in a couple of places how the CPU jumped up while the memory remained steady. The monitored system is an AMD Sempron 2200 with a 1.5GHz processor. This system came from the Micro Center with 256MB of RAM and sells for approximately $250. It's a PowerSpec SBB1. I added 512MB of memory for $70.

Figure 1. Fedora's System Monitor

To keep this system from immediately accessing the swap drive, I utilized one of the features of the Linux kernel and reduced its propensity for immediately looking for the swap file. People call this kernel aspect swappiness. It's a run-time tunable available through the proc interface for anyone needing to adapt kernel behavior to his or her own requirements.

The higher the parameter, the more the computer uses the disk. So, if you compile a large piece of software, you might want to use RAM for other things while you let the computer sit and compile. But, if you want to write a proposal and need to get to the Internet to do research, answer e-mail and use instant messaging, you probably want to use RAM instead of the disk.

On my system, I reduced the tendency for the kernel to use the swap file. I did so by running this command:

$ sudo cat /proc/sys/vm/swappiness 

and found the setting at 60. That's the default set by the kernel developers. I wanted a lower number, so I ran:

$ sudo sysctl -w vm.swappiness=10 

and ran the cat command again and it registered 10. I added

vm.swappiness=10 to /etc/sysctl.conf 

I put this on the last line. No comments existed for that entry, so it looks naked in the configuration file. I noted an immediate improvement in responsiveness, and with the entry in /etc/sysctl.conf, the system booted up with the value of 10 as the new default.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Uh... yeah.

Anonymous's picture

Just like it is in every other distro. They all use the same base kernel, you know.

Start from the beginning...

butters's picture

Actually, very few general purpose Linux distributions use 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:

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.

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:

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!!


Matthew Miller's picture

I think the poster is referring to the apparent typo in the article, where it says "/proc/sys/vm/swappinessd".


Tom's picture

Hope to have that fixed soon.


Anonymous's picture

fixed - huh.

If you wanted OOo to be reall

Anonymous's picture

If you wanted OOo to be really fast, you could store it on a RamDisk. Such is the power of Linux :)

The problem with this, as it

Anonymous's picture

The problem with this, as it touched on earlier in this thread, is that allocating memory to a ramdisk is sometimes silly. It just means that everything else in the system will has less physical ram to play with. i.e. the swap will be used more often. The operating system should decide which files are being used and cache them - it can almost certainly do a better job than you can.

load OO into the RAM...

Michael Bischof's picture


I would be very curious to learn how exactly (=> details !) you would achieve that !


Michael Bischof

I'd rather have a "swappy" desktop system

Anonymous's picture

When I'm "multitasking" in the human sense of the word, sometimes I have a big graphic open in the GIMP, and I need to compile something.

If the kernel was willing to be "swappier" it would take all those pixels I wasn't working on at the time, and park them on disk while using RAM for disk buffers to make the compile faster.

How to tell if the system is swapping too much:

It does do this. Just not in

Anonymous's picture

It does do this. Just not instantly. Imagine if as soon as you started to compile it immediately swapped out everything else. What if you decided you wanted to edit your image again, and it then had to swap it back in. What this thread is about is building a responsive desktop system. This means that it is responsive, and when you click something, you get an immediate response. It is not about getting the absolute fastest kernel compile times...