The patch

The patch is against TagLib svn, the library in charge of reading the MP3 tags and feeding them to Amarok:

Index: toolkit/tfile.cpp

--- toolkit/tfile.cpp (revisión: 721576) +++ toolkit/tfile.cpp (copia de trabajo) @@ -30,7 +30,11 @@ # include <io.h> # define ftruncate _chsize #else + /* Rudd-O: for fadvise / + / I have NO idea how to make this conditional on compile time. Ideas? */ + #define _XOPEN_SOURCE 600 #include <unistd.h> + #include <fcntl.h> #endif #include <stdlib.h>

@@ -41,6 +45,7 @@ # define W_OK 2 #endif

+ using namespace TagLib;

class File::FilePrivate @@ -73,6 +78,7 @@

File::File(const char *file) { + int fadvise_retvalue = 0; d = new FilePrivate(::strdup(file));

// First try with read/write mode, if that fails, fall back to read only. @@ -87,12 +93,26 @@

if(!d->file) debug("Could not open file " + String(file)); + + /* Rudd-O: we don't want the kernel to cache this file descriptor or perform any readahead -- but only if no one else opens the file. see posix_fadvise(2) / + / FIXME I have NO idea how to make this conditional on compile time. Ideas? */ + if(d->file) { + fadvise_retvalue = posix_fadvise(fileno(d->file),0,0,POSIX_FADV_RANDOM); + if (fadvise_retvalue != 0) + debug("Could not tell the kernel to not cache the file " + String(file)); + } }

File::~File() { - if(d->file) + int fadvise_retvalue = 0; + if(d->file) { + /* Rudd-O: FIXME Also needs to be conditional to the availability of posix_fadvise */ + fadvise_retvalue = posix_fadvise(fileno(d->file),0,0,POSIX_FADV_DONTNEED); + if (fadvise_retvalue != 0) + debug("Could not tell the kernel to evict from cache the file " + String(file)); fclose(d->file); + } delete d; }

The theory

posix_fadvise(), in theory, on POSIX systems (Linux included) lets you tell the system how to behave with regard to a certain file. In particular, this patch tells Linux that the MP3 will be accessed randomly.

Linux 2.6 obeys it by simply not performing readahead. In effect, the patch says “you shouldn’t perform readahead whlie reading the tags on the MP3s”.

When the file is closed, the patch also uses the POSIX_FADV_DONTNEED hint, to make Linux evict any memory used by the recently read file from the page cache (but only if no other process/thread has the file open, so it should be safe).

Why this should work

TagLib figures out the tags by reading two key parts of the MP3 file: the very end for ID3v1 (a couple hundred bytes), and the very beginning for ID3v2 (up to 64 K, but usually considerably less).

What TagLib does is:

1. Open the file
2. Read the data (a total of anywhere between 16K and 64K)
3. Close the file

But the Linux kernel does a few magic performance tricks behind the scenes, which actually cause the following to happen:

1. Open the file
2. Read the data — with block device and filesystem readahead, so maybe up to 512K will be read
3. Put the data in the block memory cache
4. Close the file
5. Hold on to the data in the cache for as long as possible, maybe paging out some pages from the current working set

Now, under regular conditions, these performance tricks actually work. But in the context of a collection scan, it’s brain damaged — does your computer really need to extra data from thousands of files, and then keep that data in memory?

Since there is no need for readahead (at most eight or nine 8K blocks will be needed, and the read operation is explicit about that), we disable that. This should considerably reduce the I/O demands.

Since there is no need for caching the contents (what are the odds that you want to play a specific file in 15.000, seconds after it’s been scanned?) we save memory by telling Linux not to cache the contents of the files. This should relieve memory pressure considerably, and preserve other things in memory (think application icons or code).

This patch should make scans faster and make your computer more usable while your music is being scanned or when Amarok is starting up, but…

I need benchmarks!

Who volunteers? I’ll post them here!

Update: here’s the corresponding bug report in the KDE bug tracking system.

The problem

What’s the number one cause of desktop performance problems?

Let me answer that question with another set of questions:

• Have you noticed how slow your computer is after after unzipping a big file?
• Perhaps you can also notice this effect overnight as well — you return to your computer, and every open application takes a while before they behave snappily again.
• Do you use Amarok? Then you’ll notice this effect after Amarok has finished scanning your music collection.

This problem happens all the time. In fact, I would be willing to bet this is the cause most people find Linux to be slow.

The source of the problem

Here’s my chief finding: desktop performance has very little to do with schedulers and real performance. It has everything to do with disk caching and perceived performance.

Now, bear with me for a second, because what I’m about to explain will let you understand the following. Based on my limited understanding of the Linux kernel (please correct me if I’m wrong, especially about the terminology), there are two distinct cache types:

• a block cache: caches block device contents
• a inode/dentry cache: one layer above the block cache, caches directory entries and other filesystem-related things that cost more to look up than just block device contents

Problem number 1 is that the block cache competes with applications for RAM. Problem number two is that the block cache competes with the inode/dentry cache.

On a normal desktop Linux computer, when you’re short of RAM, Linux will aggressively try to free memory to enlarge the caches. It usually does this by paging out unused portions of applications to disk. This is not good.

Why? Since disks are slow, the following consequences follow:

Let’s get technical (skip this heading if you’re uncomfortable with technicalities)

For desktop performance, where workloads are unpredictable, responsiveness needs dictate that applications’ working sets should be in core as much as possible, because the probability of major page faults in desktop loads is much larger than on server loads.

Let me rephrase that: Screw data. Prioritize code.

In other words: it’s OK if your application stalls a bit while reading non-cached data from disk, because that isn’t going to make the application seem frozen for a couple of seconds. It’s not OK if the application freezes because it needs to execute code that was paged out to disk.

All in all, how Linux uses your RAM matters a lot for desktop performance

You can see where this is going: if you have 1 GB of RAM (or less) you unzip a 300 MB archive, and the Linux kernel will swap out portions of your applications to disk in an effort to accomodate both the 300 MB file and the blocks of the uncompressed files about to be written on disk. It will also shrink the inode/dentry cache.

Linux, of course, thinks it’s doing a good thing — the archive uncompresses, in effect, rather quickly because of this. You, of course, want to kick Linux in the nuts because while (and after) the uncompress took place, starting an application or opening a new browser window suddenly takes ages, and your open applications “blank out” for a couple of seconds before reacting to your clicks and keystrokes.

Think about it: Linux is catering to the needs of the uncompression program, and you are actively telling your computer you want to do other stuff while it happens. Linux starts to scramble between reading the archive, writing data to disk, and bringing the portions of the applications you’re using “back from the dead” (from swap). Guess who loses? If you guessed “the applications” or “you”, you’d have been right.

Even worse: suppose you want to browse your home directory while all of this happens. In addition to the fact that your file manager is probably half-on-disk by now, you’ve got the problem that Linux needs to re-read your home directory, since the inode/dentry cache has been squashed.

Not good. I posit that the default settings may be very good for workloads with many repeating tasks, but definitely ungood for desktop situations, when applications (and code paths) are diverse and respond only to the whims of the user.

What we want is perceived performance

Let’s take a file manager for example. Let’s focus on Konqueror (it’s a nice case study, and it’s a nice file manager). Suppose I hit the home button on my panel, which shows one of the (usually hidden and prelaunched) Konqueror instances and prompts it to browse my home directory.

If you have lots of RAM, it won’t be a problem — both Konqueror and the contents of your home directory will be in memory, so it’ll be blindingly fast. But if you’re rather short of memory, it’s a different matter — what happens next determines whether you feel your computer slow or fast.

If Konqueror has been paged out, it will appear to be frozen (or take longer to “start up”) for a couple of seconds, until Linux has paged necessary code paths in. If, on the contrary, my home directory has been evicted from the RAM cache, Konqueror will show up instantly and be responsive, while the home directory loads.

I’d much rather wait for the directory display than have to wait for Konq to unfreeze because it was paged out. The difference is that in the first scenario, I can close the window, use the menus, navigate among the window controls, change the URL, abort the operation; in the second case, I’m screwed until Linux decides to fully pagein whatever Konq needs.

That’s what I’m arguing for — perceived performance, not throughput. It matters to me that I can manipulate my file manager half-a-second after I’ve hit the home button. It doesn’t matter to me that, because of this preference, the home directory actually takes one second longer to finish displaying.

Variations of this pattern can be found everywhere: in file open dialogs, in multimedia applications with collection managers, basically everywhere an operation requires some sort of progress report.

The solution

There are two distinct and complementary measures we’ll take to solve this problem. Keep reading to find out about them.