Power Management Guide

-#!/bin/sh - -set $* - -group=${1/\/*/} -action=${1/*\//} - -# runlevel to use in AC mode -RLVL_AC="default" -# runlevel to use in battery mode -RLVL_BATTERY="battery" - -# file indicating the AC state. Verify the filename before using -AC_STATE="/proc/acpi/ac_adapter/AC/state" -# this string means running on AC -AC_ON="on-line" -# this string means running on batteries -AC_OFF="off-line" +the sleep button. Create the following files to switch between default +and battery runlevel depending on the power source: +

+ +

+#!/bin/bash
+
+# This runlevel will be used in AC mode
+#RUNLEVEL_AC="default"
+
+# This runlevel will be used in battery mode
+#RUNLEVEL_BATTERY="battery"
+
+# This file indicates the AC state
+# It's location may vary on your system. The script checks for
+# /proc/acpi/ac_adapter/AC/state and /proc/acpi/ac_adapter/AC0/stat
+# If it is something else on your system, uncomment the next line
+# and change appropriately.
+#AC_STATE="/proc/acpi/ac_adapter/AC/state"
+

+ +

+#!/bin/bash
+
+RUNLEVEL_AC="default"
+RUNLEVEL_BATTERY="battery"
+
+if [ -f '/proc/acpi/ac_adapter/AC0/state' ]
+then
+    AC_STATE="/proc/acpi/ac_adapter/AC0/state"
+else
+    AC_STATE="/proc/acpi/ac_adapter/AC/state"
+fi
+
+
+source /etc/acpi/switch_runlevel.conf
 
 function SwitchRunlevel() {
-  if [[ "$(grep ${AC_OFF} ${AC_STATE})" != "" && "$(cat /var/lib/init.d/softlevel)" != "${RLVL_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 [ ! -f "${AC_STATE}" ]
+    then
+        logger "${0}: File ${AC_STATE} does not exist. Aborting"
+        exit 1
+    fi
+
+
+    if [[ "$(grep off-line ${AC_STATE})" != "" && "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
   then
-    logger "Switching to ${RLVL_BATTERY} runlevel"
-    /sbin/rc ${RLVL_BATTERY}
-  elif [[ "$(grep ${AC_ON} ${AC_STATE})" != "" && "$(cat /var/lib/init.d/softlevel)" != "${RLVL_AC}" ]]
+        logger "Switching to ${RUNLEVEL_BATTERY} runlevel"
+        /sbin/rc ${RUNLEVEL_BATTERY}
+    elif [[ "$(grep on-line ${AC_STATE})" != "" && "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
   then
-    logger "Switching to ${RLVL_AC} runlevel"
-    /sbin/rc ${RLVL_AC}
+        logger "Switching to ${RUNLEVEL_AC} runlevel"
+        /sbin/rc ${RUNLEVEL_AC}
   fi
 }
+

+ +

+event=ac_adapter.*
+action=/etc/acpi/actions/pmg_ac_adapter.sh %e
+

+ +

+event=battery.*
+action=/etc/acpi/actions/pmg_battery.sh %e
+

+ +

+#! /bin/bash
+
+source /etc/acpi/switch_runlevel.sh
+SwitchRunlevel
+

+ +

+#! /bin/bash
+
+source /etc/acpi/switch_runlevel.sh
+SwitchRunlevel
+

+Some of these files must be executable. Last not least restart acpid to have +it recognize the changes. +

-case "$group" in - battery) - case "$action" in - battery) - 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 +

+# chmod +x /etc/acpi/switch_runlevel.sh
+# chmod +x /etc/acpi/actions/pmg_*
+# /etc/init.d/acpid restart

@@ -304,7 +355,7 @@

Due to the nature of the event mechanism, your laptop will boot into runlevel default regardless of the AC/battery state. You can add another entry -to the boot loader with softlevel=boot, but it's likely to forget +to the boot loader with softlevel=battery, 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 /etc/acpi/default.sh script decide whether a runlevel change is necessary. Open /etc/conf.d/local.start in your @@ -313,7 +364,7 @@

 # Fake acpi event to switch runlevel if running on batteries
-/etc/acpi/default.sh "battery/battery"
+/etc/acpi/actions/pmg_battery.sh "battery/battery"

@@ -328,6 +379,43 @@ CPU Power Management

+Some technical terms + + +

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

+ +

+First of all, the kernel has to be able to change the processor's frequency. The +CPUfreq processor driver 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 policy which +consists of CPUfreq policy and a governor. 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 +powersave governor always chooses the lowest frequency available, the +performance governor the highest one. The userspace governor makes +no decision but chooses whatever the user (or a program in userspace) wants - +which means it reads the frequency from +/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed. +

+ +

+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 ondemand governor makes its decisions depending on the current CPU +load. The same is done by various userland tools like cpudyn, +speedfreq, powernowd and many more. ACPI events can be used to +enable or disable dynamic frequency changes depending on power source. +

+ + +

Setting the frequency manually @@ -394,39 +482,101 @@

The above is quite nice, but not doable in daily life. Better let your system -set the appropriate frequency automatically. A couple of user space programs -like to do it for you. The following table gives a quick overview to help you -decide on one of them. +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 kernel for approaches +that only need kernel support, daemon for programs that run in the +background and graphical for programs that provide a GUI for easy +configuration and changes.

- - + + + + + + + + 'ondemand' governor + Kernel + CPU load + N.A. + N.A. + + Further tuning through files in + /sys/devices/system/cpu/cpu0/cpufreq/ondemand/. Still requires + userland tools (programs, scripts) if governor switching or similar is + desired. + cpudyn - Also supports disk standby - + Daemon + CPU load + None + Dynamic + + Also supports disk standby - notice however that laptop mode in most + cases will do a better job. + + + + cpufreqd + Daemon + Battery state, CPU load, running programs + All available + None + + Sophisticated (but also complicated) setup. An optimal configuration + requires detailed knowledge of your system. + - cpufreq - Sophisticated setup possible - Complicated setup + + powernowd + + Daemon + CPU load + None + Passive, sine, aggressive + + Supports SMP. + speedfreq + Daemon + CPU load + None + Dynamic, powersave, performance, fixed speed + + Small yet powerful with an useful client/server interface. Requires a 2.6 + kernel. + + + + gtk-cpuspeedy + Graphical + None + None + None - Small yet powerful
- Useful client/server interface + 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. - Kernel 2.6 series only - powernowd - Supports SMP - + klaptopdaemon + Graphical + Battery state + All available + None + + KDE only, 'ondemand' governor required for dynamic frequency scaling. +

Name	Pro	Con	Category	Switch decision	Kernel governors	Further governors	Comments

@@ -458,13 +608,13 @@

@@ -548,9 +698,17 @@ speedfreq.

+ + + +

+Verifying the result + + +

The last thing to check is that your new policies do a good job. An easy way to -do so is monitoring the CPU speed while working with your laptop: +do so is monitoring CPU speed while working with your laptop:

@@ -715,25 +873,42 @@
 
 
 
-
-To start and stop laptop-mode, create a script /etc/init.d/laptop-mode. You can
-take the one included in
-/usr/src/linux/Documentation/laptop-mode.txt. Onces it's ready,
-make sure it gets called.
+
+Besides kernel support you also need a script that controls starting and
+stopping of laptop-mode. You kernel documentation in
+/usr/src/linux/Documentation/laptop-mode.txt contains one as well
+as the package laptop-mode-tools. None of them is easy to install
+though.
 
 
--# rc-update add laptop-mode battery
-
+
+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 Bugzilla. 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:
+
 
 
-Once again: Be careful with sleep/spin down settings of your hard drive.
-Setting it to small values might wear out your drive and lose warranty. Be sure
-to read the documentation in laptop-mode.txt. Make sure to stop laptop-mode
-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.
+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.
 
 
++# emerge laptop-mode-tools
+
+
+
+laptop-mode-tools has it's configuration file in
+/etc/laptop-mode/laptop-mode.conf. Adjust it the way you like it,
+it's well commented. If you have apm or acpi in your USE flags,
+laptop-mode will be started automatically in battery mode. Otherwise you can
+automate it by running rc-update add laptop-mode battery.
+
+

@@ -948,17 +1123,17 @@ # echo 3 > /proc/acpi/sleep (sleep) (kernel 2.6 series) -# echo -n standby > /sys/power/state standby -# echo -n mem > /sys/power/state sleep +# echo -n standby > /sys/power/state (standby) +# echo -n mem > /sys/power/state (sleep) (swsusp) -# echo 4 > /proc/acpi/sleep hibernate +# echo 4 > /proc/acpi/sleep (hibernate) (Suspend-to-Disk) -# echo -n disk > /sys/power/state hibernate +# echo -n disk > /sys/power/state (hibernate) (swsusp2) -# echo > /proc/swsusp/activate +# /usr/sbin/hibernate (hibernate, see below)