LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Updated document content and structure

This commit is contained in:
davidrl 2003-06-30 04:42:16 +00:00
parent 614d25daf4
commit 11e37a873a
1 changed files with 91 additions and 114 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

205
LDP/howto/docbook/Battery-Powered.sgml
View File

@ -13,10 +13,10 @@
<revhistory>
<revision>
<revnumber>2.2</revnumber>
<date>2003-05-27</date>
<revnumber>2.3</revnumber>
<date>2003-06-29</date>
<authorinitials>drl</authorinitials>
<revremark>Minor corrections and updates including document structure</revremark>
<revremark>Updated document content and structure</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
@ -28,7 +28,7 @@
<revnumber>1.0</revnumber>
<date>1997-12-21</date>
<authorinitials>hm</authorinitials>
<revremark>Initial draft by Hanno Muller</revremark>
<revremark>Initial draft by Hanno Muller &lt;kontakt@hanno.de&gt;</revremark>
</revision>
</revhistory>
@ -36,74 +36,30 @@
<para>This document describes how to optimize and configure power management
on a ready-configured Linux system for use on battery-powered laptops. This
will be helpful for everyone who runs Linux on a portable computer system.
APM and ACPI methods of power management will be discussed, along with general
APM/ACPI methods of power management are discussed along with
power saving tips and techniques. There is also some discussion about the
different types of batteries available.</para>
</abstract>
</artheader>
<sect1 id="intro">
<title>Introduction</title>
<para>The Linux Battery Powered Mini-HOWTO has undergone some significant
enhancements from its last publication in 1997. Specific attention will be
paid towards recent advances in the Linux realm with ACPI, specific power
saving techniques, and general battery issues.</para>
<sect2 id="copyright">
<title>Copyright Information</title>
<para>This document is the result of the work and contribution of many
individuals. As such, it is released under the terms of the GNU Free
Documentation License. Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License, Version
1.1 or any later version published by the Free Software Foundation.
A copy of the license is available at
<ulink url="http://www.gnu.org/licenses/fdl.txt">http://www.gnu.org/licenses/fdl.txt</ulink>
</para>
</sect2>
<sect2 id="disclaimer">
<title>Disclaimer</title>
<para>Power management can be tricky stuff. As such, no liability for the
contents of this document can be accepted. Use the concepts, examples and
other content at your own risk. This information is provided "as is" without
any warranty, condition, or representation of any kind, either express or
implied, including but not limited to, any warranty respecting
non-infringement, and the implied warranties of conditions of merchantability
and fitness for a particular purpose. In no event shall anyone connected to
this document be liable for any direct, indirect, special, incidental,
consequential or other damages howsoever caused whether arising in contract,
tort, or otherwise, arising out of or in connection with the use or performance
of the information contained in this document.</para>
</sect2>
<sect2 id="about">
<title>About this document</title>
<para>This document was lovingly handcrafted on a Dell Latitude C400 laptop running Slackware Linux 9.0,
in case anyone asks.</para>
</sect2>
</sect1>
<sect1 id="powermgm">
<title>Power Management</title>
<para>If you have a relatively recent x86 laptop, odds are it supports either
Advanced Power Management (APM) or Advanced Configuration and Power Interface
(ACPI). ACPI is the newer of the two technologies and puts power management in
the hands of the operating system, allowing for more intelligent power
management than is possible with BIOS controlled APM. You can only have one
management than is possible with BIOS controlled APM. This is most useful for battery-powered laptops.
You can only have one
power management interface in control of your machine at a time, so it's
important you decide which method best suits your situation.</para>
<sect2 id="apm">
<title>Advanced Power Management (APM)</title>
<para><emphasis>Advanced Power Management (APM)</emphasis>
is a method for saving power on your computer.
This is mostly useful for battery-powered laptops.
APM allows your computer's BIOS to control your system's power management
allows your computer's BIOS to control your system's power management
without the knowledge of the operating system.
The advantages to APM under Linux are that it's stable and has a solid history behind it. However, not much development has been
done with it over the past few years.</para>
The advantages to APM under Linux are that it's stable, well supported by Linux vendors and has a solid history behind it.
However, not much development has been done with it over the past few years.</para>
<para>To use it, you'll need to enable APM in the kernel. Most of the other APM
options exist as work-arounds for known problems with specific hardware devices,
@ -138,7 +94,6 @@ so you'll probably only want to enable the first one (CONFIG_APM).</para>
This is a workaround for a number of broken BIOSes. If your computer
crashes instead of powering off properly, turn this on.</para></listitem></itemizedlist>
<para>You'll want to install the APM daemon from
<ulink url="http://www.worldvisions.ca/~apenwarr/apmd/">http://www.worldvisions.ca/~apenwarr/apmd/</ulink>
and configure your system startup scripts to activate it on boot:</para>
@ -176,8 +131,7 @@ ACPI Linux is newer than APM Linux, more flexible in responding to power managem
much more development as of late, and as a result of all this is prone to its own share of bugs from
time to time.</para>
<para>If you're into cutting-edge development, are running a relatively recent
(>2.4.10) kernel, and are not intimidated with kernel
<para>If you're into cutting-edge development and are not intimidated with kernel
builds and applying patches against source code, ACPI is worth consideration.</para>
<para>There are two parts to ACPI under Linux: The ACPI driver built into the
@ -186,42 +140,38 @@ pretty simple: monitor /proc/acpi/event and do things in response. Even if
you don't load the daemon, you'll still get the benefit of ACPI features built
into the kernel such as processor thermal support.</para>
<para>When booting your ACPI-enabled system, you can determine which version
of the ACPI driver you are using by looking for something similar to this:
<para>You can determine which version
of the ACPI driver you are using, along with supported suspend states, by using:</para>
<screen>
ACPI: Subsystem revision 20030523
bash $ cat /proc/acpi/info
version: 20030619
states: S0 S1 S3 S4 S4Bios S5
</screen>
ACPI development is progressing at a steady rate, so you might want to consider
<para>ACPI development is progressing at a steady rate, so you might want to consider
<ulink url="http://sourceforge.net/project/showfiles.php?group_id=36832">patching</ulink>
your kernel against any recent updates to the kernel-level ACPI code. Once you have downloaded the
patch for your specific kernel, you can patch it with something like:
patch for your specific kernel, you can patch it with something like:</para>
<screen>
$ gunzip acpi-[version]-[kernel].diff.gz
# mv acpi-[version]-[kernel].diff /usr/src/linux-[version]
# cd /usr/src/linux-[version]
# patch -p1 < acpi-[version]-[kernel].diff
bash$ gunzip acpi-[version]-[kernel].diff.gz
bash# mv acpi-[version]-[kernel].diff /usr/src/linux-[version]
bash# cd /usr/src/linux-[version]
bash# patch -p1 < acpi-[version]-[kernel].diff
</screen>
You'll want to recompile your kernel after this, of course.</para>
<para>You'll want to recompile your kernel after this, of course.</para>
<para>You'll also want to install the ACPID daemon from
<ulink url="http://sourceforge.net/project/showfiles.php?group_id=33140">http://sourceforge.net/project/showfiles.php?group_id=33140</ulink>
and configure your system startup scripts to activate it on boot:</para>
<screen>
if [ -x /usr/sbin/acpid -a -d /proc/acpi ]; then
echo "Starting ACPID Daemon: /usr/sbin/acpid"
/usr/sbin/acpid
fi
</screen>
<para>A bit of history... Microsoft was the first vendor to implement ACPI. This is both good and
@ -243,6 +193,10 @@ kernel. This presents a slight dilemma in that Linux distributions want to
ship kernels that run on as many systems as possible, but there have been some
positive moves in this area lately.</para>
<para>To conserve energy while remaining quickly available, ACPI-compatible PCs may enter system sleep states. The ACPI specification defines five of these states, known as S-states. Unlike processor sleep states, no work is done by the system under S-states. Each state introduces greater power savings but requires commensurately more time to awaken and begin performing work. These are patterned on system states from the APM standard, a predecessor of ACPI.</para>
<para>Full details on ACPI sleep states are available at <ulink url="http://acpi.sourceforge.net/documentation/sleep.html">http://acpi.sourceforge.net/documentation/sleep.html</ulink>. Processor states are described at <ulink url="http://acpi.sourceforge.net/documentation/processor.html">http://acpi.sourceforge.net/documentation/processor.html</ulink>.</para>
<para>For more specific background information on ACPI itself, you can visit
the ACPI website at
<ulink url="http://www.acpi.info">http://www.acpi.info</ulink>
@ -251,21 +205,29 @@ the ACPI website at
<sect2 id="whichone">
<title>APM vs. ACPI: Which one?</title>
<para>There are currently two competing standards for providing power management: APM and ACPI. Both cannot be used at the same time, so which one is best for your situation? If you have a relatively recent (>2.4.10) kernel and are not intimidated by kernel builds and patching source code, you'll find many benefits with the flexibility of ACPI. If you just want to enable generic power management, or are using an older machine, choose APM. Neither method spins down idle hard drives; use hdparm for that instead. Either way, your system's BIOS must correctly support the power management scheme you'd like to use as well; if your system does not fully support either standard, some of the power management options might crash your system and/or cause data loss. You have been warned!</para>
<para>There are currently two competing standards for providing power management: APM and ACPI. Both cannot be used at the same time, so which one is best for your situation? If you have a relatively recent (>2.4.20) kernel and are not intimidated by kernel builds and patching source code, you'll find many benefits with the flexibility of ACPI. If you just want to enable generic power management, or are using an older machine, choose APM. Neither method spins down idle hard drives; use hdparm for that instead. Either way, your system's BIOS must correctly support the power management scheme you'd like to use as well; if your system does not fully support either standard, some of the power management options might crash your system and/or cause data loss. You have been warned!</para>
<para>Regardless, you should be aware that even if you don't enable any power management on your laptop, on the x86 architecture Linux will always issue the "hlt" instruction to your processor whenever nothing needs to be done. This results in lowering the power consumption of your CPU. Note that the system doesn't power down when it receives the hlt instruction; it just stops executing instructions until there is an interrupt.</para>
<para>Even if you don't enable power management on your x86-laptop, Linux will always issue the HLT instruction to your
processor whenever nothing needs to be done
<footnote><para>source/arch/i386/kernel/process.c</para></footnote>.
Many Microsoft Windows CPU cooling program use this technique. This results in lowering the power consumption of your CPU. Note that the system doesn't power down when it receives the HLT instruction; it just stops executing instructions until there is an interrupt.</para>
<para>Some system manufacturers may have omitted the pre-ACPI tables used for
SMP configuration. In this case, ACPI is required. If a system supports
SMP configuration. In this case, ACPI is required
<footnote><para>Andrew Grover</para></footnote>.
If a system supports
HyperThreading, it must use ACPI tables to discover all the virtual processors
present. IA64 machines require ACPI, and NUMA servers are starting to require
it for proper initialization as well. There is generally no advantage to
it for proper initialization as well.</para>
<para>There is generally no advantage to
enabling either type of power management on servers or workstations that do not fall into
these categories.</para>
<para>One item to consider is actual <emphasis>use</emphasis>: Try using your laptop under both APM and ACPI. You'll probably
be suprised if both methods provide approximately the same amount of power savings (hint, hint)!</para>
</sect2>
</sect1>
@ -275,6 +237,12 @@ be suprised if both methods provide approximately the same amount of power savin
<title>Power Management Techniques</title>
<para>The basic goal of any power management technique is to reduce an entity's consumption. In the case of laptop power management, our focus is on decreasing CPU and hard drive usage. To make things a bit simpler, this is broken down into <emphasis>obvious, semi-obvious,</emphasis> and <emphasis>non-obvious</emphasis> techniques. Granted, your mileage may vary.</para>
<sect2 id="suspend">
<title>Suspend to Disk</title>
<para>Suspend to Disk (S2D) is still an elusive task under Linux. The main project at the moment is swsusp, available at <ulink url="http://sourceforge.net/projects/swsusp">http://sourceforge.net/projects/swsusp</ulink>. It's still in beta and requires manual patching of the kernel source.</para>
</sect2>
<sect2 id="hdparm">
<title>hdparm Tuning</title>
@ -286,21 +254,18 @@ For example, the following provides 32-bit IO support with sync (-c3), DMA suppo
<para>In the following example, we run some read/write benchmarks of our hard drive before and after using <command>hdparm</command>.
Note that while our cache reads remain about the same, our actual physical reads from the drive increase tremendously!
If you like living on the edge, you can play with the -m, -c, -B, and -u switches with caution (see the man page).
If you like living on the edge, you can play with the -m, -c, -B, and -u switches with caution (see the man page).</para>
<screen>
# hdparm -tT /dev/hda
bash# hdparm -tT /dev/hda
Timing buffer-cache reads: 588 MB in 2.01 seconds = 292.15 MB/sec
Timing buffered disk reads: 14 MB in 3.46 seconds = 4.05 MB/sec
# hdparm -k1 -K1 -c3 -d1 -W1 /dev/hda
# hdparm -tT /dev/hda
bash# hdparm -k1 -K1 -c3 -d1 -W1 /dev/hda
bash# hdparm -tT /dev/hda
Timing buffer-cache reads: 596 MB in 2.01 seconds = 297.01 MB/sec
Timing buffered disk reads: 72 MB in 3.05 seconds = 23.58 MB/sec
</screen>
</para>
</sect2>
@ -310,7 +275,9 @@ Timing buffered disk reads: 72 MB in 3.05 seconds = 23.58 MB/sec
and to optimize its performance.
If you don't want to log any system activity, consider disabling syslogd and klogd entirely or,
at the very least, minimize the amount of logging your system performs.
You can also prefix each entry with the minus sign (-) to omit syncing the file after each log entry.
You can also prefix each entry with the minus sign (-) to omit syncing the file after each log entry
<footnote><para>syslogd.c</para></footnote>.
For example, this will log anything with a priority of <emphasis>info</emphasis> or higher, but lower than
<emphasis>warning</emphasis>, to <command>/var/adm/messages</command> or <command>/var/adm/mail</command>
@ -318,15 +285,11 @@ without needing to sync to disk after each write. Since we want to keep all mes
<emphasis>warning</emphasis>, this will be logged to a different file without disabling
disk syncing (to prevent data loss in the event of a system crash).</para>
<para>
<screen>
*.warning /var/adm/syslog
*.info;*.!warning;mail.none -/var/log/messages
mail.info;mail.!warning -/var/log/mail
*.warning /var/adm/syslog
*.info;*.!warning;mail.none -/var/log/messages
mail.info;mail.!warning -/var/log/mail
</screen>
</para>
<para>Another item to be aware of is the <command>-- MARK --</command> messages that <command>syslogd(8)</command> writes.
This will affect your hard drive inactivity settings. You can simply disable this by running <command>syslogd(8)</command> with:</para>
@ -352,7 +315,10 @@ The first is simply a fake "blanking" effect that doesn't actually save any powe
DPMS-compliant monitors, and must be specifically enabled to take effect. They are located in your <command>XF86Config</command>
file, which normally resides in <command>/etc/X11/XF86Config</command>.</para>
<para>DPMS (Display Power Management Signaling) is a standard to reduce power consumption in monitors.
<para>DPMS (Display Power Management Signaling) is a standard to reduce power consumption in monitors
<footnote><para>http://www.vesa.org/vbe3.pdf</para></footnote>.
Typically, both the monitor and the video card must support the DPMS standard in order to receive any
benefit from it. DPMS specifies four modes of operation (in order of increasing power savings):
"Normal", "Standby", "Suspend" and "Off". Two signal lines, "Horizontal Sync" and
@ -387,8 +353,8 @@ EndSection
<para><command>BlankTime</command>
is not actually a power saving level at all. The screen is sent
a "fake" blanking effect and defaults to activate after 10 minutes. It has
nothing to do with DPMS.</para>
a "fake" blanking effect and defaults to activate after 10 minutes. Alternately, it can indicate the number of
minutes until the screensaver should activate. It has nothing to do with DPMS.</para>
<para><command>StandbyTime</command>
is a very minor power saving level. This setting usually involves
@ -486,15 +452,12 @@ to determine how much free memory you've got on average, and whether or not your
<para>For example, today I've compiled several intensive programs and have been running my laptop for about eight hours straight.
A simple examination of my system reveals:</para>
<para>
<screen>
$ cat /proc/swaps
bash$ cat /proc/swaps
Filename Type Size Used Priority
/dev/hda3 partition 136544 0 -1
$ cat /proc/meminfo
bash$ cat /proc/meminfo
MemTotal: 513880 kB
MemFree: 254820 kB
Buffers: 42812 kB
@ -521,7 +484,6 @@ HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
</screen>
</para>
<para>Given this, I'd opt to disable my swapfile if this is any indicator of my future usage.</para>
</sect2>
@ -535,10 +497,9 @@ that it lives in the kernel internal cache and grows and shrinks to accommodate
See your kernel's Documentation/filesystems/tmpfs.txt for full information. If you don't specify a maximum
size, it will default to a ceiling limit of half your available memory.
An example /etc/fstab with 100MB temporary ram file mounted on /tmp would look like:
<screen>
tmpfs /tmp tmpfs size=100m,mode-1777 0 0
tmpfs /tmp tmpfs size=100m,mode=1777 0 0
</screen>
</para>
</sect2>
@ -546,6 +507,11 @@ An example /etc/fstab with 100MB temporary ram file mounted on /tmp would look l
<sect2 id="misc">
<title>Miscellaneous Tuning</title>
<para>
Modifying /proc/sys/vm/bdflush allows a user to specify under what
circumstances dirty buffers are flushed to disk, how many such
buffers exist, etc. Details are in linux_src_tree/Documentation/sysctl/vm.txt (thanks to Marc Liberatore for pointing this out).</para>
<para>Boot your system and list the currently loaded modules with lsmod.
Anything listed here most likely needs to be loaded on a regular basis;
compiling these in as part of your kernel rather than as loadable modules may
@ -598,13 +564,7 @@ whether or not your system is on battery power.</para></listitem>
<sect2 id="myth">
<title>Power Saving Myths</title>
<para>One popular pastime involved modifying the update/bdflush
daemon to change the frequency of flushing the filesystem buffers (sync).
However, the current Linux kernels do not use a user space update daemon any more,so any
modifications you make here will simply never take effect.</para>
<para>It used to be beneficial to recompile the Linux PCMCIA drivers to allow the slots to have APM power support.
However, most of the functionality of these drivers are now built into the kernel itself.
<para>It used to be beneficial to recompile the Linux PCMCIA drivers to allow the slots to have APM power support. However, most of the functionality of these drivers are now built into the kernel itself.
If you're interested in specifics, the PCMCIA project page is available at
<ulink url="http://sourceforge.net/projects/pcmcia-cs/">http://sourceforge.net/projects/pcmcia-cs/</ulink>.
</para>
@ -732,6 +692,23 @@ or burns.</para>
</sect2>
</sect1>
<sect1 id="intro">
<title>Appendix</title>
<para>This document was lovingly handcrafted on a Dell Latitude C400 laptop running Slackware Linux 9.0,
in case anyone asks.</para>
<para>This document would not have been possible without the excellent material initially developed by Hanno Muller <email>kontakt@hanno.de</email>.</para>
<para>This material may be distributed only subject to the terms and conditions set forth in the
Open Publication License, v1.0 (available at http://www.opencontent.org/openpub/).</para>
<para>This document is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.</para>
</sect1>
</article>
<!-- Keep this comment at the end of the file