Hardware is evolving quickly and both operating system designers and end users must keep up with these rapid changes. In this short paper, we'll show how Linux is evolving to support the many hardware circuits used to track power consumption and to monitor hardware, and how the end user may take advantage of them.
In the good old days, circuits had to be soldered by hand, putting together electron tubs, resistors, and capacitors. These circuits, or chips, were used to fulfill a single objective: execute program instructions.
In the '60s, transistors replaced electron tubs and some circuits could be spared to perform additional tasks, such as translating logical addresses into physical ones, issuing interval timer interrupts, or detecting error conditions. Thanks to these new chips, it became possible to implement efficient, robust, and interactive multiuser operating systems.
Now, we live in an era where millions of transistors can be packed into a single chip, and the main business of chip designers consists of finding clever ways to use all these transistors. In fact, if you look at a modern motherboard, you'll find it filled with new, special-purpose chips, many of which came out with the first laptop computers.
Laptop users often power their portables by battery. The energy stored in such batteries ranges from 20 watt-hours to more than 60 watt-hours. This means, for example, that a laptop requiring 20 watts of power will keep operating for three consecutive hours when energized by a 60-watt-hours battery. Since batteries with higher energy ranges are quite expensive, the only way to increase a system's uptime while running on battery is to reduce power consumption.
How can this be achieved? Well, there are several ways, all based on the fact that it makes little sense to maintain a fully operational system when no one is using it. After all, most of us switch off the lights in the living room before going to bed!
Here are three well-known techniques for reducing power consumption:
Electronics designers are quite creative, so when they designed circuits to help reduce power comsumption, they did not limit the design to that function. Rather, they pulled out of their collective hats a brand new family of chips, which were labeled as hardware health-monitoring chips.
As with all good ideas, these new chips are easy to explain: Suppose the fan on top of a CPU chip is not working properly. Wouldn't it be better to switch the computer off automatically rather than letting the chip fry? The answer is, of course, yes. All of today's motherboards now include several sensors that monitor the hardware's health. The data gathered by these sensors typically includes speed of fans, voltage levels, motherboard temperature, chassis intrusion detection, and so on. And of course, the circuits that make use of these sensors include threshold settings to determine whether a sense value has exceeded its limit.
So far so good, but how does the user control all these nice features?
There are two basic ways to do this:
The first approach was the dominant one until a few years ago. Now the situation is changing, and new standards are emerging with different operating systems--and Linux in particular--wanting total control over the chips.
We'll offer a few examples of both approaches in the rest of this article. The first two examples refer to application programs and fall under the first approach, while the last two discuss operating system drivers and thus fall under the second approach. The keyboard controller example is a hybrid: the program is in BIOS and you may control it through the BIOS setup menu.
The integrated controllers found on IDE hard disks include a timer chip that allows you to automatically spin down a disk if it remains idle for a specified amount of time. Automatic switch-off of a hard disk is not usually performed on desktop computers, although it is almost mandatory on laptops to save battery power.
The Linux kernel doesn't directly interact with the power-management chips of IDE controllers. Therefore, you'll not find any mention of the IDE time-out in the Linux source code or in the configuration options of your kernel. However, you can set the power-management options of your IDE disk by means of an external system command named hdparm. It must be executed with super-user privileges because it chats directly with your IDE controller by reading and writing in its I/O ports.
The hdparm command has many functions, and you may want to read its manual page for a complete description of arguments and options. Be careful, since an incorrect setting of some parameters may lead to file-system corruption, and even to a disk crash. However, using the hdparm command to set up power management of your IDE disk is not so dangerous.
You must always specify the device file corresponding to your IDE disk to the hdparm command. Remember that the device file of the master device on the first IDE chain is usually named /dev/hda; the slave device on the first IDE chain is named /dev/hdb; the master device on the second IDE chain is named /dev/hdc, and the slave device on the second IDE chain is named /dev/hdd. In the following examples, we'll always refer to the device file name as /dev/hda, but you should rename it, if necessary.
A drive in standby mode will automatically awake whenever a disk operation is requested. Conversely, a drive in sleeping mode will awake only by a hard or soft reset of the IDE controller. However, the EIDE driver of the Linux kernel will automatically issue a reset of the controller when necessary. Be warned, however, that your drive may take as long as 30 seconds to wake up both from the standby mode and from the sleeping mode. Moreover, it'd be better to avoid too many spin downs and spin ups of your disk, so you may want to set the standby timer to a reasonably long interval of time.
Even user-level applications may implement power-saving features. For example, the command: xset s 60 instructs the X Window Server to switch off the screen if the server itself remains inactive for 60 seconds. No hardware timer is directly involved here, since the server receives any keypress and thus can implement the time-out mechanism on its own. Moreover, the Linux kernel is not aware of what is going on because the X server handles the graphics card directly.
Almost all laptops and many 'green' desktop computers include some embedded controllers that have power-management functionalities. The most common example is the keyboard controller. Its main task is to raise an interrupt whenever you press a key, and to send the corresponding scan code to the CPU. However, the keyboard controller also includes some circuits that monitor how much time has elapsed since your last keypress. Such circuits may also trigger some actions when your keyboard hasn't been touched for a specified amount of time. Typically, the controller may switch off the screen or put the CPU in a low power mode. Finally, the keyboard controller may trigger dedicated actions when you press some special 'hard-wired' keys of your laptop.
As you see, the embedded controller may handle several hardware devices. In order to do this, the controller includes a simple microprocessor that is able to execute procedures stored in ROM, EEPROM, or Flash Memory chips. These procedures usually are included in the Basic Input/Output System (BIOS) of your computer.
If you want to take advantage of the power management offered by the embedded controller inside your computer, you must enable these features in the BIOS Configuration Menu, which is usually accessible in the boot phase. You can typically set up timers for switching off the screen, for spinning down the hard disk, and for putting the CPU in power save mode. You can also define some events that automatically wake up your machine, like receiving a packet on your network card or detecting a phone call on your modem.
All these functionalities are standardized today. The most common standards are Advanced Power Management (APM) and Advanced Configuration and Power Management (ACPI). As we shall see shortly, these standards allow the operating system to have some control over the power management of the machine. However, if your Linux kernel has been compiled without support for APM or ACPI, your embedded controller will act on its own.
All owners of laptops know well that they need some feedback from the computer on the status of the battery charge. For instance, if you're using a text editor, wouldn't you appreciate a warning from the system that your battery power is about to run out? The warning would give you a chance to save your work on disk, or to recharge your battery. Most laptops include a chip that monitors the battery charge and issues a warning by ringing a bell or flashing some LED. When this happens, however, you don't really know how much time is left before your laptop dies.
By issuing suitable commands to the chip that monitors the battery charge, an operating system or a user-level application could get the current battery level and extrapolate how much time remains. Unfortunately, every laptop model has a different chip that monitors the battery level, and each chip has its own I/O ports and its own command protocol. In order to standardize the access to the battery power chips, Intel and Microsoft introduced Advanced Power Management (APM) in 1991. This standard defines a set of BIOS procedures that can be used by compliant operating systems to query the status of the batteries, thus hiding the hardware details of the power-management chips.
If you want to take advantage of APM on your Linux box, you must run a kernel that has been compiled with the configuration option "Advanced Power Management BIOS support" enabled. To check if your kernel has APM support, simply look for the /proc/apm virtual file. If you can't find it, you must recompile your kernel. If you do have APM support, you can read the file and get a line like the following:
$ cat /proc/apm
1.13 1.2 0x07 0x00 0x01 0x01 14% 20 min
When you read the file, the kernel queries the APM BIOS procedures, and then it generates the line. The first field is the version number of the APM Linux driver. The second field is APM version of your computer as reported by the BIOS (usually 1.0, 1.1, or 1.2). The third field is a bitmap of flags describing the power-saving capability of your computer. For instance, the flags indicate whether the BIOS slows down the CPU when it's idle, or whether the APM BIOS support is enabled. The fourth field tells you the current AC line status: usually the field is equal to '0' if your laptop is offline, and equal to '1' if it is plugged into the AC line. The fifth and sixth fields represent the current battery status: high, low, critical, charging, no battery, or unknown. The seventh field is usually a number from 0 to 100 that shows the remaining battery life as a percentage of charge. The eighth and ninth field shows the remaining battery life in minutes or seconds.
Of course, you are not compelled to read and decipher for yourself the /proc/apm virtual file: this task is best done by a user-level application like the apmd daemon. The apmd daemon may execute arbitrary tasks whenever an APM event occurs. For instance, you can configure it so that the system displays an alert when your battery level becomes low. Another useful user-level application distributed together with apmd is called xapm. It displays a small window on your desktop with a bar graph indicating the current battery level.
The APM Linux driver included in the kernel is also useful when you press the standby or suspend keys of the laptop's keyboard. The standby mode saves some power by spinning down the disk and switching off the screen, but it allows the computer to wake up almost immediately after a keypress or a mouse movement. The suspend mode saves power in an aggressive way by shutting off all hardware devices except the memory chips. The CPU is also put in a very low power mode. When the system resumes after a standby or suspend mode, the kernel must perform some critical operations, like reinitialize the hardware devices that were switched off and synchronize the system time with the hardware real-time clock (RTC). (If your laptop resumes after standby or suspend mode and your Linux kernel doesn't support APM, your system may crash or hang up.)
The APM Linux driver is also useful for modern desktop computers because the APM BIOS includes a procedure for powering off the system. On these machines, the super-user command: $ shutdown -h now brings the system down and then switches off the power automatically. If your system has a graphical login, you'd obtain the same result by selecting the "Shutdown and power off" menu. Finally, if you're an old-style kernel hacker, and you want to power-off the computer with the "Three Finger Salute" (<CTRL>+<ALT>+<DEL>), you might edit the ctrlaltdel line of the /etc/inittab file as: ca::ctrlaltdel:/sbin/shutdown -t10 -h now.
An interesting alternative to the usual shutdown is hibernation: Before switching off the power, the operating system or the BIOS saves the information about the RAM contents and the state of all hardware devices on disk. At reboot time, this information is used to set up the computer. A few laptops have a BIOS hibernation procedure that works without problems in Linux: Just use the suitable key on your keyboard. Alternatively, a patch for Linux 2.2 exists, but it is not clear whether such functionality will be included in the forthcoming Linux 2.4 kernel version.
The APM standard has other interesting features. Let's suppose you're watching your favorite show using a TV video card inside the computer. At once, the monitor screen goes black! What happened? You didn't touch the keyboard for a long time, and thus the embedded controller decided to save power. It would be quite obnoxious to reboot the computer and disable power management in the BIOS every time you want to watch television. It would be better to automatically disable power-saving mode when the video card is working.
The APM standard grants what's called a 'veto right' to a compliant operating system. Whenever an embedded controller wishes to enter power-saving mode, it politely asks the kernel whether it agrees. In our scenario, the kernel could check that an application is using the video card, and deny the embedded controller to switch off the screen. However, a missing answer from the kernel means 'I agree.' This is a legacy trick that allows APM to work fine on noncompliant operating systems.
Unfortunately, the APM Linux drivers included in the current 2.2 version and in the last 2.4-test10 version do not support the veto right. The Linux kernel always enters power-saving mode whenever the APM BIOS requests it. More recent APM Linux driver versions exist, but they were not integrated in the official kernel source code. If you feel adventurous, you can get the 2.4 patch for the new APM driver and apply it yourself. A user-level application can then tell the kernel that it wants to disable power-saving modes by opening the /dev/apm_bios file and issuing a suitable ioctl() system call on it.
The APM standard has several limitations:
The Advanced Configuration and Power Interface (ACPI) was introduced in 1997 by Intel, Toshiba, and Microsoft to remove such limitations. The ACPI standard is rather complex. For instance, it defines an architecture-independent language to specify the capabilities of each hardware device included in the system. In the boot phase, a BIOS procedure builds tables containing the device descriptions. An ACPI-compliant kernel can thus handle each device in the best possible way. Actually, ACPI is much more than a new interface for power management: it defines a 'plug and play' interface that is compatible with old plug and play architectures like ISAPNP, PCI, and PC Card (PCMCIA).
ACPI-based power management is quite different from APM-based power management. While the APM operating system driver must keep polling the BIOS to be aware of APM events, ACPI is interrupt driven: each CPI-compliant hardware device may issue an interrupt to notify the kernel about a power-management event. Moreover, the kernel may force any single device to enter a power-saving mode. In this way, only non-idle devices receive power, while the others may be low-powered or switched off.
In short, ACPI defers to the operating system the task of implementing power-saving strategies, and thus is much more customizable than APM. Also, thanks to ACPI, the operating system takes control whenever a sensor, for example, a CPU temperature sensor, crosses some predetermined limits.
ACPI is quite recent and hardware manufacturers are still working on making their devices compliant with the new standard. As a matter of fact, several ACPI implementations are incomplete or buggy. You can check how your machine supports ACPI by looking at a list of compliant BIOS.
If you want to take advantage of ACPI, you need a 2.4 Linux kernel and some user-level applications like acpid and pmtools. If your kernel has been compiled with ACPI support, you'll find a /proc/sys/acpi virtual directory. However, you should never try to use this virtual directory directly. Instead, you can rely on the user-level daemon acpid.
Let's suppose that you press the power button when your computer is on. As a consequence, an interrupt is raised, and the kernel writes an event code in the /proc/sys/acpi/event virtual file. The acpid daemon monitors this file, and reacts to the event by putting the machine at run-level 0, thus forcing a clean shutdown. Of course, the user-level acpid daemon is easily customizable. For instance, it could either switch off the computer or just enter the suspend mode, according to the time of the day.
Be warned that the current level of ACPI support in Linux is rudimentary. As stated in the Linux-ACPI HOWTO, the kernel supports only sleep mode, resume from sleep mode, and power-off capabilities. The acpid daemon is also quite simple, and it can't be configured by the user. This is a work in progress, however, and sooner or later, we'll have a complete implementation of the ACPI standard in our Linux box.
Are you confused by all these power-saving methods and standards? Keeping these three suggestions in mind should help:
And a last word of advice: Do not use more than one power-saving method at the same time! In particular, if you stick to APM, then you should disable the IDE time-out mechanism (using hdparm), and the X Window Server screen blanking (using xset). Otherwise, strange interactions between the power-saving methods might occur and your hardware devices could react in some unpredictable way.