Letting sleeping processors lie

The Linux kernel tries to save power by, among other things, halting the processor when there is no work to be done. The processor's sleep can be fitful, however; even when there is no work, the timer interrupt will continue to wake the processor every 1/1000 to 1/100 second. George Anzinger's new variable scheduling timeouts (VST) patch seeks to solve this problem by eliminating timer interrupts when there is nothing for that interrupt to do.

The kernel timer interrupt is responsible for keeping track of time for the kernel by updating the value of jiffies and handling other housekeeping and process accounting functions. When processing the timer interrupt, the kernel will periodically also check the timer list to see if any kernel timers have expired and if so, call the completion function for that timer. Timers in the kernel are one of the mechanisms used to schedule work that needs to be done in the future. In the absence of a running process, the only real work that needs to be done in the timer interrupt is the maintenance of the timer list.

When no processes are running, the VST patch causes the idle task to scan the timer list and delay the timer interrupt if there are no timers that will expire in the next timer tick. It does this by changing the value in the Programmable Interrupt Timer (PIT) to generate an interrupt when the next timer is set to expire. The resolution of the PIT only allows values up to about 50ms and thus that is currently the limit of how long a timer interrupt can be held off, but there are plans to use the Real Time Clock hardware in the future to remove this restriction. When the timer interrupt eventually occurs, the VST code will update jiffies and do the necessary housekeeping to handle the amount of time that has been missed.

If the system is idle, there are no runnable tasks currently active, but an interrupt from the hardware could change that situation. To handle this case, the VST patch hooks into the low-level interrupt handling code to re-enable the timer interrupt when another interrupt occurs. It also runs the timer interrupt service routine at that time to update the kernel time information as if the timer interrupts had occurred normally.

The benefit of this patch is that when the system is idle the kernel can halt the processor in order to conserve power. Eliminating needless timer interrupts help to keep the processor idle longer. The result is that battery operated Linux based devices can operate longer on a single charge, which should make PDA and laptop users happier. As of this writing, there are no hard numbers on how well this patch reduces power consumption, hopefully some information on that will be forthcoming.

Index entries for this article
GuestArticles	Edge, Jake

---

to post comments

Letting sleeping processors lie

Posted Oct 16, 2003 1:49 UTC (Thu) by jdike (subscriber, #4055) [Link]

This feature is also highly desired by virtual machine people, i.e. UML and S/390. The reason is that a bunch of 1000 HZ VMs on a host generate 1000 timer interrupts per second per virtual machine. This is useless work for the host, and quickly adds up to a noticable load.

Virtual machines would use VST by delaying the next timer from the host until they actually have something to do for that tick. So, an idle virtual machine would consume no host CPU.

Jeff

2.4 vs 2.6

Posted Oct 16, 2003 2:57 UTC (Thu) by ncm (guest, #165) [Link]

It seems worth noting, as a matter of course, whether a given patch is meant for the 2.4 or 2.6 kernel series. This one applies to 2.4, but of course will be ported to 2.6 someday.

Letting sleeping processors lie

Posted Oct 16, 2003 20:58 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (3 responses)

How is this better than the earlier "no-tick" patches by Martin Schwidefsky, which were described in the Kernel section of the 12-APR-2001 issue of LWM under the heading "No more jiffies?"

Eliminating jiffies entirely seems a lot cleaner than VST. "No-tick" was rejected by the same Mr. Anzinger that is now pushing VST, on the basis that "no-tick" imposed extra overhead, yet VST seems to have exactly the same overhead for a less significant degree of benefit.

Thirty months later, I would have expected something better. Sigh.

Letting sleeping processors lie

Posted Oct 18, 2003 21:08 UTC (Sat) by giraffedata (guest, #1954) [Link]

Well, for one thing the patch described there is for IBM Z processors (aka S/360, S/370, S/390, et al) only. It exploits the fact that the Z has a full precision, fully accurate real time clock integrated into the CPU. Most systems on which Linux runs do not have that. They have a decrepit ISA clock that will tell you the curent time within a second, and gain or lose a few seconds a week. And it takes I/O to query it.

Letting sleeping processors lie

Posted Oct 23, 2003 23:27 UTC (Thu) by georgeanz (guest, #16234) [Link] (1 responses)

The "tick less" system was put together with instrumentation and proved to be overload prone. The problem is that entry and removal of one (or more) timers is required each context switch to keep track of the time slice and process time limits. This overhead increases as the load (i.e number of context switches per second) increases and was shown to cross over the flat overhead of a normal ticking system as a relatively low load.

Thus, since we really want less overhead with increasing load, and never more, I rejected the "tick less" system.

The VST code, on the other hand, fades away when the system is busy and only takes from idle time to do its thing.

I still have the "tick less" system patch on source forge for those who what to look at this in more detail. See: http://sourceforge.net/projects/high-res-timers/

Letting sleeping processors lie

Posted Nov 13, 2003 9:29 UTC (Thu) by brouhaha (subscriber, #1698) [Link]

Good explanation, thanks. I should have been less hasty to complain.