Language Selection

English French German Italian Portuguese Spanish

Another Major Linux Power Regression Spotted

Filed under
Linux

Since Friday there's been a number of Phoronix articles about a very bad power regression in the mainline Linux kernel, which is widespread, Ubuntu 11.04 is one of the affected distributions, and has been deemed a bug of high importance. This yet-to-be-resolved issue is affected Linux 2.6.38 and 2.6.39 kernels and for many desktop and notebook systems is causing a 10~30% increase in power consumption. Nevertheless, this is not the only major outstanding power regression in the mainline tree, there is another dramatic regression now spotted as well that is yet-to-be-fixed.

Since the discovery last week of the Linux 2.6.38 and 2.6.39 kernels going through excessive amounts of power compared to 2.6.37 and earlier, each day and practically all day since that time has been working on Linux power consumption tests. Power consumption benchmarks are not normally an area we focus on nor do many others, but since the inadvertent discovery of it when testing out the power consumption of past Ubuntu Linux releases, a lot of time has spent investigating the matter within the kernel. In order to do such, there's been continued improvements to the Phoronix Test Suite, Phoromatic, OpenBenchmarking.org, and the PTS Commercial scripts for better enhancing the power testing, more improvements to multi-point automated regression bisecting, etc. The Phoronix Test Suite has already been able to monitor and log the power consumption (along with temperatures, fan speeds, I/O wait, system load, etc) for any test profile/suite being run by using the system monitor module, but now there is more. Thanks to working on that Easter weekend, coming to fruition because of that today is the discovery of another regression while still working on finding the first commit causing a power regression.

rest here




More in Tux Machines

Kernel Space/Linux

Red Hat News

openSUSE Tumbleweed: A Linux distribution on the leading edge

So, to summarize: openSUSE Tumbleweed is a good, solid, stable Linux distribution with a wide range of desktops available. It is not anything particularly exotic or unstable, and it does not require an unusual amount of Linux expertise to install and use on an everyday system. To make a very simple comparison, in my experience installing and using Tumbleweed is much less difficult and much less risky than using the Debian "testing" distribution, and it is kept much (much much) more up to date than openSUSE Leap, Debian "stable", Linux Mint or Ubuntu. I don't say that to demean any of those other distributions. As I said at the end of my recent post about point-release vs. rolling-release distributions, if your hardware is fully supported by one of those point-release distributions, and you are satisfied with the applications included in them, then they are certainly a good choice. But if you like staying on the leading edge, or if you have very new hardware which requires the latest Linux kernel and drivers, or you just want/need the latest version of some application (in my case this would be digiKam), then openSuSE could be just what you want. Read more Also: Google Summer of Code 2017

Graphics in Linux

  • 17 Fresh AMDGPU DC Patches Posted Today
    Seventeen more "DC" display code patches were published today for the AMDGPU DRM driver, but it's still not clear if it will be ready -- or accepted -- for Linux 4.12. AMD developers posted 17 new DC (formerly known as DAL) patches today to provide small fixes for Vega10/GFX9 hardware, various internal code changes, CP2520 DisplayPort compliance, and various small fixes.
  • libinput 1.7.0
  • Libinput 1.7 Released With Support For Lid Switches, Scroll Wheel Improvements
    Peter Hutterer has announced the new release of libinput 1.7.0 as the input handling library most commonly associated with Wayland systems but also with Ubuntu's Mir as well as the X.Org Server via the xf86-input-libinput driver.
  • Nouveau TGSI Shader Cache Enabled In Mesa 17.1 Git
    Building off the work laid by Timothy Arceri and others for enabling a TGSI (and hardware) shader cache in the RadeonSI Gallium3D driver as well as R600g TGSI shader cache due ot the common infrastructure work, the Nouveau driver is now leveraging it to enable the TGSI shader cache for Nouveau Gallium3D drivers.