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.


Anonymous's picture

Nice letter thanx man ;)


Mike's picture

Great article - the other parts too..

Its been submitted into queue @ tweako

( )

where is part 2

Anonymous's picture

where is part 2

Here are parts 2 and 3 for

tngrn's picture

(Very) Old Advice

Anonymous's picture

Basically, the article says "upgrade your RAM to make your Linux desktop go faster". Well, that's nothing new. That's been sound, albeit expensive, advice for decades.

I mean, why not upgrade to 3+GB, (recompile your kernel to support himem so you can use it!), set your swapiness to 0 so everything stays in memory for as long as possible, create a 0.5 - 1GB ram disk and copy all of your most used progs and data there, and then watch your system fly! You'll have amazing responsiveness and and blazingly fast start up times.

Hey, while you're at it, why not upgrade your whole system. Get something top of the line. Max out its RAM. Install a RAID-5 array with really fast drives. Money is no object!

Okay...maybe this article doesn't go that far, but in some cases, it may as well. Here are the two real problems with adding more RAM. They aren't to do with the tips after you've got it, but rather the actual act of getting it.

First, not all systems can just have more RAM slapped into them. My laptop maxes out at 256MB of RAM (currently has 128 installed). And while desktop RAM may be cheap, smaller sticks of SODIMMs are more pricey. 512MB @ $70 may be good, but 128MB @ $ wallet starts to cry. Adding more RAM and performing most of the suggests thus far don't work for me here.

(I won't even consider touching OOo because its too bloaty. Heck, even Firefox has a 40MB physical memory footprint.)

The second problem is more philosophical, but why should I have to upgrade my system to get decent performance (responsiveness)? I mean, I hate to use the W word, but come on. Spend an extra $70 so you can get the same responsiveness from Linux, or just use Windows (which likely came preinstalled on the system) and keep your $$. I think most people are looking for a solution that will bring their Linux desktop system at LEAST up to par with an equivalent Windows system.

(XP runs great on my laptop. Very responsive. I just refuse to use it although I keep it around for those instances when I need Windows.) What I'd like is to get the same responsiveness from my Linux desktop.

the author wrote this guide s

Anonymous's picture

the author wrote this guide so we wouldn't have to spend extra money for ram. if you don't want to use a bloated and slow distro, then switch to a much faster one then download and install the packages you need. fyi: this guide has really helped me out.

brag about xp, no one's forcing you not to. just keep in mind that the next software you may need has to be purchased. and when spywares, virus, and trojans hits you, reinstalling the os is a lot more work than following the advise above.

when was the last time you've got spyware on your laptop? if you're as arrogant as i think you are, you might have one now. and how long have you been using linux? a month? six months? c'mon, if you've been using linux for some time, you'll know it's far more superior and faster with "an equivalent Windows system."

re:the author wrote this guide s

John Panno's picture

I agree, but there is one thing, that really looks different now. I am in my 40s and slowly have to use glasses to read everything on my screen. Windows-Characters look a lot more crisper than on Linux.


Anonymous's picture

You may want to invest in making your windows fonts available to the linux font server. I've done that, and since many linux apps, whether in the program or via X configuration, can have what fonts they use customized, I have the same level of clarity and choice of font as I do in windows. I use glasses for computer use as well and know where you're coming from. You may have to learn a little more about how to do the above, but you'll be much more "do-it-yourself" for it.


Anonymous's picture

Waaa, waaa, boo hoo...

I've been wearing glasses FULL-TIME since I was FIVE YEARS OLD. I wish people would stop moaning about wearing glasses when they turn 40--I've been using them since I was a toddler. And I can't see anything without my glasses on. (With them, my vision is normal, but without them--forget it!) And I am only 19.

By the way, I do use Linux myself. The fonts look fine to me. I hate the way they look on Windows XP. I hate Windows. I am a full-time Linux user.

Same here.

galileon's picture

Same here, I'm 20. Plus I always find the windows fonts to be a bit wierd and the never look right...but of course, its because i use only linux at home for about 2 years now...

Lasik is your friend, 19 yo

Anonymous's picture

Lasik is your friend, 19 yo Mr. Magoo.

What's the point of your poin

Daniel C.'s picture

What's the point of your pointless comment? Can't you read before posting. You could also try to be on topic, that would help.

re:What's the point of your poin

John Morta's picture

Sometimes people write what comes into their mind. And not all mind function in the same way 8-))))))

Anticipatory IO Scheduler

DmitryVyal's picture

You can get good speed up by tweaking io sched.
cd to /sys/block//queue/iosched

There are a several parameters, they are described in Documentation/block/as-iosched.txt.

Setting read_expire and read_batch_expire to higher values may increase disk (especialy cdrom) perfomance dramatically.

Then I did this in Knoppix, i got a sensible speed boost.


6thpink's picture

All this things are just minor tweaking that has almost nothing to do with the desktop performance. Maybe the vm.swapiness kernel parameter can increase performance in certain circumstances, but will, undoubtly, decrease it in some machines with a decent hd and about 256-500mb of RAM. Depending on the configuration, the DE or WM used and many other factors.

First, the quick startup of openoffice after the tweakings is not caused by that parameters. As far as I can tell that settings only affect the amount of memory used internally for certain operations, and is used as cache memory FOR DATA, so it has nothing to do with the initial loading of code into memory, and as such, it has nothing at all to do with the loading speed. It is something normal that a second startup of any application is faster, because the code is still cached in memory. That happened the first time that you loaded Oo after the "tweaking", the rest of times what you notice is just a placebo effect.

Second, as someone stated above, each getty takes about 300-400k into memory. That is an issue in machines with 32-64 mb of RAM, but it is not for a machine like yours.

Just clear out that I only use linux in my desktop systems since many years, and I have to say a lot about desktop interactivity and performance, but nothing has to do with all these things.

One thing that hits the desktop performance for sure is the use of reiser(4) as global filesystem, while it is only suitable for a couple of things. The scheme of partitoning and the type of fs for each partiton is one of the things that has more impact on DE interactivity. The second one I would think of is preemptivity. And the third: a good configuration of background processes. But of course, this is so long to describe in a post.

Get a clue

Anonymous's picture

You (parent post, "Really") guessed right on the getty memory and the start/restart on OOo. For the rest of your comments, pull out the pencil, make sure you have a big eraser, and stop sniffing the rubber cement.

The trick or tip with OOo and increasing the memory in the Graphics cache setting is a very effective change. Having run knoppix from the cd drive for over a year on a few computers, this increase in memory setting cuts anywhere from 30 seconds to more than several minutes off the start time of OOo depending on the computer. While tracking knoppix a year ago and more, it was one of the first tips handed out for regular users who know about it. It's one of the first things I did when installing the system on the computer I'm typing this post with. In reading this article, I checked it and found that it was back down to the default setting. It appears that an upgrade of OOo overwrote my increased memory setting back to default. I couldn't figure out why OOo was taking so long to start up while ssh'ing into this computer (Debian) from another computer that was running knoppix off the cd drive. I attributed the slowness to running it over the network and running on knoppix from the cd. It didn't occur to me that an upgrade of OOo would have overwrote my increased memory setting. Now that the memory setting is increased again, OOo once again starts faster both on the desktop and while ssh'ing in from another location.

The memory tip in this setting that I often gave to others was to increase to about 24 MB depending on how much memory they had installed (Walmart/Microtel boxes with 128mb memory for example) and try increasing further, 32 MB if more memory was available (192mb or higher) and to test when going higher.

There's absolutely no question that this memory setting increase helps startup tremendously. It is magnified and much easier to see when running knoppix from cd, but is also apparent to a lesser extent when running a stock distro off the hard drive. And no, the slowness of running off the cd when using knoppix is not 100% of the problem since the startup time improves when the memory setting is increased. Stop sniffing the rubber cement and pay attention.

As for swappiness, I'm glad to read about this tip as well. This isn't an issue just on low memory systems. It also has to do with how Linux handles swap. There were debates over this more than a year ago with the 2.4 kernel. Googling linux, swap, ramdisk should bring up the kernel debates. There was ongoing discussion about whether creating ramdisks out of ram would help with swap issues, or whether the ram was being wasted and should be put to use as more regular ram instead.

For a reproduceable example, on a system with 512 mb of memory, run kde, open a mail client that has a large number of emails (500,000 or so) or another application that contains a large number of small files, then also open up about 150-200 tabs in konqueror or mozilla/firefox to web pages, open an IM client, run a few ktimer jobs, open 40-50 bash sessions, firestarter, a couple dozen kwrite/kate or other editors on some files preferably larger ones. Then leave the system running for a few days without using it.

When you come back to the system, try viewing a dozen web pages from the tabs of your web browser and checking logs with one of the bash windows. It will take minutes to view a couple of web pages in each tab. Switching more tabs will take minutes for each of those tabs to swap back in so you can view them and scroll down to see the info below the bottom of the window.

Have 256 mb memory? Cut the numbers above in half. Have 1 GB? Don't know if that much memory will present the same issues or if that much memory is handled differently but I think it would be the same, so double the numbers above and try with 1 GB.

The point is that there are issues with Linux loading up everything into memory. Maybe more memory should be left unused to decrease swap so the current X window open in front of the user has access to more ram instantly instead of waiting for pages to swap in and out from the very beginning after some idle time. As is clearly the case, memory management and actual and perceived responsiveness are tough issues for programmers. Some programmers may not see the problem because they use their systems differently and if it is good enough for them it is good enough for everyone. Some see the problem, hence the discussion about it during the 2.4 timeframe.

Reading the tip that I can manually adjust swappiness and find the best setting for my own situation is another great tip in this article. I've already changed the setting and am getting a better response time for opening new tabs, starting applications, and other similar tasks. Haven't tested extensively yet, but I can see that this tweak will help me and others now and in the future.

As for your dig at Reiser4, I can't say as its considered experimental still. If Reiser4 is any faster than the current Reiserfs, then I know that you've been sniffing the rubber cement again. Reiserfs absolutely dominates ext3 and other journaled/meta-journaled filesystems when it comes to small files. The comparison tests are out there on the web. I don't need any comparison tests for my own info. I have about a million email files sitting in about 30-40 subdirectories of my mail directory. Write yourself a script that creates that many files from 1k to 10k in size, averaging about 4 or 5k. Distribute them to 30-40 subdirectories randomly so some directories get 25,000 files, some just a few thousand, and most somewhere in between. Then pull the plug from the wall. Then run a fsck, fixing any errors. Do that for Reiserfs, for ext3, ext2, and whatever other filesystem you are enamored with. Don't bother posting the results. Anyone with experience with Reiserfs with the above parameters knows which filesystem is superior. Just post the response times for each filesystem when switching directories when each directory contains 25,000-50,000 files in your mail client. If Reiser4 is as fast as or faster (or even a little slower) than Reiserfs, then you are sniffing too much glue. The last time I checked, Reiser4 was still considered experimental for a "stable" filesystem. I don't know anyone dumb enough to use an experimental file system for their desktop or for a mission critical use (and when it comes to filesystems and data on hard drives I consider anything other than development/testing to be mission critical).

I look forward to reading the future installments of this article. I've found the tips useful for myself and will recommend them and continue to recommend them to others. Parent poster should stop sniffing the rubber cement. It's burning too many of your brain cells.


Anonymous's picture

Hmmmm. I'm pretty smart and I also understand the things suggested in the article. So have a raspberry because they work for me.

In fact, have two raspberries.

swappiness file in slackware

gaurav's picture

i am not able to find the such file in slackware
as the article mentions that it is in the fedora and ubuntu based systems so what alternative is there for the slackware distro


slackware swappiness

Paolo Sonego's picture

As usual in slackware, you can add the following line

sysctl -w vm.swappiness=10

to /etc/rc.d/rc.local


gaurav's picture

i get this in slackware

error: 'vm.swappiness' is an unknown key

also since there is not /proc/sys/vm/swappines file


Are you running 2.4 or 2.6? S

Anonymous's picture

Are you running 2.4 or 2.6? Swappiness can only be controlled on 2.6, AFAIK.

same for gentoo

Anonymous's picture

same for gentoo

Swappiness=10 is great

Anonymous's picture

Noticed a much more responsive desktop as a result. Doom 3 liked it also, very much. Application exits are much faster.

Dual AMD MP 2000
1gig ram

My issue with distributions.

JAChaney's picture

The article does a great job of explaining what many of the problems existing with standard distributions, however, it misses the main issue that I have with nearly all the mainstream distributions. The problem has its root in trying to be all things to all users.

My suggestion is to work the installation from the other direction, instead of starting with "install all" then having the user remove the items they have no use for, how about starting with a base then clicking on what they want added.

Example, "a workstation" doesn't need to have an Apache server running in the background. The same way, a server box doesn't necessarily need to have a GUI and all its overhead.

Here's a radical thought, an X-based workstation with OpenOffice, Mozilla, a stripped out Window Manager, DHCP client(or PPP, or wireless client), No compilers, no Perl, some libraries to make things work, an audio player, and some simple applications and games(selectable). The size of the footprint would be greatly reduced, the speed improvement would be substantial due to not having all the daemons running in the background, and security could be more easily managed by limiting access points.

Already been done twice that

Anonymous's picture

Already been done twice that I know of. DSL is exactly what you described, and there was a distro "JAMD" that was a recompiled and optimized RedHat. Both were small and fast.

Closing those virtual consoles.

Anonymous's picture

Worked a treat! Thankyou.

My greatest speed increase I

Morgan's picture

My greatest speed increase I have noticed in Linux is when I have recompiled the kernel source rpm using.

rpm --rebuild --target athlon kernel.src.rpm

Also there is Yoper (very fast!)

Pointless optimization

moZer's picture

So...exactly how much ram do you expect to free by disabling 4 out of 6 virtual consoles?

On my Fedora Rawhide box the mingetty processes each consume about 352 kb of resident memory. That's less than any other userspace application.

RE: Pointless Optimization

JL's picture

From a system aspect any unnecessary processes left running consume resources, the removal or which would mean "optimization".

If reactiveness (counted in ms, not seconds) is the game then nothing is taboo. Slash, crash, and workaround until your 400Mhz Pentium is reacting faster than computers twice that grade. Any process in the stack is another drag on response time, but there are tradeoffs. Some are worth keeping on at all times, say the kernel, and at least the CLI...

One good way to learn this is to start with a top down approach, install all your junk and learn what you do and don't need (ie. RedHat). Then experiment building minimal setups from the ground up I think that's where Ubuntu and Knoppix shine. That is what modular code is for.

Universal installations are for learning, getting the feet wet. Then targeted/specific installs are highly customized and performance oriented. There is a sacrifice though, things out of your usual routine will not be 'immediately' available (buffered, installed, & what-have-you) which is why we can execute, compile, and/or install them whenever we choose. :)

Just my POV...

You are right. A better appro

Anonymous's picture

You are right. A better approach is to disable unused and unneeded daemons. Most distributions enable much more than you need or will use.

You are right. A better appro

Anonymous's picture

Dah. Why don't you give Linux Journal the opportunity to finish the series.

mingetty is a good getty for

MadProf's picture

mingetty is a good getty for most desktops, and takes up very little. but many systems come with "agetty" and other overly complex gettys. They can do more, but most people don't need the stuff they can do.

Pointless optimization

Anonymous's picture

Mine save 1.7 MB each and I can use it on my Laptop.

reloading OOo...

Anonymous's picture

on the second and third launch of OO Writer, the speed increased a lot on my laptop... without touching the configuration at all!

the speed gain is mainly due to kernel caching of the on disk pages containing the object code for OO itself...

To make a real test, you have to actually reboot your pc to clean the cache then you can get more correct numbers, I think the tweaks can maybe improve OO speed while running but certainly can't improve program loading times.

For that, you have to operate at a totally different level (prelinking, compiler optimizations etc.).

reloading OOo...

Anonymous's picture

the speed gain is mainly due to kernel caching of the on disk pages containing the object code for OO itself...

I rebooted and it started up much faster than ever. Sometime when I see comments like this, they sound as if the person commenting really knows what they are talking about because the use words like "caching of the on disk pages" and "object code". Why would someone want to bias someone aagainst trying this technique.

reloading OOo...

Tom's picture has a quickstart feature to which you may be referring that keeps it in memory. It also helps with startup and one can activate it with:

$ ooffice -quickstart &

But, the hack in the article above does work and you can test it yourself.

Next week I'll discuss quickstart, ooprelink and adding a respanning script. We'll address many other hacks as well.

The -quickstart switch only w

Anonymous's picture

The -quickstart switch only works properly in Windows. Under Linux, the quickstarter will exit once you close the last OOo window. You can write a simple bash script to automatically reload the quickstarter (the KDE applet oooqs and the GNOME one both do exactly this), though this will spike the CPU for several seconds and somehow defeat the purpose of quickstarting.

You can read about this at OOo bugs database. The developers admitted that the quickstart feature only works in Windows.

The -quickstart switch only w

Anonymous's picture

Is it me, or some people attempting to sabatoge the Linux desktop here. I mean, what's this only Microsoft FUD.

The hack works for me. In fact, signficantly. I found this in O'Reilly's "Desktop Linux Hacks". The author explained how quickstart went off when you closed OOo and he showed how to write an executable to keep it running.

So, when I tried in, my start times went down 90%. The memory increases in the options menu also work.

The proff is in the putting (pudding) or whatever.

"In the above figure, you can

Anonymous's picture

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

I was referring to this part. Tuning the Graphics cache of OO can do probably wonders while using it, but the preceived speed improvement you reported here is due 100% to the page cache.

the quickstart feature is a different beast

"In the above figure, you can

Tom's picture

Sure. I agree completely.


bill's picture

So you are agreeing that your tip about
setting OO graphics cache size has no
effect whatsoever on startup times?

I timed my OO startup (14.5 seconds) and
then adjusted the graphics cache and
**rebooted**. The OO startup time did
not change at all.

I think you should be clear about tips
that improve launch time (the worst thing
about OO IMO) and tips that improve
its operation while running (always seemed
ok to me with default setting actually).


Anonymous's picture

No, I'm not saying it has no effect "what so ever". In fact, it does improve performance with start up because it uses caching. In Part II, you can see another technique to get the applications running faster as well as using the graphics cache.

hmmm ....

bill's picture

the built in linux kernel caching makes a big
difference of course. I've set the OO graphics
cache at default values and at your recommended
values. It makes no difference at all to OO
startup times.

(here's exactly what I did: reboot computer,
start and stop OO 5 times in a row. After
the first startup, so that OO was cached in
memory - a kernel function, nothing to do with
OO - startup time was 4.5 seconds. I then
reset the OO graphics cache to your recommended
values and rebooted, started and stopped OO
five times. After the first startup, OO's startup
time was 4.5 seconds, same as before.)

Not sure I entirely agree

Richard Neill's picture

A few thoughts occur to me:

1)Turning off the spare gettys is unlikely to save you much by way of memory. On my system, they each use 440k of RAM (ps aux -> look for the RSS entry). This isn't that significant.

2)Swappiness: see here:

3)The benefit you saw with OOo restarting faster probably wasn't anything to do with the fact that you changed its memory use. It was to do with the executable remaining cached in RAM, and not having to be retreived from disk. The only fair way to compare application startup speeds is to start it twice, and measuere the *second* time.

forcing caching?

Anonymous's picture

Can't you just do this:

tar c /usr/lib/openoffice/ &> /dev/null

to get Linux to cache all your OOo stuff?

This sounds great! How come

Anonymous's picture

This sounds great!
How come all of this isn't default already? 6 virtual terminals seems like quite a lot...

On another note: OO.o 1.9 series is much much faster than the previous... you should try it out - do the same tips apply there too?

virtual terminals

Matthew Miller's picture

6 virtual terminals is a lot if you don't use them, but if you're working in text mode (as I sometimes do on my very tiny laptop), it's nice to have. Rather than commenting them out, you could change the inittab to:

1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:23:respawn:/sbin/mingetty tty3
4:23:respawn:/sbin/mingetty tty4
5:23:respawn:/sbin/mingetty tty5
6:23:respawn:/sbin/mingetty tty6

which will give you 6 virtual consoles in text mode runlevel 3, but only 2 when X is up in runlevel 5.

Of course, this isn't really a big deal unless you decrease swappiness too much (ironically, given the rest of this article) because if you don't ever use the virtual terminals, the getty processes will get swapped to disk when active programs need the memory.

swap file use

chattr's picture

In Debian testing/sid, the file is


Umm, I don't have that file.

Dudeman's picture

Umm, I don't have that file. Is this something specific to 2.6.x kernels? I'm running 2.4.26.

Umm, I don't have that file.

Anonymous's picture

You're right. It's a 2.6 thingy.