Nailing the Cause of Recent Linux Power Issues 156
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."
"serious bug" my ass (Score:5, Interesting)
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.
Re:Summary: not a Linux problem, but a BIOS proble (Score:5, Interesting)
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)
Re:Summary: not a Linux problem, but a BIOS proble (Score:5, Interesting)
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...
Re:"serious bug" my ass (Score:5, Interesting)
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...
Re:Summary: not a Linux problem, but a BIOS proble (Score:4, Interesting)
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?
Re:Summary: not a Linux problem, but a BIOS proble (Score:4, Interesting)
Re:"serious bug" my ass (Score:4, Interesting)
"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]
Re:Never upgrade your Linux... (Score:5, Interesting)
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.