Linux 2.6.38 power problems confirmed, but workaround appears

Phoronix has identified the source of Linux power regression problems in Linux 2.6.38 as being related to ASPM code for PCI Express, and has published a workaround. The problem, which can reduce battery life with Ubuntu 11.04 and Fedora 15, was confirmed by Tom's Hardware Guide.

The Linux 2.6.38 power consumption problems were encountered by Phoronix' Michael Larabel in April when benchmarking Ubuntu 11.04 ("Natty Narwhal"), one of the first major distros to adopt Linux kernel 2.6.38. The results showed a 10 percent average power consumption increase over the Linux 2.6.35-based Ubuntu 10.10 ("Maverick Meerkat").

Some configurations and workloads revealed up to a 26 percent increase, said the benchmark-focused site. The problem was traced down to a power regression problem in the 2.6.38 kernel. On April 25, further testing indicated an even larger power consumption boost dating back to Linux 2.6.35.



Phoronix' earlier power testing on Lenovo ThinkPad running Ubuntu -- top two lines show Linux 2.6.38 and 2.6.39
Source: Phoronix
(Click to enlarge)

On June 12, Tom's Hardware published an Ubuntu 11.04 review that included benchmarks that confirmed the Phoronix findings on Linux 2.6.38.

"We not only confirm his findings, but also demonstrate that this issue has very significant implications in actual use," writes reviewer Adam Overa. "It also appears that the Unity interface is not the root cause. In fact, Ubuntu 11.04 with Unity gets more than 20 minutes additional battery life than Ubuntu 11.04 Classic. The previous release, Ubuntu 10.10 Maverick Meerkat gets over two hours more battery life than Natty Narwhal, regardless of the user interface."

Overa goes on to conclude, "I hate to say it, especially in an Ubuntu review, but the mobile edge goes to Windows for now."

Neither Phoronix, Canonical, or the Linux kernel team have yet to get to the bottom of the Linux 2.6.35 problems, and the publication is also looking into a 2.6.38-era regression related to a scheduler issue. However, Phoronix' Larabel claims to have found an easy workaround for the originally discovered Linux 2.6.38 power regression issue.

This week, Phoronix published a report identifying the source of the problem, while noting that the issue is affecting users of Fedora 15 and other recent Linux distribution releases that have adopted Linux 2.6.38 or 2.6.39.

The problem is due to a change in behavior introduced in Linux 2.6.38 regarding Active-State Power Management (ASPM) for PCI Express (PCIe), writes Larabel. ASPM is designed to save power by setting a lower power state for unused PCIe links. ASPM is not generally implemented on desktop systems because it can increase device latency due to the time required in switching PCIe link power modes. However, it generally saves a "fair amount" of power on mobile systems, explains Larabel.

Linux 2.6.38 changed ASPM so that if the BIOS indicates it does not support ASPM, the behavior is changed. Essentially, it appears that Linux 2.6.38 is disabling ASPM if a BIOS asks it to.

The problem stems from the fact that many BIOSes are oriented toward Windows power management, and are often flawed when it comes to communicating with Linux over power issues. As a result, ASPM is often being turned off even when the BIOS supports it on some devices.

While the problem is complex, the workaround is fairly simple. According to Larabel, users who want to turn ASPM back on can simply add "pcie_aspm=force" to their boot command line.

"Just adding ["pcie_aspm=force"] to 2.6.38+ kernels on the systems I have tested will workaround this problem-causing commit and lead to noticeable power savings," reports Larabel, adding that in his tests the power consumption rate dropped by nearly 15 percent.


Power consumption on Intel Core i7 system using ASPM workaround for Linux 2.6.38+ vs. problem-free Linux 2.6.37 system and Linux 2.6.38 system
Source: Phoronix
(Click to enlarge)
If one's BIOS really does have a problem with ASPM, adding the boot code could make the system hang, he warns. However, Larabel did not see such issues in his test systems.

A fix in the kernel itself is not likely until Linux 3.1, "as the Linux 3.0 merge window is closed and a final release is only a few weeks out," explains Larabel. It's also unclear whether such a fix would be backported to the stable kernel series, he adds.