OSNews

dynamic kernel command line?

edit:

never mind, checked kernelnewbies

Edited 2007-04-26 17:09

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..

No, like the linked article said, this is something that will be in one of the future kernels.

Perhaps this "benchmark" is worth something to you:

http://www.phoronix.com/scan.php?page=article&item=651&num=...

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...

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

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

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.