Probably within a week. I was hoping to have a complete version of the staircase ready by now and start working on -ck but I don't think that's going to be the case. It will be a better version than the one in 2.6.4-ck but it will not be the final version.

Fortunately the stuff I've been putting into -ck has actually been sneaking into 2.6 mainline meaning I'm not the only person who thinks these things are important ;-) Some things I have will never be merged, though, so it means there will always be something for me to make a -ck with.

For what it's worth, it might be worthwhile to have some combination of the autoswappiness patch and automatic swap sizing in a desktop distro.

Granted, when you have a swap partition (as opposed to a swap file), the swap size is picked up front as part of the install. I seem to recall most installers at least suggest an initial partition layout.

None seem to suggest anything like my favorite algorithm, which is to:

• Put one swap partition on each hard drive
  
• Put the swap partitions as early as possible on the drive
  
• Mark swap partitions on all fast primary drives (masters on IDE chains) at equal priority so swap allocations "round-robin"
  
• Mark all other swap partitions low-priority so they only get allocated if the others fill up. Mark at lowest priority drives on chains that will get a lot of disk usage (eg. mastering DVDs, etc.).
  

That effectively spreads the swap loading out, and it seems to speed up swap-in in my limited testing. Granted, the last time I tested it heavily with a swappy load was in the 2.2 days, but old habits die hard. I'm still not running 2.6 yet (though I will w/ my next computer).

One variation on the algorithm is to put the partition for /tmp ahead of the swap partition.

Read the first line of this story and check out the link.

Linux seems to gobble up the entire available memory and allocate it as a disk cache. Linux systems with less than 95% memory usage are unusual, precisely because of this aggressive cache allocation. But that is ok.
What some people (me included) complain about is that the cache is so aggressive that it pushes out processes. This is very much the case with the 2.4 kernel, it is less an issue with 2.6 but it still happens a bit too much.
Con Kolivas' patches try to address this problem and make the kernel "smarter", so that "it knows" when to be aggressive and when not to.

The disk cache is dynamic. Actually, the notion of "disk cache" is pretty slippery, since it's not quite what you may think it is. This isn't like MS-DOS's "SmartDrive" or Norton SpeedDisk.

The description below is mostly from memory, with some slight refreshes from Mel Gorman's VM Documentation for Linux 2.4. It also is oversimplified and probably inaccurate in places. Mainly it is intended to make a point.

Once upon a time, there were two caching structures--the buffer cache and the page cache. The buffer cache strictly held copies of blocks from the disk. The page cache held pages that could be mapped into process address space. The buffer cache is the closest thing Linux had to something like the disk caches of old. IIRC, starting with 2.4, the buffer and page cache are unified. Thus, what you have for a disk cache is really an all-purpose beast.

Pages are the work-horse of the VM. They can be file-backed or anonymous. They can hold data or they can hold code. They can be "clean" or "dirty." They can be "read only" or "copy-on-write." All of this is quite important.

Nearly every bit of code or data your applications want to touch is held in a page. Thus, keeping an application's working set in memory is really a process of keeping the pages it needs in memory. When you don't have enough memory for all the pages you might want to access, you have to make room somehow.

There are two main strategies for making room: Throw some pages away, and push some pages to swap. Both strategies will require you to re-read the pages in the future. How pages are handled depends on how they're categorized. One way to break it down is as follows:

1. File-backed pages that are never written to can be thrown away and re-read. This includes pages that hold data files, and pages that hold executable code. These pages will be scattered all over the disk, and so the cost of bringing them back into memory may be large.

   
   

2. File-backed pages that are read-write and have been written to (aka. are "dirty") can be written back to their respective files and then discarded. The cost of discarding these is higher, since they must be written back. The cost of bringing these pages back into memory is the same as for the other file backed pages. Periodically writing back dirty pages (e.g. what bdflush does) keeps this set small.

   
   

3. Anonymous pages (such as those that back 'malloc()') and file-backed copy-on-write pages can't be written to any file. File-backed copy-on-write pages are typically program pages and library pages that have been written to by the dynamic linker. These clearly cannot be written back to their source files. Anonymous pages don't have an associated file. To move these pages out of the way, the only recourse is to move these to swap. The cost of writing the pages to swap can be low if the swap is well organized. The cost of bringing the pages back in is similar to bringing back file-backed pages, with a small chance of it being cheaper if the swap is laid out well.

   
   

Side note: Swap is interesting, because it offers an on-disk home for all the pages in that third category. When pages are written out to swap, they now have an on-disk home. When they're subsequently brought back in, the copy in swap doesn't change. As long as the page isn't written to later, it can be discarded without re-writing it to swap. In Linux, the "swap cache" handles this optimization.

But anyway, back to my point. If you eliminate swap, you only allow clean file-backed pages to be moved out of the memory map. The balance between swap and non-swap is totally a matter of discarding never-written file and program pages and discarding pages that can only live in swap. It's not as simple as "this is my disk cache, and it can only get this big."

Balancing the composition of the page cache is tricky business. Some portion of it will be file-backed pages, and some portion won't. Some portion will be swapped, some portion will be dropped and re-read. The "swappiness" control changes the bias, but there's no good answer. Ultimately, your goal is to reduce your I/O to maximize CPU utilization. If your working set is too large, you'll get excess I/O, period. VM tuning is all about making the transition region between "too large" and "not too large" as pleasant as possible.

Why are desktop loads so special, and the cause of so much controversy? Because the user's definition of working set ("the windows I can see and want to point my mouse at") has little to do with the actual working set ("the tasks that aren't sleeping"). If some job comes up in the background (such as everyone's favorite whipping boy, updatedb), the OS legitimately considers it the current working set. The user who sits down at the machine later and tries to interact with the now-swapped Mozilla window afterwards wonders why his "working set" got pushed out.

Basically, for those applications, it sounds like Linux too aggressively prefers to move pages to swap as opposed to dropping nice, clean file-backed pages. For latency sensitive applications, you really need to make sure you've set the tasks to a real-time priority, and make sure you mlock() all the buffers in RAM so they don't get paged. For streaming apps, I'm not sure what exactly you do.

Notice one of the caveats I gave about swap in my post: Swap has potential to perform as well or better than just discarding clean pages if it is laid out well. I suspect on most systems, swap isn't laid out very well at all after awhile--you get a seek storm with every burst of swap activity.

For large video applications and what-not, I can see this being particularly frustrating, since most of what's in that disk buffer won't be referenced again any time soon. You're either streaming, or you're doing non-linear editing, but in any case, the context is so huge that it is a loss for the kernel to try to keep some of it in RAM--its LRU just won't do the trick.

I seem to recall an O_STREAM attribute being bandied about at some point, but I don't know if it ever went in. Its purpose would be to identify a file as a "huge freakin' stream you shouldn't bother caching too aggressively."