There have been numerous improvements to the Vista kernel which greatly improve user experiences and deterministic application behavior. I’ve mentioned one such improvement earlier in my post about Vista not melting laptops (a form of I/O cancellation I talk about below), and will mention a few others here. I learned about these improvements by attending a lecture from Mark Russinovich from SysInternals fame a few months back.

Better Thread Fairness

In prior versions of Windows, the kernel scheduler had to make some rather unfair assumptions about thread execution time because CPU cycle counters (these registers are available in modern processors) were not taken into consideration. By way of example, in Windows XP, if both thread-A and thread-B have the same priority and are ready to be run at the same time, one is chosen (let’s say thread-A) and is executed for a pre-defined time slice. However, if another higher priority thread comes along during thread-A’s execution, the scheduler will interrupt thread-A and run the higher priority thread. The scheduler doesn’t keep track of this though, so sticks with its assumption that thread-A ran for the entire time slice even though it ran for much less because of the interruption. After the time slice is up, thread-B is ran; which if un-interrupted, is free to run for the entire time slice (same amount of time thread-A was supposed to get). In this situation, thread-B got much more CPU time than thread-A, even though they had the same priority.

In Vista, the scheduler makes use of cycle counter registers in modern processors, and is able to estimate how many cycles a thread uses per clock tick. This way, the scheduler can divvy up CPU time much more fairly. For the example above, thread-A would be allowed to run for another time slice after being interrupted, before thread-B would be allowed to execute. Now this scheme isn’t completely fair (I’m not sure it’s feasible to be 100% fair) because thread-A would actually get a few more ticks of execution time than thread-b, but it is *much more* fair than Windows XP and before.

Multimedia Class Scheduling

Multimedia (audio/video) is a core scenario for Vista, and as such, it is critical that these experiences are great even in the face of concurrently running, resource sucking, applications. A great example is if you are watching a high-resolution video with Windows Media Player on XP and anti-virus scanning kicks into action in the background. It’s likely you’ll see video glitches. To remedy this, Windows Vista introduces the Multimedia Class Scheduling Service (MMCSS) to manage CPU priorities of multimedia threads.

Multimedia applications like Media Center and Media Player can register with this new service via newly available Vista APIs for describing their characteristics. The characteristics have to be one described in this registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks

MMCSS manages the priorities of registered multimedia applications, while at the same time, ensuring that they don’t starve other applications. If you were to try the above example on Vista (media player with anti-virus concurrently), you’d see the video playback glitch free.

I/O Completion Performance & Cancellation

A common approach for doing asynchronous I/O is to use completion ports; which is a programming construct for use as a synchronization object. Prior to Vista, when such an I/O completed, the thread which issued the I/O is the same that executes the I/O completion work. This required a context switch that introduced a performance penalty (especially if there is a lot of I/O). Once the I/O completed, the I/O system would update the completion port status to wake up a thread monitoring its status.

On Vista, the I/O completion processing is done by the thread that is waiting for the completion port to be updated. The very minor change negates the need for thread scheduling and the context switches that can degrade an application’s (and system’s) overall performance. Even better, the results of multiple I/O operations from a completion can be retrieved with a single request, avoiding transitions to kernel mode from a user mode application.

A new capability for Vista is I/O cancellation prior to reaching timeouts. You’ve experienced not being able to cancel an I/O operation if you have ever tried to cancel (Ctrl + C) an attempt to access an offline network share; you had to wait until the timeout expired while the system was unresponsive. Now in Vista, you can cancel these operations! In fact, most I/O operations can be canceled (I’m not sure which ones can’t be) including the open file I/O that net view and Explorer use. If 3rd party applications don’t rely on the file I/O provided by Windows, they will have to update to support the new cancellation capability.

I/O Priority

Finally! My background processes like search indexing, anti-virus, malware scans, disk defragments, etc. won’t bog down foreground tasks. Vista enables both I/O priority for individual operations, as well as I/O bandwidth reservations. Note I’m talking about disk bandwidth, not network bandwidth (Windows doesn’t support network bandwidth reservations for good reason). All the background processes built-in to Vista use low I/O priority (Windows Defender, search indexing, etc.), but 3rd party applications (think Anti-Virus) have to take advantage of this capability to provide a better user experience. Regarding I/O bandwidth reservations, applications like Windows Media Player use this to ensure local playback of multimedia files is glitch free. Disk I/O priority combined with process priority provided by MMCSS discussed above enables a really great user experience of multimedia, even in the presence of other substantial system activity.

There are *many* other kernel improvements that I haven’t discussed here, but hopefully I’ll get to those in future posts. If there are any other areas folks have interest in, let me know. I’ll do my best to provide details.

Previous in series