Linux Kernel Power Bug Now High Importance In Ubuntu

[cyring]

That bug seems still opened
monitored with the powertop running with ArchLinux 64 bits, Linux 3.1.x
kworker threads display more than 60% of kernel wake-ups
when the last is idling
Btw, system is a Core i7 8 cores, speedstep, hyperthreading, C6 state, OC 3.2GHz, VTx, everythings activated

[cyring]

kworker

That bug seems still opened
monitored with the powertop running with ArchLinux 64 bits, Linux 3.1.x
kworker threads display more than 60% of kernel wake-ups
when the last is idling
Btw, system is a Core i7 8 cores, speedstep, hyperthreading, C6 state, OC 3.2GHz, VTx, everythings activated

[kokoko3k]

Good for me

Scared by this phoronix article, i decided to give 2.6.38.4 from archlinux packages a try.
Well, on this little asus eeepc 1005ha, this kernel shines, really.
It went from about 6.1-6.5W to 5.7..6.2W just idling.

What can i say, the bug of course isn't triggered for me.

[BlackStar]

Translation: They're not willing to pay me any money so that I divulge to them the commit id where the 'regression' was introduced.

Your translation is ridiculously wrong.

[AnonymousCoward]

It doesn't appear that they are devoting any resources to getting the issue resolved but it looks like they will be waiting for a fix to appear upstream in the stable series or in 2.6.39 and then to have that back-ported into an Ubuntu 11.04 SRU update.

Translation: They're not willing to pay me any money so that I divulge to them the commit id where the 'regression' was introduced.

[gururise]

Michael,

Thank you for bringing attention to this regression. Without Phoronix, this regression would have received very little, if any, attention.

Being a mobile user, I would definitely love to see the devs get to the bottom of this issue, whether it be an actual regression in the kernel, or a serious misconfiguration, either way, it still affects us and needs to be looked at.

Thanks again for PTS!

[fewt]

A) OK. In that case instead of a regression in the linux kernel itself we'd have a regression in the way one (more?) distribution are configuring their kernels. From the point of view of the users, it makes little practical difference.

Of course it makes little difference to the user, but we aren't talking about user impact, we are talking about root cause analysis.

B) I don't know. Maybe, I guess?

That's my point, it still isn't black and white. We can't blindly say that this is a kernel problem because the burden of proof hasn't been reached (in my opinion).

C) It's not like 2.6.37 required a new version of PowerTop. PowerTop required a recent kernel for some of its features to work. I don't see how this is relevant.

It was required for proper reporting. That is why it is relevant, and why I brought it up. Older versions of powertop do not report on the new changes, which led me to believe that Phoronix test suite may also need an update.

D) That the kernel doesn't tweak itself is a constant in these tests, therefore it can't explain the observed differences.

Sure it can, the kernel must be tuned differently for power vs battery.

We'll know soon enough, I guess.

Perhaps, but only if we look at the issue as a whole, and don't assume that it is just a kernel bug because it may just be a configuration problem (as I implied).

This doesn't mean that the configuration problem wouldn't be visible across distributions, because none of them (with the exception of a few designed for portables like mine, Fuduntu) reconfigure the running kernel when the applied power state changes.

[VinzC]

I'd just like to stress that thanks to the Phoronix Test Suite and how its widely spread, this problem can be narrowed down to when exactly the issue was introduced much faster. Without it the amount of code to inspect would have been drastically more important, IMHO.

Thanks to Michael for inspecting this issue!

[yotambien]

I can't explain them (there isn't enough data), however I believe that the problem could be:

A) The build options between kernel versions may be different
B) Something in userspace
C) The Phoronix test suite itself
(2.6.37 pretty much required a new version of Powertop, Phoronix test suite probably also needs an update)
D) The kernel doesn't tune itself for power / battery (requiring a userspace tool like Jupiter)

It is most likely that this is just a misconfiguration blown grossly out of proportion.

A) OK. In that case instead of a regression in the linux kernel itself we'd have a regression in the way one (more?) distribution are configuring their kernels. From the point of view of the users, it makes little practical difference.

B) I don't know. Maybe, I guess? It would have to be quite an important component of the system, and again, for users it would make not much difference. The way to test this would have to install 2 kernel versions. Some user in the forum did this and found a difference. I did and found none (but I can't measure anything).

C) It's not like 2.6.37 required a new version of PowerTop. PowerTop required a recent kernel for some of its features to work. I don't see how this is relevant.

D) That the kernel doesn't tweak itself is a constant in these tests, therefore it can't explain the observed differences.

We'll know soon enough, I guess.

[fewt]

So the mainline kernel PPA, Ubuntu kernel config, Arch Linux config, openSUSE config, Fedora config, and other peoples configurations, etc all went out of whack? There's been independent tests in all of those cases.

What data has been collected to verify these claims though? I don't mean any disrespect, I would just like to see a flood of data to analyze. The dataset that I posted in my initial comment seems to prove you wrong. If nothing else, it could be a good indicator of where to look for the root cause if it is a real problem by analyzing the content of /usr/lib/jupiter/kernel/{battery,power} since the issue does not appear to exist in Fuduntu with kernel 2.6.38.4.