The Linux Kernel Power Problems On Older Desktop Hardware

[FunkyRider]

After some long and frustrating research myself, I think the "power saga" is a non issue too. The high wake ups was caused by my own acerfand and backlight fixing scripts which set in the background polling hardware status.

I finally came up with that conclusion after trying all possible kernels, those kernels behaves very nice on my desktop system are having ridiculously high wake ups on my laptop.

2.6.35, 2.6.37, 2.6.39 on my desktop: 10~20 wake ups per second
exact same kernels on laptop: 160~200 wake ups per second

Only after installing Powertop 1.97 it was able to show that my script was constantly banging the hardware access, which causes high wake ups.

Removing the acerfand script and backlight script makes the laptop behaves same as the desktop, 10~20 wake ups per second and 5.x watt idle power with screen on.

I think I will post a detailed topic on the discover of the issue: It is indeed userland issue.

[FunkyRider]

Also to the powertop users:

STOP RUNNING THE FRICKING WEB BROWSERS AND MOVING YOUR MOUSE LIKE CRAZY!

It is YOU that is waking up the CPU, nothing more!

[fewt]

Sorry but as a developer going on for close to two decades now that proves nothing. All it proves is that you were unable to replicate it. We have all seen bugs in software that have spanned years but because they were hard to reproduce or to nail down as to the exact cause. For example just recently I nailed down a bug that had eluded our company for years because the combination of criteria that had to be in play for it to act up was very specific (ATI card, window frame size of 1366x682 with a button on the gui stored in png format at a specific size as well). We have had reports for years about it but until recently have been able to do absolutely nothing to fix it as the triggers had to be in the exact combination.

Unable to replicate it because it does not exist, as I indicated.

Again that really doesn't prove anything. Until you can 100% prove and 100% replicate each of those reports you cannot say with certainty that they don't exist.

The reports are useless, if you can't or are unwilling to see that then I would question anything else that you have to say in relation to the issue.

As do I and many others have extensive experience in product testing as well. Is the environment that these testing ideal, absolutely not but they are about as good as they are going to get without massive manpower and financial backing. It is always easier to isolate an issue in a iron clad control environment but alas the whole open development movement doesn't exactly cater to that. You make do with what you have available.

It doesn't take massive manpower or financial backing, it simply takes coordination. You don't get that by writing articles about the sky falling. Nor do these articles improve credibility of Phoronix.

That statement right there can be proven wrong soooooooooo many times. Not all bugs are found and isolated so quickly. You can visit any bug tracker and see clear evidence of that especially where the bug is not a P1 "we really fucked up and severely borked the system rendering it useless".

Sure, but you have to prove there is a bug first. Making wild claims does not prove that there is a bug.

Again the only thing that you have proven is that you cannot reproduce or have observed it. In any type of research that is not proof of it existing or not being there.

As I said, it doesn't exist. Making lame excuses as to why I (and others) haven't seen it doesn't really help.

[deanjo]

Unable to replicate it because it does not exist, as I indicated.



The reports are useless, if you can't or are unwilling to see that then I would question anything else that you have to say in relation to the issue.



It doesn't take massive manpower or financial backing, it simply takes coordination. You don't get that by writing articles about the sky falling. Nor do these articles improve credibility of Phoronix.



Sure, but you have to prove there is a bug first. Making wild claims does not prove that there is a bug.



As I said, it doesn't exist. Making lame excuses as to why I (and others) haven't seen it doesn't really help.

You seem to miss an extremely simple concept here. Being not able to replicate is not proof that it does not exist. It only proves that you cannot replicate it.

[FunkyRider]

I think we have to pose some very basic requirement when collecting statistics data:

Which version of Powertop? Different version gives different result
Interacting with the machine? Invalid result
Having any client program running? Invalid result

I can see there is a lot of noise to the actual data, like samples where chrome is waking the CPU up 400 times/s, or touch pad/Mouse/PS2 is waking the CPU up 200 time/s, even a sample where nautilus is very active and doing 120/s CPU wakeup (What the hell people?), those are invalid data which should not be taken into account.

Unfortunately almost 90% data appeared on the internet fall into this (invalid) category. So the problem is definitely way over-reacted.

And even if you got the basics right, like my situation before, there are userland daemons which keeps the CPU busy. I would have never realized that a fan monitoring program is capable of waking CPU up 20-30 times per second, merely polling the sensor data. So, yeah, if you ran any third party scripts in the background, stop them.

Anyway, my rant goes on, learn how to use the tool first, before your data can be accepted as valid results. Don't just fire up Powertop then jerk around in the system to come up with a 1000/s wake up 'IDLE' stat, your machine is surely not frikking IDLE being jerked around by YOU.

[fewt]

You seem to miss an extremely simple concept here. Being not able to replicate is not proof that it does not exist. It only proves that you cannot replicate it.

I haven't missed any concept. To imply that I have shows that you either don't understand my comments, or that you are too arrogant to admit that I might be right.

Either way, it's your problem.

[deanjo]

I haven't missed any concept. To imply that I have shows that you either don't understand my comments, or that you are too arrogant to admit that I might be right.

Either way, it's your problem.

I never said you might not be right, but you have not proved that it doesn't exist. You say "This power bug doesn't exist" which is an absolute answer with no possibility of any chance that you might be missing something or unable to replicate. The only one displaying arrogance is you with your self confidence that what ever results you come up with has to be the only and absolute right answer.

[Artemis3]

Hey fewt, where are your tests that demonstrate the power usage across kernels has not changed? Until then, you have no right to discredit others.

I hope to see more tests, with actual facts and science done, not petty bickering in a forum based on beliefs.

[krazy]

What is up with the unlabelled axes on these graphs? And why do some of the plots appear to stop in the middle of the graph?

I also fail to see the "well-known" power regression.. can anyone explain where it is on the first plot?

This is a very confusing article.

[Jimmy]

I never said you might not be right, but you have not proved that it doesn't exist. You say "This power bug doesn't exist" which is an absolute answer with no possibility of any chance that you might be missing something or unable to replicate. The only one displaying arrogance is you with your self confidence that what ever results you come up with has to be the only and absolute right answer.

It's no worse than Phoronix insisting that it does exist while at the same time being unable to show it. This article in particular is not conclusive on the point yet it carries the title "The Linux Kernel Power Problems On Older Desktop Hardware." Yes, that's the title even though it fails to show an actual problem with recent kernels that supposedly have some killer widespread regression.

Just look at that graph and tell me that the average power shown there actually can mean a damned thing if each kernel is measured differently. There clearly are more idle samples than busy samples for some kernels. The 2.6.36 kernel is apparently so good that it only uses extra power for ONE sample, the last one. Does that realllllly sound reasonable? Why does the 2.6.36 have fewer samples for that kernel than any other kernel? Did it really play the video that fast or was it cut off for some reason?