The Linux Kernel Power Problems On Older Desktop Hardware

[fewt]

Are we still beating this dead horse? This power bug doesn't exist, and sadly I'm starting to believe it is being reported on for the sole purpose of driving hits.

No, the sky is not falling. Yes, I have used my netbook for 10 hours with kernel 2.6.39 and yes I still had battery left afterwards.

Time to let it go and move on, or actually spend time finding the problem instead of writing articles about it.

Sorry to be so blunt, but people are actually believing this even though there is NO evidence that it's real.

[ioannis]

The first graph is completely meaningless because it seems that there are different numbers of idle samples to busy samples between kernels.

Of course if you have more idle points than busy points you're going to have a lower average power. The idle points vs the Busy points are easy to see from the graph. Now look at the ratio of I to B:

KV      I to B     I/B     Av pwr
------===========================
2.6.34  14 to 1    14      54
2.6.35  10 to 3     3.3    59.3
2.6.36   9 to 1     9      57.6
2.6.37   8 to 3     2.6    60.4
2.6.38   9 to 4     2.25   65.6
2.6.39  10 to 4     2.5    66.4
3.0.00   8 to 5     1.6    70.5

Now sort them by the I/B and notice the average power magically gets sorted too (except for one point which is probably close enough to be within the margin of error).

KV      I to B     I/B     Av pwr
===================-----=========
2.6.34  14 to 1    14      54
2.6.36   9 to 1     9      57.6
2.6.35  10 to 3     3.3    59.3
2.6.37   8 to 3     2.6    60.4
2.6.39  10 to 4     2.5    66.4
2.6.38   9 to 4     2.25   65.6
3.0.00   8 to 5     1.6    70.5

[sarcasm]OMG the ones with a lower I/B are on a power binge!!![/sarcasm] Completely useless.

The rest of the graphs are more interesting, mostly because they don't seem to be fundamentally flawed. However, they don't really show that power consumption is that much worse off.

Of course since the entire article seems to hinge on the first graph...

Exactly!!!

and as someone else pointed out, looking at the first graph, it looks like a difference in how the speedstep is being used, i.e. enabled post 2.6.34 and tune/tweaked afterwords. Seems that 3.0 has a more 'aggressive' response to load. I don't actually see any so called power regression on the 2.6.38, at least on this hardware. If anything, .38 seems to have a more 'relaxed' recovery from idle.

[deanjo]

Yes, I have used my netbook for 10 hours with kernel 2.6.39 and yes I still had battery left afterwards.

"Works for me" is never proof of something working fine for everyone and the people that are experiencing the issue are seeing differences in battery life by simply swapping the kernel for an older one.

[fewt]

"Works for me" is never proof of something working fine for everyone and the people that are experiencing the issue are seeing differences in battery life by simply swapping the kernel for an older one.

I agree, however "WorksForMe" isn't at play here, since I have pretty extensive knowledge of power saving techniques on this platform.

I did write Jupiter after all.

People aren't seeing differences in battery life by simply swapping the kernel, if you look at the bug report on Launchpad the majority of them would save battery life simply by properly testing.

Most of the people confirming the "bug" have web browsers and other applications open that of course cause wakeups. That's simply what applications do.

Don't make assumptions.

[deanjo]

Most of the people confirming the "bug" have web browsers and other applications open that of course cause wakeups. That's simply what applications do.

Don't make assumptions.

"Most" are not all. Don't make assumptions. It is however reasonable to think that those that did have browsers open also had them open in both instances, with older kernel and new.

[fewt]

"Most" are not all. Don't make assumptions. It is however reasonable to think that those that did have browsers open also had them open in both instances, with older kernel and new.

Again you make assumptions. I looked at each and every comment in the bug report and discredited nearly all of them almost two weeks ago.

From report #760131
Comment #1 - chromium-browser, PS/2 keyboard/mouse/touchpad interrupt, thunderbird-bin, gwibber-service, ubuntuone-syncd, desktopcouch - The system is not idle, non-idle systems cannot have sub 200 wakeups, as they system is busy being used.

Comment #10 - chrome, iwlagn - System is busy being used, and not idle.

Comment #12 - 91 wakeups, looks pretty idle

Comment #13 - firefox, gtk-gnash, mc, wget, grep - Not an idle system

Comment #51 - First result, fairly idle and < 100 wakeups. Second result - gwibber, nautilus, etc - Not idle

Comment #54 - The entire process list isn't included, invalid.

Comment #53 - Sub 100 wakeups

Comment #65 - The entire process list isn't included, invalid.

Comment #66 - Chromium, Docky - System not idle

Comment #67 - 21 wakeups

Comment #82 - USB OPTICAL MOUSE .. USB input devices drain batteries and cause wakeups. There are other external devices connected.

Comment #85 - PS/2 keyboard/mouse/touchpad interrupt - Not idle, and incomplete process list.

All of the reports are using Powertop 1.13, but kernels newer than 2.6.36 (that some people were using) need 1.97.

This report seems to be filled with comments by people that don't know how to test for issues like the one being reported. That's not a problem with the reporters, as they just don't know how to test it which isn't their fault.

To properly test it, the system should be completely idle with all applications closed, and all external keyboards, mice, hard drives, flash drives, or whatever disconnected. You can't have a busy system and expect the processor to stay sleep, that is simply illogical.

I know you are trying to defend the article, but this is ridiculous. Phoronix was given the benefit of the doubt, and has had plenty of time to "bisect the issue". All this article does is continue to claim that the sky is falling, but if you look outside you will find that the sky is certainly NOT falling.

If it were we would have credible reports and not just one tinfoil hat article, and the resulting bug reports from the paranoia that it caused.

[deanjo]

Again you make assumptions. I looked at each and every comment in the bug report and discredited nearly all of them almost two weeks ago.

I know you are trying to defend the article, but this is ridiculous. Phoronix was given the benefit of the doubt, and has had plenty of time to "bisect the issue". All this article does is continue to claim that the sky is falling, but if you look outside you will find that the sky is certainly NOT falling.

If it were we would have credible reports and not just one tinfoil hat article, and the resulting bug reports from the paranoia that it caused.

What you did is not discredit them but offered alternative options on your pure speculation. You offered your theory, nothing more. Alternatively Michael is actually doing the school work to find the reason for the regressions he is observing.

[fewt]

What you did is not discredit them but offered alternative options on your pure speculation. You offered your theory, nothing more. Alternatively Michael is actually doing the school work to find the reason for the regressions he is observing.

By "theory" you mean practice, practice which happens to be in the realm of Linux power management.

Something that I have deep roots in and years of experience with.

Not to mention the thousands of users of my product that improves power savings .. on the Linux platform. None of which have filed a bug report, or made mere mention of battery life issues with any recent kernel.

Because those issues don't exist.

I also happen to have experience with product testing, and believe me they are all doing it wrong. There is no control group, and the test reports are all over the map. You can't confirm anything by it except that the testing itself is invalid.

Michael has had enough time to find the issue, and he's come up empty. The closest thing we have seen to a "real" power related issue is the patch for the cpuidle bug that was pulled into 2.6.39.1.

Too bad you don't like what I have to say but Phoronix is wrong, get over it.

[deanjo]

By "theory" you mean practice, practice which happens to be in the realm of Linux power management.

Something that I have deep roots in and years of experience with.

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.

Not to mention the thousands of users of my product that improves power savings .. on the Linux platform. None of which have filed a bug report, or made mere mention of battery life issues with any recent kernel.

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.

I also happen to have experience with product testing, and believe me they are all doing it wrong. There is no control group, and the test reports are all over the map. You can't confirm anything by it except that the testing itself is invalid.

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.

Michael has had enough time to find the issue, and he's come up empty.

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

Too bad you don't like what I have to say but Phoronix is wrong, get over it.

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.

[dungeon]

The Radeon DRM changes in the Linux 2.6.33 kernel related to the R200 series includes 3DC compression support, support for external TMDS on older hardware, and reworked Radeon object handling.

Nope, these are mainly for R300, nothing for R200.

While the Radeon 9200PRO graphics card has regressed, even with the Linux 2.6.32 kernel the open-source Mesa driver and DRM do not result in a playable experience for this game at 1280 x 1024.

r200 just regresseed with transition to KMS! Mesa regressed! If someone needs excellent GL performance, compatibility and lowest mesa/r200 bug level on R200 based cards s/he (so do I) could use UMS and mesa-7.5.2 (yep, 7.5 is 2 years old but still could be used with current X, current DDX and current kernel).

It is all metter of software combo you (want to) run.