IanG on Tap

As you doubtless know, the scheduler in Windows is able to apply a little bias. If multiple processes are all trying to use the CPU, by default Windows will favour whichever process has the focus. It won't let it hog the CPU, but it will give it more cycles than other processes. On a typical desktop this is a good thing - it means that whatever application you're using is likely to get the lion's share of the resources. (And for those situations where it's not a good thing, e.g. server systems, you can turn this feature off.)

Unfortunately, disk IO doesn't seem to get the same treatment. This irks me because my laptop has a really slow hard disk. (I chose to put pixel count above everything else when I bought my laptop. So on the plus side, I have a fabulous 1920x1200 screen, at a stunning pixel pitch of 150dpi, which with ClearType's technique of controlling the individual colour elements works out at an effective horizontal resolution of 450dpi. I love this screen. Sadly, when I bought it, the only laptop with this screen came with a crummy 4,200rpm hard disk - a downgrade from my previous laptop. I'm waiting for a 7,200rpm 80GB disk to come out. The 7,200rpm 60GB disks have been out for about a year now, so surely it can't be that much longer before a larger 7,200rpm hard disk comes out. I thought hard disk capacity was suppose to be outpacing Moore's law at the moment!)

Whenever I run a virus scan, or install something huge, all my applications grind to a halt. For example, today I downloaded the DirectX 9 SDK, and my machine was barely capable of sustaining two IM conversations - it would take about 5 seconds of thrashing to move the focus between two IM windows.

There seem to be two problems here.

The first problem is actually unrelated to the title of this blog. It appears that whenever some work involving large amounts of disk activity goes on, Windows XP decides to trim the working set of all my applications aggressively and divert all the memory to the disk cache. This is a royal pain for things like unpacking vast compressed files or running virus scans, because absolutely none of that caching will be remotely useful. I don't have enough RAM to cache my entire hard disk, sadly, and in any case, these are sequential operations - once a particular sector has been touched during one of these operations, chances are it's not going to be touched again. So memory that was previously doing useful work in the applications I'm running has been redirected to cache data I'm unlikely to need any time in the next few days. This is a bit galling - it makes me wonder whether I've been wasting my time all these years when I've passed in the FILE_FLAG_SEQUENTIAL_SCAN flag to the CreateFile API. Of course it could simply be that my virus scanner isn't bothering to use that flag...

(It could be that my analysis of what's going on here is wrong by the way. I'm basing this on the fact that whenever either a virus scan runs or a vast compressed file is unpacked, I can use the Task Manager to watch the System Cache grow huge, I can see the Mem Usage column of all my apps shrinking, and everything swaps painfully for the next 5 minutes once the operation is done. So I'm reasonably confident that this is whats going on.)

The second problem is that there doesn't seem to be any kind of IO priority boost for the application in the foreground. I want my virus scan to run of course, but I absolutely don't want it to slow my machine down. There's no good reason for it to slow things down. I'm already resigned to the scan taking several hours to run, but I only want it to be granted access to the hard disk when nothing else wants to use the hard disk. That way, the worst impact it could possibly have is that if the OS has already started a disk seek on behalf of the virus scan, the foreground application might have to wait for that seek to finish, but that should only be a few ms.

But apparently this isn't happening. (Or if it is, it's not giving enough of a boost.) I say this because of what happens when I go to Outlook during a virus scan. Of course most of Outlook has been swapped out due to the aforementioned well intentioned but unhelpful disk caching. But it takes forever to swap back in - far longer than it does when the virus scanner isn't running, and most of Outlook has been paged out for some other reason. (E.g., today when unpacking the DirectX SDK, Windows had dedicated the entire disk cache to a file I was about to delete, returning to Outlook after the installation process was complete was sluggish as everything paged back in, but it was way faster than when a virus scan is running.)

I'm hoping this will get better in Longhorn. I know that disk scheduling support is being added to the kernel to enable the necessary real time guarantees required to stream media off disk reliably. Today's versions of Windows (and also Mac OS X and Linux in case you're wondering) will exhibit playblack problems if there is too much contention for the disk. For example, if you run a virus scan, a build, two or three full text searches on your hard disk and you play some music off the hard disk at the same time, you are likely to experience breakup in the music playback. (Although those of you with more exotic disk setups might get away with it.)

As I understand it, it will be possible for media presentation code (audio and video codecs mainly) to reserve a level of guaranteed access to the CPU and to the disk system to make sure that they can play out regardless of what else the system might be doing. (Of course the OS will only agree to their requests if it knows it can meet them - if I ask the OS to give me 200% of the CPU time and 200TB/s of data access of the disk on my single-CPU laptop with its puny hard disk, it will, I hope, turn down my request.)

So, what I'm hoping is that the infrastructure they've built there will also allow processes to arrange to run with low IO priority. Today it's possible to lower your thread priorities such that the thread only runs when the system has nothing better to do. In the future I'd like to be able to do the same thing for disk IO.