GNU/Linux and openSUSE power management regressions

English Open Chat
#1

There are tidbits elsewhere in openSUSE forums on this possible Power Management regression topic, plus a number of articles on the Phornoix web site, and after a recommendation to do so, I thought I would start a blog entry on the GNU/Linux Power Management regressions impacting openSUSE, and some work arounds ( ! ).

Originally, my posts on this topic was in an openSUSE forum thread here: Possible Power Management regressions in recent Linux kernels ?

In that I noted that there have been a series of articles on the Phoronix web site, which have suggested regressions in the Linux kernel

  • during the 2.6.37 to 2.6.38 and
  • during the 2.6.34 to 2.6.35

with the 2.6.34 to 2.6.35 being discovered last.

Some quotes from the Phoronix web site posts …

FIRST, the 2.6.37 to 2.6.28 possible regression was discovered: [Phoronix] Mobile Users Beware: Linux Has Major Power Regression](Mobile Users Beware: Linux Has Major Power Regression - Phoronix) where they state:

During the Linux 2.6.38 kernel development, a regression was introduced causing systems to burn through significantly more power. … On the particular system being talked about in the article today is the power consumption going up by 14%, which would lead to a noticeably shorter battery life. … The Linux 2.6.35/2.6.36/2.6.37 results are virtually identical, but with 2.6.38 is where the regression strikes. As far as the Linux 2.6.39 results, it shows the regression still present. …
SECOND, the 2.6.34 to 2.6.35 possible regression, discovered [Phoronix] Another Major Linux Power Regression Spotted](http://www.phoronix.com/scan.php?page=article&item=linux_kernel_regress2&num=1) after Phoronix upgraded their benchmarks and paid more attention to power management in the results. Also, the 2.6.34 to 2.6.35 possible regression appeared worse than the 2.6.37 to 2.6.38.

With this expanded round of power testing, the Linux 2.6.37 to Linux 2.6.38 regression is still shown, but it also uncovered a very noticeable differentiation in power consumption between the Linux 2.6.34 and 2.6.35 kernels too. Under idle on this test system, it equates to a 20% difference in power consumption and then the 2.6.37/2.6.38 regression tacks on another 6% in this particular test profile.

… The pre-2.6.35 kernels are all running at right around the same power level within a reasonable milliwatt range of each other on the various tests. … However, with the Linux 2.6.35 kernel, the power consumption goes up noticeably.

Now the above is all from Phoronix.

There has also been more information of late:

USEFUL WORK AROUND

Its interesting that Phoronix are now suggesting that laptop users with newer kernels (2.6.27 and newer to present) consider adding the boot code:


pcie_aspm=force

to work around some of the power management issues.

The Phoronix article is here: [Phoronix] The Leading Cause Of The Recent Linux Kernel Power Problems](http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1)

Phoronix believe the biggest cause of the 2.6.38 power issue (according to their testing software and the hardware they have been running) is due to a change in behavior regarding ASPM. ASPM is the Active-State Power Management for PCI Express. Namely, they claime to blame is commit 2f671e2dbff6eb5ef4e2600adbec550c13b8fe72 that is titled “PCI: Disable ASPM if BIOS asks us to.”

Read more on the article to see the details.

Wrt the work around, they say this:

Given the thousands of users having this 2.6.38 power regression by this change, there is a big ASPM problem at hand. Fortunately, as PCI-E ASPM problems are not new, a few boot options can be used. Namely, most people affected by this issue will want to add “pcie_aspm=force” to their boot command line. Simply adding this will force Active-State Power Management to be enabled.

FURTHER ARTICLES

Further articles in Phoronix look at other Power Management issues :

with similar workloads, for the most part the power consumption is comparable between Ubuntu 11.04 and Windows 7 Pro SP1. The only major differences came during Flash-based HD video playback being more efficient under Windows, power consumption while OpenGL gaming, and in select other areas.

My guess is power management on openSUSE is likely similar to Ubuntu for basic desktop use, video playback, and gaming (Ubuntu is usually faster than openSUSE for boot up times). Ergo openSUSE possibly is comparable to Windows 7 for power management with basic desktop use and video playback.
.

  • open-source Radeon driver power management where Phoronix compared the system power consumption for the open and closed-source ATI/AMD Radeon Linux drivers for a variety of graphics cards (ATI Radeon HD 2400PRO, ATI Radeon HD 4550, ATI Radeon HD 4870, and ATI Radeon HD 5750). Phoronix discovered with with newer hardware the proprietary Catalyst driver consumes less power than using the open-source driver in any configuration. So not only does the proprietary Catalyst driver deliver better performance, but also its power consumption is lower.
    .
  • What to do if still seeing poor Linux Battery Life? In this post Phoronix ask user’s to try the work around noted above, and then if power management is still poor to provide further information per the links they provide, so that they can investigate the problem further and maybe help come up with a solution.
#2

There is a new article on Phoronix, dated 6-July-2011, where in this new article there are some power consumption and thermal tests when comparing the latest open-source “Nouveau” driver code against NVIDIA’s closed-source proprietary driver: [Phoronix] Nouveau Driver Power Management Against The NVIDIA Blob](http://www.phoronix.com/scan.php?page=article&item=nouveau_power_comparison&num=1)

According to Phoronix, testing went nearly the same as last week’s Radeon driver power management test.

Phoronix compared the open source Nouveau graphic driver vs the proprietary nVidia graphpic driver for the nVidia 8500GT, 8600GTS, 9500GT, and 9800GT graphic devices.

In general the propreitary graphic driver had significantly superior performance for equal or less power consumption.

#3

While on the topic of Power Management, I wanted to point to some other useful Internet content:

#4

oldcpu I found another interesting article on the latest kernels, Intel Sandy Bridge & Power Usage using Linux 3.x Kernels. Here is the article pointer:

http://www.h-online.com/open/features/Kernel-Comment-Untapped-power-saving-potential-1361906.html

Apparently turned off by default in kernels 3.0 and 3.1 referred to as RC6, you must add in the kernel loading option to turn back on: i915.i915_enable_rc6=1

To restore normal power savings when using the Sandy Bridge CPU and supporting Chipset this option must be added to the kernel load line in the grub menu.lst file for openSUSE. Laptops were reported to go from using around 15 (rc6 is on) to around 21.5 watts (rc6 off, now the default). This can make a big difference for new laptops running the most recent kernels while on battery power.

Thank You,

#5

thats interesting.

Phoronix also have an article on this " i915.i915_enable_rc6=1 " boot code: [Phoronix] Tweaks To Extend The Battery Life Of Intel Linux Notebooks](http://www.phoronix.com/scan.php?page=article&item=intel_i915_power&num=1) where they suggest:


i915.i915_enable_rc6=1

stating for “i915.i915_enable_rc6=1”:

RC6 was enabled by default for a while, but then it ended up being too buggy for some hardware configuration so it had to be disabled. For affected systems on the current code-base, enabling RC6 can cause GPU hangs. The Intel RC6 feature allows the GPU to enter a lower power state when the GPU is idling.

and in other cases:


i915.i915_enable_fbc=1

stating for “i915.i915_enable_fbc=1” :

This kernel option enables FBC (frame-buffer compression) for the Intel graphics driver. Frame-buffer compression is not enabled by default since for some systems when frame-buffer compression is active there is a bug where the screen is not being properly repainted when using a compositing window manager. As implied by the name, frame-buffer compression will compress the buffer of what’s to be drawn to the screen so that less memory bandwidth is used on screen refreshes, and as a result, less memory being confused.

and in other cases


i915.lvds_downclock=1

stating for “i915.lvds_downclock=1” :

This kernel option will down-clock the LVDS refresh rate, which can increase power savings as a result. However, for systems that do not properly support LVDS down-clocking, the screen can begin to flicker during use.

#6

Man are you putting this stuff altogether? While I do understand some items might create an issue when enabled, putting all of these back online might put the power consumption where it should be. It is very hard to imagine so may alleged issues all causing kernel power consumption, mainly on Laptops, to get so high. It is very interesting for sure.

Thank You,

#7

Intel RC6 power savings support disabling in 2.6.32 kernel is likely according to a recent Phoronix article.

First, I should provide a caveat on this series of blog postings - they are all 3rd party with no direct experience on my part, and my interest in this has waned a bit, as when I first started blogging on this subject, the GNU/Linux power regression issues were not so well known, and also others picked up on the Phoronix stories of GNU/Linux power regression. Recently Phoronix have had some articles on Power Regression in GNU/Linux specifically mentioning the Sandybridge and IvyBridge graphics, and given I installed openSUSE-12.1 on a laptop with Sandbybridge Graphics within the past week, my interest has come back.

I note Phoronix article in early December (entitled " RC6 To Be Flipped On For Sandy Bridge, Ivy Bridge " which commented that a patch to enable RC6 power-savings support on Intel SandyBridge and IvyBridge hardware where possible had been submitted to the GNU/Linux kernel. Purported this hardware feature can decrease power usage while also increasing performance in certain workloads. For SandyBridge (Gen6) hardware, RC6 will be enabled when IOMMU is not enabled while for the next-generation Ivy Bridge (Gen7) hardware, RC6 can safely be enabled always. For Ironlake and previous generations of Intel hardware, RC6 won’t be used by default.

However it appears now, there were concerns wrt the stability of the patch, as reflected in the Phoronix article article entitled " Intel Flip-Flops Again: RC6 Disabled For Linux 3.2 "

Now I blogged less than a week ago about installing openSUSE-12.1 on my wife’s Lenovo X220 laptop where that laptop has SandyBridge graphics. This is my wife’s laptop, where windows7 is her main OS, and hence access to that laptop on my part when the laptop is running openSUSE-12.1 is limited. Also, typically my access is when the laptop is using electric cable power (as opposed to needing battery power). So I have not yet tried the boot code that enables RC6 power savings support. So today being New Years day, a ‘New Years Resolution’ of mine will be to try that boot code on her laptop sometime, and see if I can better guage stabililty of the 2.6.31 kernel in the laptop while the RC6 boot code is enabled.

For the record, as noted in a previous post above in this blog, the boot code being mentioned is:


i915.i915_enable_rc6=1
#8

Found and interesting Link here, It starts off by saying …

Greg Kroah-Hartman has released long-term kernel 3.0.20 and stable kernel 3.2.5. Both contain just a single bug fix that allows PCIe power-saving technology ASPM (Active State Power Management) to be used on systems with a BIOS that activates ASPM on some components, but states in the FADT (Fixed ACPI Description Table) consulted by Linux that ASPM is not supported. Read More Here …

Thank You,

#9

The H: Security news and Open source developments has an article on patches being applied to a couple Linux kernel versions to help improve (slightly) the power management: New Linux kernel fixes power-saving issues - The H Open Source: News and Features

In the article they note:

… long-term kernel 3.0.20 and stable kernel 3.2.5. Both contain just a single bug fix that allows PCIe power-saving technology ASPM (Active State Power Management) to be used on systems with a BIOS that activates ASPM on some components, but states in the FADT (Fixed ACPI Description Table) consulted by Linux that ASPM is not supported.

The article gives an example of reducing the power consumption of a Thinkpad X220 by 5 watts with the patch. My wife has a Thinkpad X220, but I have not applied the patch to that yet (as my access to that laptop is limited, and my wife nominally runs windows7 on it). If I get the chance, I will apply it.

#10

I found the following information here: Reducing Laptop Power Consumption on openSUSE 12.2 (Sandybridge) | /sys/rich and it is important enough to reproduce here …
Reducing Laptop Power Consumption on openSUSE 12.2 (Sandybridge)

A bunch of us did a lot of work investigating power consumption issues in openSUSE 12.1 on Sandybridge laptops (especially the Thinkpad X220)

We found the majority of the power consumption issues are due to the i915 graphics module and the notorious PCIe ASPM issues that were in the Linux kernel
With the impending release of openSUSE 12.2, I’ve slapped Release Candidate 1 on my laptop and brushed off my notes to see how the situation has improved in the new release
For a short ‘tl;dr’ version of what you can do to (probably) save a bunch of power on your Sandybridge laptop, skip to ‘Summary’ at the end

PCIe ASPM

Matthew Garrett‘s great work with a number of PCIe ASPM patches and fixes means that now openSUSE 12.2 seems to correctly detect the ASPM capabilities of my PCIe devices, making the pcie_aspm=force boot parameter obsolete. Once you have openSUSE 12.2 installed, you can this for yourself, run the following from the terminal (as root)[b]

lspci -vvv|grep ASPM

[/b]

You should get a list showing that the majority of your PCI devices have ASPM Enabled. The more devices with ASPM L1 enabled the better, as this provides greater power reductions
I have tried booting openSUSE 12.2 with the following boot parameter
pcie_aspm=powersave

or
pcie_aspm.policy=powersave

In theory one of these should set the aspm policy to a greater powersaving mode – I haven’t seen any improvement
Trying to double check what policy it’s using with ‘cat /sys/module/pcie_aspm/parameters/policy’ suggests it’s still set to [default] and ignoring my attempts to eek out a little more battery life.
If you have a different experience, please comment below!

i915

Some people probably think the built in GPU to Sandybridge chips is a cool thing. When it comes to power consumption on Linux, it seems to me to pretty much be a pain in the arse. The i915 driver has a ton of power saving parameters, many of which are turned off by default, to play on the safe side as it seems no two chipsets from the i915 are exactly the same and some really don’t seem to like some of these paramters

The following have all been tested on an X220 Thinkpad with an i7 CPU. They work fine for me and so far have had no negative effects, just significant battery life gains. That said, your mileage may vary, please test and find out what works best for you

i915 RC6

The i915 RC6 feature allows the GPU to enter a lower power state during GPU idle. Back in openSUSE 12.1 my recommendation was to boot with this parameter set to ’1′
However, doing a ‘modinfo i915′ in openSUSE 12.2 reveals that the i915 RC6 parameter actually controls several different stages of RC6, noted as “RC6, “Deep RC6″, and “Deepest RC6″, each with obviously different effects on power consumption.

Booting up with the following boot parameter enables all 3 RC6 states, for maximum power savings.
i915.i915_enable_rc6=7


i915 Framebuffer Compression

Framebuffer compression reduces the memory bandwidth on screen refereshes and depending on the image in the framebuffer can reduce power consumption. My tests suggest this saves around about 1 Watt

To enable it, boot with the following kernel boot parameter
i915.i915_enable_fbc=1


i915 LVDS Downclocking

This option will download the LVDS refresh rate which in theory should save power. In my tests it didn’t seem to do much, but it didn’t break anything either so I’m still running it on my default boot options

i915.lvds_downclock=1


DRM vblank off delay

This parameter reduces DRM wakeup events and according to powertop seems to be saving me a good couple of watts of power.
[b]drm.vblankoffdelay=1

[/b]


Stuff I didn’t try

Powertop

Powertop has a theoretically great feature that can suggest and implement settings to improve the power saving of a number of devices, including Webcams, Audio, DRAM, ethernet, etc
However, every time I tested it in openSUSE 12.1, it always seems to break more than it fixed, and even though openSUSE 12.2 comes with the nice and shiny powertop v2, I haven’t been brave enough to play around with this yet. If you give it a shot, let me know how it goes in the comments

Aggressive Link Power Management

Aggressive Link Power Management (ALPM) is a mechanism where a SATA AHCI controller can put the SATA link that connects to the disk into a very low power mode during periods of zero I/O activity and into an active power state when work needs to be done. Tests show that this can save around 0.5-2 Watts of power on a typical system.
But as it can theoretically cause data loss on some controllers that end up going into their low power states incorrectly, I’ve avoided looking into this and probably wont (I’m quite happy with the results of the above parameters). Again, if you’re braving than me, let me know how it goes

Summary

Pulling all the above together, if you want to have my recommended maximum (stable) power consumption on Sandybridge laptops running openSUSE 12.2 all you need to do is

[ul]
[li]Fire up YaST [/li][li]Go to Boot Loader [/li][li]Find the field for ‘Optional Kernel Command Line Parameter’[/li][LIST]
[li]If you’re using Grub2 this is under “Boot Loader Options” [/li][li]If you’re using Grub1 this is under the Edit option for whichever Grub menu entry fires up openSUSE 12.2 [/li][/ul]

[li]Add the following to the end of the line (which usually ends in ‘showopts’) [/li][/LIST]
i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 i915.lvds_downclock=1 drm.vblankoffdelay=1

[ul]
[li]Click OK, Close YaST, reboot your system, and you should be home free with a laptop with a power consumption lasting twice as long[/li](in my tests, I went from over 20W with Wifi/Bluetooth enabled and Full backlight brightness, to around 10W, obviously dropping even lower if I reduce the backlight and turn off Wireless)
[/ul]

Please let me know how it works out for you in the comments below!

Thank You,