1. Power Management

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. 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.

1.1. Advanced Power Management (APM)

Advanced Power Management (APM) 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, 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.

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, so you'll probably only want to enable the first one (CONFIG_APM).

You'll want to install the APM daemon from http://www.worldvisions.ca/~apenwarr/apmd/ and configure your system startup scripts to activate it on boot:


# Start the APM daemon if APM is enabled in the kernel
if [ -x /usr/sbin/apmd -a -d /proc/apm ]; then
	if cat /proc/apm 1> /dev/null 2> /dev/null ; then
		echo "Starting APM daemon:  /usr/sbin/apmd"
		/usr/sbin/apmd
	fi
fi

The APM daemon is actually made up of three primary programs:

If you're looking for a simple, "works out of the box" approach to power management for your Laptop, APM is definitely the way to go.

1.2. Advanced Configuration and Power Interface (ACPI)

Advanced Configuration and Power Interface (ACPI) is the successor to APM, which places the responsibility of power management away from the BIOS and into the hands of the operating system. ACPI Linux is newer than APM Linux, more flexible in responding to power management events, has seen 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.

If you're into cutting-edge development and are not intimidated with kernel builds and applying patches against source code, ACPI is worth consideration.

There are two parts to ACPI under Linux: The ACPI driver built into the kernel itself, and the ACPI daemon (ACPID). ACPID in its current incarnation is 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.

You can determine which version of the ACPI driver you are using, along with supported suspend states, by using:

bash $ cat /proc/acpi/info
version:                 20030619
states:                  S0 S1 S3 S4 S4Bios S5

ACPI development is progressing at a steady rate, so you might want to consider patching 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:

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

You'll want to recompile your kernel after this, of course.

You'll also want to install the ACPID daemon from http://sourceforge.net/project/showfiles.php?group_id=33140 and configure your system startup scripts to activate it on boot:

if [ -x /usr/sbin/acpid -a -d /proc/acpi ]; then
	echo "Starting ACPID Daemon:  /usr/sbin/acpid"
	/usr/sbin/acpid
fi

A bit of history... Microsoft was the first vendor to implement ACPI. This is both good and bad. It is good because when you buy a system, you can pretty much guarantee that it has passed Microsoft's hardware compliance tests, including the test of its ACPI implementation. However, these tests come up short in that they do not indicate compliance with the ACPI specification, but rather with Microsoft's implementation of ACPI. When that same machine is used with Linux, some classes of errors that did not manifest themselves under Windows may become apparent. To protect against this problem, the Linux ACPI driver maintains a "bad BIOS" blacklist of known BIOS's that are known to not be ACPI compliant, and as a result will refuse to enable ACPI if your system is listed.

Many manufacturers are now validating that their systems run on Linux. However, they use major Linux distributions with the default kernel. This means that it is somewhat difficult to get OEMs to ensure that their systems work with ACPI-enabled Linux until a major Linux distribution ships an ACPI 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.

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.

Full details on ACPI sleep states are available at http://acpi.sourceforge.net/documentation/sleep.html. Processor states are described at http://acpi.sourceforge.net/documentation/processor.html.

For more specific background information on ACPI itself, you can visit the ACPI website at http://www.acpi.info

1.3. APM vs. ACPI: Which one?

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!

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 [1]. 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.

Some system manufacturers may have omitted the pre-ACPI tables used for SMP configuration. In this case, ACPI is required [2]. 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 enabling either type of power management on servers or workstations that do not fall into these categories.

Notes

[1]

source/arch/i386/kernel/process.c

[2]

Andrew Grover