http://www.fewt.com/2011/09/about-kernel-30-power-regression-myth.html
_____________________________________________________________________________ About the Kernel 3.0 "Power Regression" Myth Oh boy, here we go again. LOLPhoronix has yet another article proclaiming that the Linux Kernel has a "power regression". Those Kernel developer losers aren't doing ANYTHING about it either! Oh the HUMANITY! /drama Oh, and by the way it's really bad now. We are losing ~50%!!! Would you believe it? A power regression so bad that Portable Linux users running Kernel 3.0.x are losing over 50% of our battery life! Uhh, no, we aren't. There is no such thing as this power "regression" in the kernel. There was a patch to a bug found by RedHat related to how the kernel enables ASPM. The bug caused a group of computers effected to crash when the BIOS reported that ASPM wasn't supported, but ASPM was enabled in hardware (RHEL-681017). The fix was too instruct ASPM to go to an off state if the BIOS reported it wasn't supported rather than leaving it default. This fixed the instability issue causing systems to crash. More information on the subject: http://lwn.net/Articles/449448/ http://lwn.net/Articles/449648/ HOWEVER, forcing ASPM to turn off on systems that report that it is unsupported caused a slight loss in power savings. It was a sacrifice necessary to prevent systems from crashing. IT WAS THE RIGHT THING TO DO. also IT IS NOT A REGRESSION. One reason that is is not a regression is that the kernel's exposed tuneable parameters for power management are not dynamic. This means that when you boot up either with a power cord connected or on battery your kernel boots into the same state. The kernel by default is optimized for performance, and not power savings. An example of this would be dirty_writeback_centisecs. This parameter specifies the time in 100ths of a second where pdflush wakes up and writes cached data out to disk. By default it is set to 500 which is optimal for performance but sub optimal for battery life. A much more sane value when on battery is 1500. Unfortunately, the parameter does not change "automatically" when you unplug. Other examples would be parameters like nmi_watchdog, sched_smt_power_savings, and snd_hda_intel/parameters/power_save. This is where a tool like Jupiter or tuned comes in, these tools are designed to alter the state of the kernel to optimize the system for performance when plugged in, and battery life when unplugged. In the case of Jupiter, not only do I change multiple kernel parameters, but I also change the power state of (supported) devices to shift them to power savings mode. I tried to explain to Michael why he was wrong, but Michael Larabel ignores reason choosing instead to continue to poison Linux users into believing the sky is falling when it isn't. For those that do see a small loss in battery life and are willing to risk stability for a few extra minutes unplugged, there is a workaround. Set 'pcie_aspm=force' on the kernel command line of grub.conf, reboot, and move on with life. To see if you have a bad BIOS, look at /sys/module/pcie_aspm/parameters/policy. If it says 'default', you probably unfortunately have a computer that is reporting that ASPM is unsupported. If you have a laptop or netbook, and you want optimal battery life, install Jupiter or tuned and get on with your life. The remaining complaints Michael blindly points at the kernel are most likely configuration problems in the Ubuntu distribution itself (Unity or other application maybe), in the Xorg video driver stack shipping with Ubuntu, or operator error. No offense to Ubuntu intended, it just honestly isn't well optimized for portable computers. Even the older netbook remixes were just a different GUI bolted onto a default install. I should know, I spent a lot of my personal time optimizing it for Eee PCs which eventually led to my being invited to join the Eeebuntu project (now called Aurora). If you are looking at powertop and you are seeing crazy wakeups, look at what you have running and what you are doing. If you see things like applications (Chromium, Firefox, Thunderbird, Terminals, shell scripts, etc), congrats - you are doing it wrong. Thanks to the Ubuntu Forums member that pointed out bug #760131 the bug report is a fine example of doing it wrong. I stopped counting at 347 process or device interrupts. It's a busy system, busy systems don't have IDLE CPUs. Not a bug! Every process, keystroke, mouse movement, etc causes a wakeup, some cause tens or hundreds of wakeups per second. If you want to test for wakeups, you need to close EVERYTHING except the base desktop (clean boot recommended), open a terminal, unplug, and start powertop as root. Now .. walk away for ~15 minutes. Still seeing crazy wakeups? Probably not. Michael Larabel would be far more helpful to the community if he would learn how to properly identify and test for these sorts of problems and report them through the proper channels. He is more interested though in driving clicks to his website, and the best way to do that is through fear, uncertainty, and doubt. If he cared about the community, you would see his participation about his fabled ASPM "regression" on the Linux Kernel Mailing List. If he were to post about the myth he created there though, he would probably be eaten alive .. and deservedly s ______________________________________________________________ Best A. Mani -- A. Mani CU, ASL, CLC, AMS, CMS http://www.logicamani.co.cc _______________________________________________ Ilugd mailing list Ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd
