Linus Torvalds announced the first release candidate for the upcoming 2.6.21 kernel, ending the two-week merge window [story], "there's a lot of changes, as is usual for an -rc1 thing, but at least so far it would seem that 2.6.20 has been a good base, and I don't think we have anything *really* scary here." Linus noted that the tickless kernel patch [story] was finally merged into the mainline kernel, "the most interesting core change may be the dyntick/nohz one, where timer ticks will only happen when needed. It's been brewing for a _loong_ time, but it's in the standard kernel now as an option." Thomas Gleixner explained a year ago how this could result in cooler CPUs and power savings, "the tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer interrupts: if there is no timer to be expired for say 1.5 seconds when the system goes idle, then the system will stay totally idle for 1.5 seconds."
As for the rest of the changes, Linus added, "there's a ton of architecture updates (arm, mips, powerpc, x86, you name it), ACPI updates, and lots of driver work. And just a lot of cleanups." Release candidate kernels can be downloaded from your nearest kernel.org mirror. You can browse through all the changes using the gitweb interface. Kernel Newbiews maintains a useful summary of all the changes going into the latest version of the Linux kernel.
From: Linus Torvalds [email blocked] To: Linux Kernel Mailing List [email blocked] Subject: Linux 2.6.21-rc1 Date: Tue, 20 Feb 2007 20:53:45 -0800 (PST) Ok, the merge window for 2.6.21 has closed, and -rc1 is out there. There's a lot of changes, as is usual for an -rc1 thing, but at least so far it would seem that 2.6.20 has been a good base, and I don't think we have anything *really* scary here. The most interesting core change may be the dyntick/nohz one, where timer ticks will only happen when needed. It's been brewing for a _loong_ time, but it's in the standard kernel now as an option. But there's a ton of architecture updates (arm, mips, powerpc, x86, you name it), ACPI updates, and lots of driver work. And just a lot of cleanups. Have fun, Linus
dyntick outside virtualization?
The description of the dynticks patch sound like it could help saving power for any linux, especially laptops, while the patch looks like it depends on paravirtualization.
So is this going to help only kernels running under paravirtualization or not?
Thanks.
Disclaimer: I only have a
Disclaimer: I only have a vague clue.
It probably depends on whether your system has a reprogrammable timer whose programming does not incur too much overhead/latency. I remember reading that this is a problem with some systems. Though desktop computers have a variety of different timers/alarms, so it might just be the problem of a single one of them.
With paravirtualization, though, the supervisor will inherently have control over all the timers. Thus, guest VMs can always offload timers to the supervisor, and the supervisor may choose to either use ticks for scheduling, or rely on the system's reprogrammable timer.
Why is your opinion that
Why is your opinion that wheater the system has reprogrammable timer whose programming does not incur too much overhead/latency.
Please could you point me to the link where you read this.
It is extremely important to
It is extremely important to embedded systems as well. On the OMAP platform we use have used it for almost 2 years e.g Nokia 770, N800.
Not paravirt-dependent
It helps all kernels, paravirtualised or not, by holding the system in idle for longer. For a laptop, it helps by allowing the system to stay in deep sleep states for longer.
The reason it's most helpful for paravirtulized kernels is that all interrupts involve context switching; in the case of a paravirt kernel, a timer interrupt is one switch to the hypervisor, then one to the guest kernel. By allowing an idle guest to stay at idle until it actually needs CPU time, you don't waste CPU cycles that could be allocated to another guest.
Bit different.
> [...] all interrupts involve context switching [...]
Not under Linux. Interrupts do have only minimalistic context under Linux and the scheduling tick interrupt doesn't have any heavy processing - increment time & check with scheduler.
The patch was relevant back 5 years ago on embedded systems - where influence of periodic tick was very noticeable on overall performance of system. On desktop systems, such interrupts are handled instantly and Linux scheduler now is also very very fast. One redundant interrupt per millisecond doesn't hurt.
Notebooks might gain something, though on modern idle CPU, one interrupt per millisecond really looks like "very rare occurrence" - remaining millions of cycles are still properly spent in CPU sleep/low power/idle mode (activated by Linux scheduler in absence of work).
How does Linux prevent the hardware context switch?
There's still a context switch, even under Linux (at least on the CPUs I'm familiar with - PowerPC, ARM, mobile x86), as the processor switches to an interrupt context from whatever context it was in; it's not a huge deal on non-paravirtualised kernels, since (as you say), the interrupt context is lightweight.
And I disagree with your claim that "one redundant interrupt per millisecond doesn't hurt". Again, on the CPUs I'm familiar with, there are relatively hefty power drains in entering and leaving deep sleep states; the longer you can stay in deep sleep, the less often you pay this penalty - on one PowerPC core I've dealt with, it's not worth deep sleeping for less than 15ms, as the wakeup cost is so high.
Further, in a paravirtualised setup, the context switches aren't nearly so lightweight (which is why it's most helpful on paravirtualised systems), since you have to enter the hypervisor in the interrupt context to set up the guest context for handling the interrupt.
Once dynticks has settled down, the big deal it enables (in terms of power saving) is timer batching. A lot of time-related things in the kernel aren't particularly critical (think timeouts on networking and the like); if these time events can be "fuzzed" by the timer core, such that two timeouts close together are merged into a single wakeup, you get longer periods in deep sleep.
not THAT different on desktops/laptops
Thing is, laptop, desktop, and server CPUs have been adopting the same techniques used for years on embedded system-on-chip (SOC) configurations. So it's wrong to think this stopped mattering at any point.
If you can prevent IRQs from arriving for most of a second, which is something the dyntick stuff enables (in conjunction with saner userspace than most distros include, which is a different issue) then you most certainly can save power by staying in, say, a C3 state the whole time.
Every cycle of the CPU clock burns power. Every timer IRQ takes thousands of CPU clock cycles. Every NEEDLESS timer IRQ *wastes* all of those cycles. QED. It doesn't matter how efficient the scheduler is, when all you're making it do is waste energy. That translates to shorter laptop battery life, hotter desktops, higher power bills for your server farm.
saner userspaces
in conjunction with saner userspace than most distros include,
Would you mind expanding upon what a "saner" userspace is, and which distros already include one?
How many CPU cycles are
How many CPU cycles are wasted in the logic attempting to batch wakeup events so that the timer can be masked?
Does it solve
Does it solve http://www.securityfocus.com/bid/22539/info ?
A. Nonyme
your link calls it resolved.
your link calls it resolved.
Where is that option?
Where is that option to enable dynamic ticks? I can't find it :/
Processor type and features
Processor type and features ->[*] Tickless System (Dynamic Ticks)
argh, it looks like it's a
argh, it looks like it's a x86 specific option...
Probably just for now
I imagine dynamic ticks requires hardware support from each arch. It doesn't seem like dyntick should be specific to x86 for long.
Didn't it originate on
Didn't it originate on another arch? Though I could be thinking of something else.
originally from s390
The initial patch came from Martin Schwidefsky, who worked on this for the s390 architecture. A patch implementing fully tickless operation was first posted in 2001 for 2.2 and 2.4 kernels, and finally in 2004 a patch was integrated in 2.6.6 with the architecture independent parts for skipping the timer tick during idle(), and the s390 specific backend. Later backends that were merged were for arm and uml, with the powerpc and i386 ones remaining out of tree until now.
Powerpc and x86_64 should be the next to get merged, maybe even within the next three years.
hardware support == one dual mode timer
A "clockevent" source is just an abstraction for a timer that can run in two modes: periodic (like a Periodic Interval Timer, a.k.a. "PIT"), or oneshot. If your hardware has such a timer, or can combine two timers to act like one, then it can support dyntick. Most hardware can do so.
ARM has supported dyntick for at least a couple years now, as a useful way to extend battery life. ISTR that Nokia funded that work for the Nokia 770 tablet, which uses OMAP1 processors. I've used the ARM dyntick on systems and regularly had average tick rates of 3/second, with ticks sometimes stretching out to once every two seconds (network timers, as I recall).
The reason it's taken so long to mainline this for x86 is that x86 hardware tends to be congenitally broken. Lots of timers, wired in all kinds of ways, which often don't work the way they're supposed to and interact rudely with CPU low power states (notably C3, the state one wants to leave the CPU in most of the time if possible).
The expectation is that this version is sufficiently generic that it will work not just for ARM and x86, but x86_64, PPC, and everything else that wants to invest the effort.
So maybe it's up to the arch maintainers?
The clockevent layer still has fingers back into the individual arches though. I imagine since clockevent's new, the arch-side implementation will need to come into the mainline via the arch trees' maintainers, wouldn't it? FWIW, LWN reports "The developers also have support for the x86_64 and ARM architectures, though that support has not been merged for 2.6.21; MIPS and PowerPC support is in the works as well."
As for x86... All I know is that to get my machine to boot I had to play around with the interrupt routing options ("nolapic"). That's at least part of the "wired in all kinds of ways" you refer to, I'd imagine. But, then, we're talking about a machine that, in its earlier years, used its keyboard controller (which was yet another CPU) to control one of its address lines...
Don't forget the reset
Don't forget the reset through keyboard controller...
*shudder*
Can't I, please? Pretty please? <:-)
Hah, I was having some
Hah, I was having some similar issues, thanks for your directions
Me too, solved it now. Heads
Me too, solved it now. Heads up
Battery Life and Cooling Comparison
I brought this topic up on another list I am part of where we were discussing the disparity that exists in battery life between Linux and Windows. I suggested to them that this particular change would move to close that gap. The question was then posed is Windows "tickless"? If so it could explain why batteries last longer and CPUs run cooler under Windows. If not, I am then still mystified. Does anyone here know?