Linux in Government: Optimizing Desktop Performance, Part I

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

On a default Linux configuration, distributors provide six text-mode virtual consoles. You can access each console by pressing Ctrl+Alt+F1 through Ctrl+Alt+F6; Ctrl+Alt+F7 switches to the graphical desktop. Each virtual console consumes memory.

Virtual consoles attracted me to Linux and they are one of my favorite features. But, I don't use those consoles much. I like having an extra one so I can get to a graphic terminal if I need, but as a desktop user, I don't need six.

I edit /etc/inittab (see Figure 2) and commented out four or so of the six lines that spawn gettys. This allows me to free up more memory to use with my productivity suite, which we'll reconfigure in a few moments.

Figure 2. Disabling Virtual Terminals

Speeding Up OpenOffice.orgs' Launch

One of the major complaints that I hear is how long it takes the applications to launch. You can add a quickstart applet to GNOME by installing the program ooqstart- gnome, which may help some. However, an internal adjustment to OOo Writer can improve the entire suite's performance.

To accomplish this, you need to start the word processor, Writer. Next, you need to open the Tools drop-down menu and select options. Once you open the options box, you are ready to adjust the memory and speed up your Linux productivity suite. Let's look at Figure 3.

Figure 3. Options

In the above figure, you can see that we selected the first expansion box and then clicked Memory with our mouse. This exposed the window you see in Figure 3. I changed the default values under the Graphics cache for Use for and Memory per Object. I increased the first value from 6 to 128MB. I also increased the second value from .5 to 20MB.

After clicking OK, I closed the word processor and reopened it two times. On each occasion, the application took less time to open. Under Ubuntu, I found that OO Writer opened in three seconds, and in Fedora it opened in less than six seconds. Previously, it took 30 and 26 seconds, respectively, for the word processor to launch.

Just the Start

Due to space limitations, we have to break this discussion of optimizations into different parts. Hopefully, the first article enables you to make improvements in your desktop's performance. Each change we make in future articles will have a cumulative effect, and soon you will see your entire Linux operating system in a new way--as a fast desktop.

Tom Adelstein works as an Analyst with Hiser+Adelstein, headquartered in New York City. He's the co-author of the book Exploring the JDS Linux Desktop and author of an upcoming book on Linux system administration, to be published by O'Reilly and Associates. Tom has been consulting and writing articles and books about Linux since early 1999.



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