Forgot your password?
typodupeerror
Intel Bug Power Linux

Nailing the Cause of Recent Linux Power Issues 156

Posted by timothy
from the building-a-better-eyeball dept.
An anonymous reader writes "For the Linux kernel power regressions that were found a few months ago, and hit in Ubuntu 11.04, Phoronix has found the regression that's still present in the Linux 3.0 kernel. The power regression is caused by a change in ASPM, the Active-State Power Management, for PCI Express support."
This discussion has been archived. No new comments can be posted.

Nailing the Cause of Recent Linux Power Issues

Comments Filter:
  • "serious bug" my ass (Score:5, Interesting)

    by KiloByte (825081) on Monday June 27, 2011 @05:52AM (#36581712)

    The article is full of sensationalism like "serious bug", "major regression" to promote Phoronix and its "wonderful test suite". If you read it closely, you'll see they have seen a 10% increase in power consumption on just one of their test laptops that depends on BIOS settings. That particular laptop has a bug in its BIOS where it claims it wants to manage configuration of a particular piece of hardware, and new kernels obey that request. You can even tell the kernel to disregard BIOS and force power settings anyway.

    For me, improving power efficiency everywhere but that particular laptop is a major win. If you feel nice, you can even detect this particular buggy BIOS and ignore its request. But then, even after throrough fiddling, Phoronix guys weren't able to improve power usage by more than 15% even on this laptop, so it's not a big issue anyway.

  • by Manip (656104) on Monday June 27, 2011 @06:17AM (#36581760)
    That is an accurate summation of the article; but calling things "right" and "wrong" is a little nieve. Windows treats this information very differently to Linux, and BIOS manufacturers are caught between the two. Simply advertising ASPM sounds good, unless it causes Windows to treat card without ASPM support as if they have it just because the bios advertised that the system supported it. Now current versions of Windows might act rationally in this regard, but XP and older are still highly prevalent particularly amongst corporate clients and governments.

    So I guess my point is - it isn't a simple right or wrong/black or white scenario. It is a messy, ugly, undocumented hack, that ultimately leaves nobody happy. Linux will likely wind up having to implement a hack too to fix this, which makes them no better or no worse than the bios manufacturers who did exactly the same thing.
  • Re:tl;dr (Score:4, Interesting)

    by AlexiaDeath (1616055) on Monday June 27, 2011 @06:23AM (#36581788)
    It cant be a quick test either. Some machines start randomly hard locking with ASPM managed by the kernel. I have one of those. Uptime can vary from 5 minutes to 3 hours.
  • by fuzzyfuzzyfungus (1223518) on Monday June 27, 2011 @06:23AM (#36581796) Journal
    Hard to say without the exact specs of the machine, and probably a bunch of test-probes clipped in awkward places inside the laptop; but the overall trend in hardware does seem to have been toward ever higher theoretical maximum-if-we-felt-like-burning-that-much power draw(remember back when a ~50-80 watt CPU was considered a howling-mad-danger-to-self-and-others overclock/overvolt insanity demandng nerves of steel and custom cooling? Now boring retail CPUs have TDPs in the ~130 watt range); but a corresponding increase in the ability of hardware to throttle various clocks(CPU, GPU, high sped busses), sometimes cut Vcore as well, and turn off(or very nearly so) unused peripherals.

    Exactly where the delta exists vs. Windows seems to be a matter of some confusion; but unless Linux is just plain burning more CPU time for housekeeping purposes(which, one assumes, is the sort of things that the Big Serious Corporate users of 1000+ node commodity server/compute setups would have noticed by now), it likely rests largely in the hands of a (no doubt alarmingly large and ever changing) set of hardware-specific power throttling stuff whose responsibilities were designed to be divided between the buggy BIOS and the vendor's Windows drivers. If it were Just One Mistake, it'd likely have been quashed by now...
  • by fuzzyfuzzyfungus (1223518) on Monday June 27, 2011 @06:37AM (#36581830) Journal
    While this article is a touch overblown, stories like this make me profoundly pessimistic about the advent of EFI...

    Yeah, the BIOS pretty much sucks, and its horrible backwards-compatibility hackery makes purists cry; but the very fact that it sucks so much has had the basically positive effect of keeping vendors from trying to get too clever it. Given the results of their trying to do so(like everybody's favorite problem child, ACPI) this is probably a good thing.

    EFI, especially in conjunction with CPUs that have hardware level virtualization support, is pretty much an entire second OS, moonlighting as a bootloader, that you either have to perform coreboot-platform-port level black magic to replace(if the board even allows you, you might also have to defeat some sort of firmware integrity check) or lament unto your motherboard vendor in hope of getting fixed. If buggy BIOSes are an issue now, buggy EFI will be a fucking nightmare. The last thing we want is more and more stuff going on under the surface, with development handled by motherboard OEMs with, to put it charitably, no OS-development experience worth putting on a CV...

    At least the suckitude of the classic BIOS created a de-facto pressure toward "let the bootloader bootload and then GTFO so that the OS can handle things". Ideally, we could have just had a modern, lessons-learned, minimal bootloader, that could skip the brief sojourn to the 80s; but still bugger off as fast as possible. Instead, we are facing the looming advent of having every computer running two OSes with hardware access, even after the bootloading is done, the resultant messy(but model/firmware-revision specific) infighting of which are going to make ACPI look like an architecturally elegant story of idyllic peaceful cooperation...
  • That is an accurate summation of the article; but calling things "right" and "wrong" is a little nieve. Windows treats this information very differently to Linux, and BIOS manufacturers are caught between the two.

    In other cases this has been because microsoft wrote the tools and designed them to be hostile to Linux, e.g. ACPI. is there any of that here?

  • by jonamous++ (1687704) on Monday June 27, 2011 @07:28AM (#36582006)
    I'm using a Vaio S that gets 7+hr battery life in Windows, and under 2hr battery life in Fedora. The big problem that I see with this laptop is that Fedora is not utilizing the "hybrid" graphics system, and it is constantly running off of the graphics card instead of the integrated graphics (in windows, this brings the battery life to under 2 hours, as well). It would be nice to be able to switch that permanently to integrated to get the battery life.
  • by fuzzyfuzzyfungus (1223518) on Monday June 27, 2011 @07:41AM (#36582044) Journal
    This behavior is by design:

    "One thing I find myself wondering about is whether we shouldn’t try and make the "ACPI" extensions somehow Windows specific.
    It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.
    Maybe there is no way Io avoid this problem but it does bother me. Maybe we couid define the APIs so that they work well with NT and not the others even if they are open."

    William H. Gates III [slated.org]
  • by jedidiah (1196) on Monday June 27, 2011 @08:35AM (#36582322) Homepage

    Yes. 30 years of Microsoft sabotaging competitors great and small does make it hard for anyone else to get a toe hold.

    As always, this situation depends on how demanding your expectations are and whether or not you can put up with crap you're forced to put up with.

    Microsoft thinks it needs dirty tricks and that it's product can't survive on it's own merit.

The universe does not have laws -- it has habits, and habits can be broken.

Working...