Resolved: A Performance Issue in Windows Timer Management

By Alexander Schmidt

Two years ago, I wrote an article about spurious timer table entries. Those entries occurred in the global timer table and resulted in unnecessarily scheduled DPCs. During a recent visit in Redmond, I had the chance to meet with one of the Windows kernel developers. By coincidence, he remembered my article and told me that with Windows 7 the issue has been fixed. Here is how they did it.

In the WRK, there are multiple timer lists, each list representing a certain multiple of the system time. Prior to Windows Server 2003, there were only 256 timer lists, while in the WRK and subsequent Windows versions the number of timer lists was raised to 512. This was mainly because of lock contention issues on the lock that protects a timer list.

The problem with 512 timer lists was that the field holding the information in which list a timer was placed, was and still is only 8 bits wide and thus capable of only holding 256 distinct values. However, Windows relies on that information when removing the timer from its list. If the timer list becomes empty, it has to be marked as such. When a timer is removed from a list greater than 255, Windows checks the wrong timer list for emptiness and may thus leave the original timer table entry in an inconsistent state which caused the timer interrupt to schedule unnecessary DPCs. More details on that can be found in my previous article.

In Windows 7, however, Microsoft decided to go with another strategy: instead of having a global timer table with X entries, each processor now has its own timer table. With this approach, the original lock contention issue could be solved and the number of timer table entries, or timer lists, could be reduced to 256. With that the overflow described above cannot happen anymore and spurious timer table entries can be avoided.

Comments