CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

[phoronix]

Phoronix: CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

Support for "full dynticks" has been accepted into the mainline Linux 3.10 kernel...

http://www.phoronix.com/vr.php?view=MTM2NTM

[Rexilion]

Three cycles of preparing work and finally a request for a pull containing relatively untested patches.

So I haven't actually found a real load where any of this makes a noticeable *difference*.

Quite the risk if you ask me...

[Vash63]

Three cycles of preparing work and finally a request for a pull containing relatively untested patches.



Quite the risk if you ask me...

Did someone say that you had to configure your kernel using it? What's so dangerous about it? I'm sure all of the 'stable' distros are going to stay away for a couple years anyway.

[Rexilion]

Did someone say that you had to configure your kernel using it?

No, did I mention that?

What's so dangerous about it?

Many regressions, few gains.

I'm sure all of the 'stable' distros are going to stay away for a couple years anyway.

Causing less testing coverage since there are now multiple ways to configure a single kernel.

Just my opinion though.

[ypnos]

This feature is a major evolutionary step in modern operating system kernel development.

I am happy to see that the Linux kernel developers embrace new technologies. We don't need a copycat kernel just as well as we don't need a copycat desktop environment. As was said erlier, the common user of the kernel is not affected at all by introducing this new feature until benefits for the general usage will surface and regressions are ruled out.

[uid313]

Asynchronous CPU?

Would this be useful on a clockless asynchronous CPU?

I wish there were more asynchronous processors on the market, it seems like an interesting idea...

[schmidtbag]

Did someone say that you had to configure your kernel using it? What's so dangerous about it? I'm sure all of the 'stable' distros are going to stay away for a couple years anyway.

Right so why pull it? Unless it were to replace the old one, or if the developers of it could point out a particular task where this worked well, then this wasn't worth pulling.

[AJenbo]

Right so why pull it? Unless it were to replace the old one, or if the developers of it could point out a particular task where this worked well, then this wasn't worth pulling.

To make it available for testing.

[Rexilion]

To make it available for testing.

No...........

[Wildfire]

Causing less testing coverage since there are now multiple ways to configure a single kernel.

Just my opinion though.

Last time I built a kernel, there were thousands of configuration options One more is hardly gonna hurt...

Whether or not a particular option is used depends on the distro/target audience. As the article mentions this option is currently experimental (the kernel has always contained a few of those, you'll only see them if you tick "show experimental stuff"). Unless this option offers improvements for the average user, most distros will keep clear anyway. My guess: You'll not see this option in action any time soon, unless you build your own kernel.

Would this be useful on a clockless asynchronous CPU?

The kernel's ticks and the CPU's clock rate are not related. A kernel that wakes up periodically potentially uses more power, whether the CPU is synchronous or asynchronous. Also, by "more" you mean "any relevant to the average user at all", right?