Check out the new USENIX Web site. next up previous
Next: Performance Evaluation Up: FastMessages Previous: FastMessages

Communication and DSM Server Threads

Application threads run as native kernel threads of the operating system. When started, they invoke a wrapper routine that installs the MILLIPAGE exception handler and calls the original main thread routine. Aside from this, the application code is executed as is and application threads experience no interference unless they fault.

In addition to the application threads, MILLIPAGE spawns three threads that are in charge of maintaining the memory consistency and servicing requests: two DSM server threads and a millisecond timer thread. One DSM server thread, called the poller, is constantly polling for messages in a busy loop. It promptly serves received messages, then continues to poll. The poller runs at a low priority; it does not consume cpu cycles when required by application threads. Another thread, called the sweeper, differs from the poller only in that it waits on an event before it issues a single poll.

 Ideally, we would let the sweeper sleep for periods of a few hundred microseconds, maximizing responsiveness without overloading the cpu. However, high resolution timers are provided in Windows-NT only through multimedia timers, of which the finest resolution is 1ms. Therefore, a third thread, the timer, was used to set up an event to wake up the sweeper once in every millisecond. For higher accuracy, and since it consumes, over a period of a millisecond, very little time, the priority of the sweeper was set to exceed that of the application threads. Note that the multimedia timer thread runs in high priority as well.

Our measurements showed that the deviation in the time between timer events is extreme: most of them appear either within several tens of microseconds, which overloads the cpu, or take several milliseconds, which degrades responsiveness. We have found that this anomaly of the Windows-NT timers has been recently reported in [11], where a standard deviation of 955 microseconds was measured for 1ms timers on similar hardware - nearly equal to the mean! Since polling is in the core of our system, the timer inaccuracy significantly affected the responsiveness of the DSM server threads, and thus the overall performance of MILLIPAGE.


next up previous
Next: Performance Evaluation Up: FastMessages Previous: FastMessages
Ayal Itzkovitz and Assaf Schuster, The Technion