Submitted by Linux Kernel 2.6.21 has been announced. Linus writes: “So the big change during 2.6.21 is all the timer changes to support a tickless system (and even with ticks, more varied time sources). Thanks (when it no longer broke for lots of people 😉 go to Thomas Gleixner and Ingo Molnar and a cadre of testers and coders.” More info here and here.
Linux Kernel 2.6.21 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
One of the bigger features of the 2.6.20 kernel was the kvm virtualization solution. One of the biggest features for 2.6.21 is the tickless kernel. It will improve energy efficiency and battery life among other times.
If you would rather not read through the shortlog, take a look here for a fairly comprehensive and easy to read list of changes:
http://kernelnewbies.org/Linux_2_6_21
My favorite changes were, V4linux, bttv cropping support, PS3 USB (this was great)and dynamic kernel command line.
Guys I want to ask about what about OSS is it completely dropped. becuase OSS has got many changes too.
dynamic kernel command line?
edit:
never mind, checked kernelnewbies
Edited 2007-04-26 17:09
What is a tickless system?
You know when you stop your car after a long drive, it “ticks” for a while after whilst it cools down..? Well, some servers were doing that too, so this prevents that now.
Edited 2007-04-26 07:55
Modded up for humor
This isn’t Slashdot. In my opinion we should continue to keep the OSnews comments filled with intelligent on-topic conversation. That means no stupid joke posts.
Opinions mean nothing when the mods of OSNews constantly allow such one liner jokes on all of their news stories. Sorry, but that’s how it is here.
As far as I understand it (but please bear in mind I’m no expert), tickless means that the kernel will not necessarily wake up periodically anymore.
Originally, a timer was programmed to generate an interrupt (“timer tick”) a fixed number of times per second, usually in the range of 100-1000 Hz. That also meant the processor would possibly wake from sleep that many times per second, causing unnecessary power consumption on a lightly loaded system.
A tickless system might disable the timer interrupt altogether when entering an idle state, so it will only wake up when an I/O device demands the attention of the kernel. Of course it would be re-enabled again as soon as multiple processes are competing for processor resources.
If anyone has corrections to the information stated above, please don’t hesitate to post them. I’m curious about the exact implications as well.
Well some part is missing. There are processes that want to be woken up after X milliseconds.
So the system has also to make sure to wake up at the next of these events.
A reasonable solution would be to disable the timer interrupt only of no process waits for a timing event, but if so, change the interrupt’s frequency according to it.
It is explained here: http://kernelnewbies.org/Linux_2_6_21#head-8547911895fda9cdff32a947…
Edited 2007-04-26 17:14
I haven’t studied the tickless kernel, but I ASSUME that this explains the basics:
Normally the kernel is issuing an interrupt every X milliseconds in order to preempt processes. These interrupts are (normally?) fired at a constant rate. These ticks can influence the power states, and make the CPU etc. change to a more active power state even though no preemption is needed.
The tickless kernel will not fire new clock-interrupts unless there are active processes and a need for preemption. The tickless kernel will only wait for external interrupts when all processes are idle.
This isn’t exactly how it works because I don’t know the number of times / second the kernel wakes up, but it is something like this…
Before:
1000 times / second, the kernel will wakeup and say, “Is there anything for me to do?” Each wakeup is called a ‘tick’. If there is nothing for it to do, it goes back to sleep. This wastes energy and cpu power.
Now:
Instead of polling every so often the kernel will only wakeup when there is actually something to do. Once more drivers are taking advantage of the tickless feature in the kernel, there will be less wakeups and less power used. This will be a *huge* gain in powersavings and battery life on laptops. It will also help with virtualization by speeding up virtualized guests.
Does that help any?
The phoronix test (a very, very simplistic test) suggests the the power savings is very small, but it’s measurable. I’d like to see a testcase that shows a significant (i.e. >10%) decrease in idle power consumption. My guess is that tickless will have a greater impact on virtualization performance than on power consumption. In any case, it’s a smart enhancement that should provide advantages without regressions, but the scale of these benefits remains to be seen.
AFAIK
1) currently even with tickless, the CPU doesn’t enter low power mode, when this will be added the power consumption should be lower.
2) if there are two event scheduled at nearly the same time, it would be interesting to regroup the scheduling of those events, this is planned also.
3) some userspace applications may have to be modified to avoid useless polling (I think a Python library used to do lot of polling).
So there’s still quite some work to do, still will the power consumption be really lower? I don’t know..
is 2.6.21 the kernel that finally integrates the new wifi stack?
No, like the linked article said, this is something that will be in one of the future kernels.
I’m interested to find out how much battery ‘performance’ is improved with this kernel. Likely I’ll install it in Feisty (and unfortunately loose new mac80211 bcm43xx driver that they pathched in, unless I do it myself).
Other important side is userspace. If HAL or any other daemon (or GNOME/KDE component, and even programs like web browser) polls something all the time, than of course CPU will not be idling that often (plus the additional overhead of frequent switching from/to powersave mode). Seriously, Linux still doesn’t match battery consumption of a 5+ years old Windows XP, I hope this kernel will change it (along with optimization of userspace stuff).
Perhaps this “benchmark” is worth something to you:
http://www.phoronix.com/scan.php?page=article&item=651&num=1
Notice that while 2.6.21 is tickless, it doesn’t use the CPU power saving modes when going tickless. In the future, when the kernel enters in tickless mode, the cpu power saving modes will be used, allowing to save more power
Seriously, Linux still doesn’t match battery consumption of a 5+ years old Windows XP
Doesn’t accord with my laptop experience – my “runtimes” were (freshly charged to total cutout):
XP – 2hrs 37mins
Xubuntu 6.06 – 3hrs 49mins
Odd one, that. Can’t retest because that was before I completely killed my battery with overwork
My main interest in a “tickless” kernel is for audio work – the kernel clock has fairly recently been changed from 1000hz to 250hz, and this blows out apps such as “Rosegarden”, which has to be run on a specially compiled kernel. Even most of then low-latency audio kernels miss this trick – AFAIK only the 64studio distro has a low-latency 1000hz kernel. My hope is that if the clock is “off” when idle the kernel developers will turn it up to 1000hz again when it is going.
Biteydog— I do highly recommend rolling your own kernel for audio work. I was a complete newbie a few years ago and compiling my kernel was a daunting task, but it’s actually pretty easy after the first couple tries. I guess what I mean to say is that changing the HZ setting from 250 back to 1000HZ is pretty easy (literally, the press of a few buttons) once you know how to roll your own.
from what I understand HAL doesn’t poll but rather listens, this one of the advantages of userspace.
Larry Finger maintains a cumulative patchset for released kernels with the latest wireless-dev stuff, it will cleanly apply to 2.6.21 if you want mac80211 and are going to roll your own anyways.
ftp://lwfinger.dynalias.org/patches/
There were some substantial improvements to the softmac bcm43xx drivers in 2.6.21. I can actually use my 4311 now without jumping through hoops; mac80211 is still a WIP, doesn’t work well for all the chipsets yet. But still, it’s nice to no longer curse my wifi or fiddle with ndiswrapper. With the latest development the bcm43xx team is doing, broadcom is becoming one of the better supported chipsets in the kernel… that speaks volumes to the work they’ve done…
Too bad Linuks sucks so bad that you need to recompile the whole Colonel every damn time you change the screen resolution and bugs are being added faster than they are being fixed. Version 2.8 to be released by Linuz Thorwall’s grandson in 2028…
nice try
Whatever happened to the smarter windups and the ‘artistry’ a troll would employ to bait his victims?
Trolls these days are just frigging lazy.
It is nice to have a captain of industry such as yourself add your insightful comments to the discussion
Definition of a “troll”: anyone who says or does something you do not like or agree with. “Trolling” is an expression that these days covers just about any sort of activity on the internet. Web discussions always end with someone calling someone else a troll, nazi, fascist, or anti-semite. Piss off.
Your post was not part of a discussion, merely a ranting insult. A “definition” of a word from someone who is incapable of spelling is inevitably rather suspect, anyway.
I suggest night classes, if you are old enough to attend. You might enjoy them, and maybe even get a life.
Could this improve audio quality? As I understand it, sometimes the kernel waking up repeatedly can cause fuzzier audio (due to the power surges), and infact, I have noticed a difference changing between 1000Hz and 100Hz in audio quality. Additionally, running a program that consumes all CPU can increase audio quality.
I assume if you used a large buffer and tickless kernel, audio quality could be better.
The only good solution for your problem is to:
a) use a good soundcard
b) use symmetric or optical out
Agreed. Use spdif.
I bought a card with spdif five years ago just for that purpose because I had my computer hooked up to my receiver and had a horrible hum on it.
I could fix some of the hum by taking a wire and sticking it in the ground plug of a power outlet and touching the other end to the back of the receiver, but it didn’t fix it completely.
That is the one good thing about sending digital signals. You can even use crappy wire to some extent (If you get the signal, it’ll be perfect).
Right. I see so many people buying $200 sound cards (and higher) and just using the SPDIF outputs. The value of these high-end cards is the quality of their analog outputs. If your motherboard has an SPDIF output onboard, then that’s all you need, even if you’ll be hooking it to professional studio monitors or a Bose home theater system. That’s the beauty of digital media.
Oh, yes, of course. The solution that I was talking about was an “acceptable” solution, given the machine in question was a laptop. They tend to have sound shielding issues and such.
you can operate on battery 😉
you can also try out to use some DI Unit then (if plugging off the power connector helps, those will help, too), if you don’t want to buy a USB soundcard or D/A:
http://en.wikipedia.org/wiki/DI_unit
There are such units for your purpose, too. they work the same but don’t have XLR connectors
New linux Kernel + KDE 4 = Marketshare gains
So what was the timers for?
To interupt the kernel’s process schedular and then CPU when Linux wants to perform a context switch between multiple running processes?
Is it used for interupting the kernel when an I/O device device wants the CPUs attention? If so, how is an idle system returned from standby when interrupt ticks are disabled?
Yes – when processes are running the timer would go off 1000 times a second and the scheduler would then decide if it wanted to switch to another process. I believe this still happens, with the difference that when the kernel is in the idle loop and not running any processes the timer no longer fires.
When an I/O device wants attention it just creates an interrupt (not a timer interrupt), which hasn’t changed from before.
Edited 2007-04-26 19:13
When a CPU is running the idle task (basically just sleeping) and is in tickless mode, the only events that can wake up the CPU is a hardware interrupt. This doesn’t necessarily mean an I/O interrupt. For example, on an SMP system, an idle CPU might be woken up because the scheduler (called by an active CPU) rebalanced the runqueues, and there is now work for the previously idle CPU.
Note that tickless currently doesn’t use the CPU’s low-power states when idle, but it will in the future. Also note that on most current multi-core CPUs, the cores are on the same power management plane, so even if one core is idle, it will run at the same power level as an active core. Future CPUs will have independent power planes for each core.
If we really want to get serious about power management on Linux, then we need to get behind LinuxBIOS and push hard on chipset and motherboard vendors.
Save yourself the trouble of looking for the option in your kernel config if you are using a 64-bit architecture. I was so excited about this feature finally being merged that I didn’t read the fine print but apparently dynticks is only available on x86 for now. I guess I’m going to have to wait until 2.6.22, hopefully devicescape will be in by then too.