2011 09/23/2009 09/04/2009 103 When a process does some number crunching for a while, without involving the kernel, the kernel still interrupts it HZ times per second to figure out if it has any work to do. With a system dedicated to doing such number crunching, the answer will almost always come up "no"; however, the kernel takes a while figuring out all the "no"s from various subsystems, every timer tick. On my system, the timer tick takes about 80us, every 1/HZ seconds; that represents a significant overhead. 80us out of every 1ms, for instance, means 8% overhead. Furthermore, the time taken varies, and the timer interrupts lead to jitter in the performance of the number crunching. The kernel has long had a "tickless" or "nohz" mechanism to shut down the timer tick when not needed, but this mechanism only works when idle, not when running. If every function currently polling from the timer tick could instead make use of an appropriate event, or just wait to get updated until the next time the kernel has work to do, the kernel could become entirely event-driven. A prototype[1] of a truly tickless Linux kernel demonstrated the improvement in performance and consistency demonstrated by removing the timer tick[2][3]. Making this a reality, though, requires reworking all the bits hanging off the timer tick. [1] http://lkml.org/lkml/2009/9/1/229 [2] http://lkml.org/lkml/2009/9/3/7 [3] http://ozlabs.org/~anton/linux/osjitter/ An event-driven kernel would improve throughput by decreasing interruptions, improve latency by removing large non-preemptible regions, improve consistency by eliminating the primary source of jitter, and improve power savings by getting done and back to sleep sooner. So, if the kernel has you ticked, come to this BoF, and we'll get you ticked off in a jiffy. 09/04/2009