Weekly Edition
Return to the Kernel page
| |||||||||||||
The dynamic tick patch
The timer interrupt is one of the most predictable events on a Linux
system. Like a heartbeat, it pokes the kernel every so often (about every
1ms on most systems), enabling the kernel to note the passage of time, run
internal timers, etc. Most of the time, the timer interrupt handler just
does its job and nobody really notices.
There are times, however, when this interrupt can be unwelcome. Many processors, when idle, can go into a low-power state until some work comes along. To such processors, the timer interrupt looks like work. If there is nothing which actually needs to be done, however, then the processor might be powering up 1000 times per second for no real purpose. Timer interrupts can also be an issue on virtualized systems; if a system is hosting dozens of Linux instances simultaneously, the combined load from each instance's timer interrupt can add up to a substantial amount of work. So it has often been thought that there would be a benefit to turning off the timer interrupt when there is nothing for the system to do. Tony Lindgren's dynamic tick patch is another attempt to put a lid on the timer interrupt. This version of the patch only works on the i386 architecture, but it is simple enough that porting it to other platforms should not be particularly difficult. The core of the patch is a hook into the architecture-specific cpu_idle() function. If a processor has run out of work and is about to go idle, it first makes a call to dyn_tick_reprogram_timer(). That function checks to see whether all other processors on the system are idle; if at least one processor remains busy, the timer interrupt continues as always. Experience has shown that trying to play games with the timer interrupt while the system is loaded leads to a net loss in performance - the overhead of reprogramming the clock outweighs the savings. So, if the system is working, no changes are made to the timer. If, instead, all CPUs on the system are idle, there may be an opportunity to shut down the timer interrupt for a while. When the system goes idle, there are only two events which can create new work to do: the completion of an I/O operation or the expiration of an internal kernel timer. The dynamic tick code looks at when the next internal timer is set to go off, and figures it might be able to get away with turning off the hardware timer interrupt until then. After applying some tests (there are minimum and maximum allowable numbers of interrupts to skip), the code reprograms the hardware clock to interrupt after this time period, and puts the processor to sleep. At some point in the future, an interrupt will come along and wake the processor. It might be the clock interrupt which had been requested before, or it could be some other device - a keyboard or network interface, for example. The dynamic tick code hooks into the main interrupt handler, causing its own handler to be invoked for every interrupt on the system, regardless of source. This code will figure out how many clock interrupts were actually skipped, then loop calling do_timer_interrupt() until it catches up with the current time. Finally, the interrupt handler restores the regular timer interrupt, and the system continues as usual. The end result is a system which can drop down to about 6 timer interrupts per second when nothing is going on. That should eventually translate into welcome news for laptop users and virtual hosters running Linux. (Log in to post comments)
The dynamic tick patch Posted Jun 9, 2005 11:05 UTC (Thu) by dvrabel (subscriber, #9500) [Link] I can't seem to find any benchmarks or testing of real-world power-savings from this patch.
The patch is, presumably, putting the processor into a deeper sleep mode since the power savings from just reducing the timer tick frequency is minimal (if the CPU is 99.5% idle then making it 99.9% idle isn't a big different).
The dynamic tick patch Posted Jun 9, 2005 16:46 UTC (Thu) by iabervon (subscriber, #722) [Link] IIRC, the power savings doesn't come from the CPU being in sleep for more total time; it comes from switching into and out of sleep less often. There is some delay after the instruction to go to sleep before the power usage actually drops substantially, and, on an idle system, this is significant. It's a smaller effect, but generally similar to the reason that laptops want disk access bunched up instead of evenly spread.
Also, for a system where the virtual processor being idle means more time for other virtual processors, going from 99.5% idle to 99.9% idle means that the cost of an extra idle system is cut by a factor of 5.
The dynamic tick patch Posted Jun 9, 2005 11:27 UTC (Thu) by arnd (subscriber, #8866) [Link] Actually, this was first merged for the s390 architecture in 2.6.6, seehttp://lwn.net/Articles/82376/. As Tony writes, his patch is a port of the s390 code and similar patches are already used on some other platforms outside of the official kernel tree, e.g. the Xen linux code base.
The dynamic tick patch Posted Jun 9, 2005 15:53 UTC (Thu) by jg (subscriber, #17537) [Link] It turns out to take a lot of power to power up a CPU chip. It is much more than just the raw number of instructions that might execute.
So taking a 1000hz clock interrupt actually consumes a significant amount of power.
I don't know what the stats are for x86 in this area is though.
As an aside, other things take lots more power than you might naively expect. On StrongARM's of, say 3 years ago, the cost of a miss in cache to reference main memory was equivalent to executing of order a hundred
The dynamic tick patch Posted Jun 16, 2005 9:33 UTC (Thu) by farnz (guest, #17727) [Link] Also, most CPUs take a long time to switch from run to sleep; at 1kHz tick, there's a good chance that the "sleeping" CPU is actually running for a decent stretch of time. As they can switch back almost instantly, a good power saving technique is to try and maximise the time between a "go to sleep" command, and the next wakeup, which is exactly what dynamic ticks does.
The dynamic tick patch Posted Jun 16, 2005 5:31 UTC (Thu) by HalfMoon (guest, #3211) [Link] Worth noting: the i386 implementation was preceded by one for the OMAP processors ... ARM based system-on-chip processors you may well have in your cell phones, with some serious hardware support for power reduction. You know, where shaving a few milliWatts power here and there start to add up to more hours of battery life, getting you into that sixth day of unplugged operation... Unlike PCs these are designed with the expectation that parts of the system will go to sleep while others are still active. So putting the CPU to sleep may mean notable savings depending on how deeply it sleeps, and yet the whole system could still be streaming DMA through audio. Wasting power on waking up the CPU even just a hundred times per second (default HZ on ARM) would be bad.
The dynamic tick patch Posted Jun 17, 2005 5:52 UTC (Fri) by goaty (guest, #17783) [Link] Experience has shown that trying to play games with the timer interrupt while the system is loaded leads to a net loss in performance - the overhead of reprogramming the clock outweighs the savings.Does this mean that nanosleep() will never have resolution higher than a timer tick? That really sucks. Sometimes I despair of ever getting decent video playback on Linux. Last time I checked the X server couldn't even manage to sync to vsync, an operation that was trivial on the BBC Micro I had in 1985! At the moment a $50 TV with a $30 DVD player can achieve smoother DVD playback than Linux on a 2GHz workstation. Pathetic.
|
|||||||||||||