I would not be the least bit surprised if this regression is also hitting desktop and server Linux users too in making your systems less green. However, my only AC power meters do not have the ability to interface directly with the PC, so I am unable to check on their results without resorting to manually monitoring the meter's power display and thus no automatic Phoronix Test Suite monitoring.
As far as what commit is causing this very noticeable regression, that's unknown at the moment. While the Phoronix Test Suite can automatically bisect kernel regressions (and that in other software projects leveraging a version control system), and the Phoronix Test Suite natively supports sensor monitoring regardless of what's being tested (a feature that AMD's Tapper or Canonical's Abrek still lack), with this situation it's a bit harder than being able to have it be 100% automated due to needing to ensure the battery does not run out mid-test, among other reasons.
It's also time consuming from my current range of mobile devices with no longer having the System76 Sandy Bridge notebook around and Intel not yet having shipped a new Sandy Bridge notebook for the new Linux automated test farm. Depending upon interest level and potential ROI, this may end up being bisected to find the specific commit. I am just putting the information out here now as other kernel stakeholders can also likely reproduce this issue and bisect the problem if they so desire.
I'm also more than happy to show other organizations how to utilize the Phoronix Test Suite's sensor monitoring, its other extensible features, and integration with Phoromatic and OpenBenchmarking.org to detect this regression and other performance issues for the kernel. Or even for their own software projects and to do so in an automated manner either on a timed basis or per-commit for continuous integration. I will also be back in Munich, Nürnberg, and Frankfurt beginning late next week and then at UDS Budapest followed by the tail-end of Berlin LinuxTag if anyone would like me to happily demonstrate or to discuss Linux testing practices, etc. Let me know so that we can all improve this situation for Linux; clearly the status quo is insufficient if the problem's already been in one released kernel and is set to appear next week in Ubuntu 11.04.
More information to be published next week. More information will also likely come on my Twitter feed (where I usually break the news first) and then the Phoronix feed over the weekend as my investigation continues and stay tuned for the article on Monday with the complete set of results that led to the discovery of this regression that's been around for at least a few months.
UPDATE 1: Another test using the battery power usage test profile was carried out that monitors the battery usage when the system is again idling, idling while the display is turned off via DPMS, and then when the display is flipped back on and MPlayer is used to play a video clip. These results are uploaded to OpenBenchmarking.org and show that even when the display is off, the system is still consuming more power under the Linux 2.6.38 kernel, to eliminate any questions of whether the display backlight explains a power difference.
UPDATE 3: The regression will be bisected this weekend via the Phoronix Test Suite stack. Any Phoronix findings should be published on Sunday or Monday.
UPDATE 4: The Tests Showing Ubuntu 11.04 On A Power Consumption Binge is the prequel to this testing showing all of the original Ubuntu 11.04 power consumption benchmarks as the first sign of this major power problem.