Attachment #47703 for bug #69734

View | Details | Raw Unified | Return to bug 69734 | Differences between
Collapse All | Expand All




<title>Power Management Guide</title>

<author title="Author">
  <mail link="fragfred@gmx.de">Dennis Nienhüser</mail>
</author>

<abstract>

<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>

<version>1.18</version>
<date>January 05, 2005</date>

<chapter>
<title>Introduction</title>

          Default CPUFreq governor (userspace)
    &lt;*&gt;   'performance' governor
    &lt;*&gt;   'powersave' governor
    &lt;*&gt;   'ondemand' cpufreq policy governor
    &lt;*&gt;   CPU frequency table helpers
    &lt;M&gt; ACPI Processor P-States driver
    &lt;*&gt; <i>CPUFreq driver for your processor</i>
</pre>

<p>
Decide yourself whether you want to enable Software Suspend, Suspend-to-Disk and
Sleep States (see below). If you own an ASUS, Medion or Toshiba laptop, enable
the appropriate section. Recent kernel versions (2.6.9 and later) include an
<e>'ondemand' governor</e> for CPU Frequency Scaling, activate it as well when
using such a kernel.
</p>

<p>
The kernel has to know how to enable CPU frequency scaling on your processor. As
each type of CPU has a different interface, you've got to choose the right
driver for your processor. Be careful here - enabling <e>Intel Pentium 4 clock
modulation</e> on a Pentium M system will lead to strange results for example.
Consult the kernel documentation if you're unsure which one to take.
</p>

<p>


<p>
Typical ACPI events are closing the lid, changing the power source or pressing
the sleep button. An important event is changing the power source, which should
cause a runlevel switch. Create the following files to switch between
<e>default</e> and <e>battery</e> runlevel depending on the power source:
</p>

<pre caption="/etc/acpi/switch_runlevel.sh">
#!/bin/bash

RUNLEVEL_AC="default"
RUNLEVEL_BATTERY="battery"

function on_ac () {
    if which on_ac_power &amp;> /dev/null
    then
        on_ac_power
    else
        grep --quiet on-line /proc/acpi/ac_adapter/*/state
    fi
}

function SwitchRunlevel () {
RLVL_AC="default"
<comment># runlevel to use in battery mode</comment>
RLVL_BATTERY="battery"

    if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]
    then
        logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."
        exit 1
    fi


    if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]
    then
        logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."
        exit 1
    fi

    if on_ac
    then if [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
  then
            logger "Switching to ${RUNLEVEL_AC} runlevel"
            /sbin/rc ${RUNLEVEL_AC}
        fi
    elif [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
  then
        logger "Switching to ${RUNLEVEL_BATTERY} runlevel"
        /sbin/rc ${RUNLEVEL_BATTERY}
  fi
}
</pre>

<pre caption="/etc/acpi/events/pmg_ac_adapter">
event=ac_adapter.*
action=/etc/acpi/actions/pmg_ac_adapter.sh %e
</pre>

<pre caption="/etc/acpi/events/pmg_battery">
event=battery.*
action=/etc/acpi/actions/pmg_battery.sh %e
</pre>

<pre caption="/etc/acpi/actions/pmg_ac_adapter.sh">
#!/bin/bash

source /etc/acpi/switch_runlevel.sh
SwitchRunlevel
</pre>

<pre caption="/etc/acpi/actions/pmg_battery.sh">
#!/bin/bash

source /etc/acpi/switch_runlevel.sh
SwitchRunlevel
</pre>

<p>
Some of these files must be executable. Last not least restart acpid to have
it recognize the changes.
</p>

<pre caption="Finishing runlevel switching with acpid">
<i># chmod +x /etc/acpi/switch_runlevel.sh</i>
<i># chmod +x /etc/acpi/actions/pmg_*</i>
<i># /etc/init.d/acpid restart</i>
        SwitchRunlevel
        ;;
      *) 
        logger "ACPI group battery / action $action is not defined"
        ;;
    esac
    ;;

  ac_adapter)
    case "$action" in
      ac_adapter)
        SwitchRunlevel
        ;;
      *)
        logger "ACPI group ac_adapter / action $action is not defined"
        ;;
    esac
    ;;
  *)
    logger "ACPI group $group / action $action is not defined"
    ;;
esac
</pre>

<p>
Give it a try: Plug AC in and out and watch syslog for the "Switching to AC
mode" or "Switching to battery mode" messages. See the Troubleshooting
section if the script is not able to detect the power source correctly.
</p>

<p>
Due to the nature of the event mechanism, your laptop will boot into runlevel
<e>default</e> regardless of the AC/battery state. You can add another entry
to the boot loader with <c>softlevel=battery</c>, but it's likely to forget
choosing it. A better way is faking an ACPI event in the end of the boot
process and let the <path>/etc/acpi/default.sh</path> script decide whether a
runlevel change is necessary. Open <path>/etc/conf.d/local.start</path> in your


<pre caption="Runlevel switch at boot time by editing local.start">
<comment># Fake acpi event to switch runlevel if running on batteries</comment>
/etc/acpi/actions/pmg_battery.sh "battery/battery"
</pre>

<p>

<chapter>
<title>CPU Power Management</title>
<section>
<title>Some technical terms</title>
<body>

<p>
CPU frequency scaling brings up some technical terms that might be unknown to
you. Here's a quick introduction.
</p>

<p>
First of all, the kernel has to be able to change the processor's frequency. The
<e>CPUfreq processor driver</e> knows the commands to do it on your CPU. Thus
it's important to choose the right one in your kernel. You should already have
done it above. Once the kernel knows how to change frequencies, it has to know
which frequency it should set. This is done according to the <e>policy</e> which
consists of <e>CPUfreq policy</e> and a <e>governor</e>. A CPUfreq policy are
just two numbers which define a range the frequency has to stay between -
minimal and maximal frequency. The governor now decides which of the available
frequencies in between minimal and maximal frequency to choose. For example, the
<e>powersave governor</e> always chooses the lowest frequency available, the
<e>performance governor</e> the highest one. The <e>userspace governor</e> makes
no decision but chooses whatever the user (or a program in userspace) wants -
which means it reads the frequency from
<path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path>.
</p>

<p>
This doesn't sound like dynamic frequency changes yet and in fact it isn't.
Dynamics however can be accomplished with various approaches. For example,
the <e>ondemand governor</e> makes its decisions depending on the current CPU
load. The same is done by various userland tools like <c>cpudyn</c>,
<c>speedfreq</c>, <c>powernowd</c> and many more. ACPI events can be used to
enable or disable dynamic frequency changes depending on power source.
</p>

</body>
</section>
<section>
<title>Setting the frequency manually</title>
<body>



<p>
The above is quite nice, but not doable in daily life. Better let your system
set the appropriate frequency automatically. There are many different approaches
to do this. The following table gives a quick overview to help you decide on one
of them. It's roughly seperated in three categories <e>kernel</e> for approaches
that only need kernel support, <e>daemon</e> for programs that run in the
background and <e>graphical</e> for programs that provide a GUI for easy
configuration and changes.
</p>

<table>
<tr>
  <th>Name</th>
  <th>Category</th>
  <th>Switch decision</th>
  <th>Kernel governors</th>
  <th>Further governors</th>
  <th>Comments</th>
</tr>
<tr>
  <ti>'ondemand' governor</ti>
  <ti>Kernel</ti>
  <ti>CPU load</ti>
  <ti>N.A.</ti>
  <ti>N.A.</ti>
  <ti>
    Further tuning through files in
    <path>/sys/devices/system/cpu/cpu0/cpufreq/ondemand/</path>. Still requires
    userland tools (programs, scripts) if governor switching or similar is
    desired.
  </ti>
</tr>
<tr>
  <ti><uri link="http://mnm.uib.es/~gallir/cpudyn/">cpudyn</uri></ti>
  <ti>Daemon</ti>
  <ti>CPU load</ti>
  <ti>None</ti>
  <ti>Dynamic</ti>
  <ti>
    Also supports disk standby - notice however that <e>laptop mode</e> in most
    cases will do a better job.
  </ti>
</tr>
<tr>
  <ti><uri link="http://sourceforge.net/projects/cpufreqd/">cpufreqd</uri></ti>
  <ti>Daemon</ti>
  <ti>Battery state, CPU load, running programs</ti>
  <ti>All available</ti>
  <ti>None</ti>
  <ti>
    Sophisticated (but also complicated) setup. An optimal configuration
    requires detailed knowledge of your system.
  </ti>
</tr>
<tr>
  <ti>
    <uri link="http://www.deater.net/john/powernowd.html">powernowd</uri>
  </ti>
  <ti>Daemon</ti>
  <ti>CPU load</ti>
  <ti>None</ti>
  <ti>Passive, sine, aggressive</ti>
  <ti>
    Supports SMP.
  </ti>
</tr>
<tr>
  <ti><uri link="http://www.goop.org/~jeremy/speedfreq/">speedfreq</uri></ti>
  <ti>Daemon</ti>
  <ti>CPU load</ti>
  <ti>None</ti>
  <ti>Dynamic, powersave, performance, fixed speed</ti>
  <ti>
    Small yet powerful with an useful client/server interface. Requires a 2.6
    kernel.
  </ti>
  <ti>Kernel 2.6 series only</ti>
</tr>
<tr>
  <ti><uri link="http://cpuspeedy.sourceforge.net/">gtk-cpuspeedy</uri></ti>
  <ti>Graphical</ti>
  <ti>None</ti>
  <ti>None</ti>
  <ti>None</ti>
  <ti>
    Gnome application, a graphical tool to set CPU frequency manually. It does
    not offer any automation and is mainly listed for the sake of completeness.
  </ti>
</tr>
<tr>
  <ti>klaptopdaemon</ti>
  <ti>Graphical</ti>
  <ti>Battery state</ti>
  <ti>All available</ti>
  <ti>None</ti>
  <ti>
    KDE only, 'ondemand' governor required for dynamic frequency scaling.
  </ti>
</tr>
</table>


</pre>

<p>
Setting up cpufreqd is a little bit more complicated.
</p>

<warn>
Do not run more than one of the above programs at the same time. It may cause
confusion like switching between two frequencies all the time. If you just
installed speedfreq, skip cpufreqd now.
</warn>

<pre caption="Installing cpufreqd">

<c>speedfreq</c>.
</p>

</body>
</section>

<section>
<title>Verifying the result</title>

<body>

<p>
The last thing to check is that your new policies do a good job. An easy way to
do so is monitoring CPU speed while working with your laptop:
</p>

<pre caption="Monitoring CPU speed">

</p>

<pre caption="Automate disk standby settings">
# <i>chmod +x /etc/init.d/pm.hda</i>
# <i>/sbin/depscan.sh</i>
# <i>rc-update add pm.hda battery</i>
</pre>

</p>

<p>
<!-- TODO: bug #45593 -->
Besides kernel support you also need a script that controls starting and
stopping of laptop-mode. You kernel documentation in
<path>/usr/src/linux/Documentation/laptop-mode.txt</path> contains one as well
as the package <c>laptop-mode-tools</c>. None of them is easy to install
though.
</p>

<p>
Ebuilds for laptop-mode-tools are not in Portage, because Gentoo developers
don't think they are production ready yet. Take that into consideration
before using the ebuilds which can be found in <uri
link="http://bugs.gentoo.org/show_bug.cgi?id=45593">Bugzilla</uri>. The Gentoo
Handbook tells you how to use external ebuilds if you don't know where to put
them. Once your PORTDIR_OVERLAY contains the ebuilds, install the
script:
</p>

<warn>
This package is not seen as production ready and installing custom ebuilds from
Bugzilla is not recommended. Please don't use laptop-mode-tools if you're
unsure.
before your battery runs out of power and data gets written to disk - otherwise
you will at least lose the last 10 minutes of your work.
</warn>

<pre caption="Automated start of laptop-mode">
# <i>emerge laptop-mode-tools</i>
</pre>

<p>
<c>laptop-mode-tools</c> has it's configuration file in
<path>/etc/laptop-mode/laptop-mode.conf</path>. Adjust it the way you like it,
it's well commented. If you have <e>apm</e> or <e>acpi</e> in your USE flags,
laptop-mode will be started automatically in battery mode. Otherwise you can
automate it by running <c>rc-update add laptop-mode battery</c>.
</p>

</body>
</section>
<section>

is a good starting point to save even more energy.
</p>

<pre caption="Power Management for WLAN">
# <i>chmod +x /etc/init.d/pm.wlan0</i>
# <i>/sbin/depscan.sh</i>
# <i>rc-update add pm.wlan0 battery</i>
</pre>

</body>
</section>
<section>

# <i>echo 3 &gt; /proc/acpi/sleep</i>          <comment>(sleep)</comment>

<comment>(kernel 2.6 series)</comment>
# <i>echo -n standby &gt; /sys/power/state</i> <comment>(standby)</comment>
# <i>echo -n mem &gt; /sys/power/state</i>     <comment>(sleep)</comment>

<comment>(swsusp)</comment>
# <i>echo 4 &gt; /proc/acpi/sleep</i>          <comment>(hibernate)</comment>

<comment>(Suspend-to-Disk)</comment>
# <i>echo -n disk &gt; /sys/power/state</i>    <comment>(hibernate)</comment>

<comment>(swsusp2)</comment>
# <i>/usr/sbin/hibernate</i>                   <comment>(hibernate, see below)</comment>
</pre>

<warn>

<p>
While the above should be sufficient to get swsusp and Suspend-to-Disk running
(I didn't say working), swsusp2 needs special care. 
The first thing to do is patching the kernel with the patches provided at <uri
link="http://softwaresuspend.berlios.de/">
http://softwaresuspend.berlios.de/</uri>. Additionally you've got to emerge
<c>hibernate-script</c>. Once it is installed, configure
<path>/etc/hibernate/hibernate.conf</path> and try whether it works:
</p>

<pre>
<i># emerge hibernate-script</i>
<i># $EDITOR /etc/hibernate/hibernate.conf</i>
<comment>(Last chance to backup any data)</comment>
<i># hibernate</i>
</pre>

</body>
</section>
</chapter>

</p>

<p>
<e>A:</e> Probably you have activated symmetric multiprocessing support
(CONFIG_SMP) in your kernel. Deactivate it and it should work. Some older
kernels had a bug causing this. In that case, run <c>emerge x86info</c>,
update your kernel as asked and check the current frequency with
<c>x86info -mhz</c>.
</p>

<p>

</p>

<p>
<e>Q:</e> When configuring the kernel, powersave, performance and userspace
governors show up, but that ondemand thing is missing. Where do I get it?
</p>

<p>
<e>A:</e> The ondemand governor is only included in recent kernel sources. Try
updating them.
</p>

<p>
<e>Q:</e> Runlevel switching doesn't work - the script is not able to determine
the power source correctly.
</p>

<p>
<e>A:</e> On some systems, the power source can't be determined by reading
<path>/proc/acpi/ac_adapter/*/state</path>. If it fails for you, create a
custom script <c>on_ac_power</c> or use the one from <c>powermgmt-base</c>.
An ebuild can be found in <uri
link="http://bugs.gentoo.org/show_bug.cgi?id=76516">Bug #76516</uri>. You
only have to emerge it, it works transparently with the above script.
</p>

<p>
<e>Q:</e> Battery life time seems to be worse than before.
</p>


your battery is probably broken. Try to claim your warranty.
</p>

<p>
<e>Q:</e> My problem is not listed above. Where should I go next?
</p>

<p>
<e>A:</e> Don't fear to contact me, <mail link="fragfred@gmx.de">Dennis
Nienhüser</mail>, directly.
</p>

</body>
</section>
</chapter>

Return to bug 69734