even if the read is from the cache. One
work-around is to disable atime updates entirely, but this breaks certain
applications. A subtler work-around
is to update the atime if the file was
modified more recently than it was last
read. This avoids breaking mail applications that depend upon the atime to
determine whether mail has been read
or not. This provides a dramatic reduction in write activity to the disk and
makes it more likely that spinning the
drive down will be worthwhile.
The drive is not the only part of the
I/O system where savings are possible.
The AHCI (Advanced Host Controller
Interface) specification for serial ATA
controllers includes link-level power
management. In the absence of any
pending commands, the link between
the drive and the controller can be
powered down, saving about 0.5 watts
of power. The cost is a partial reduction in functionality—hotplug events
will no longer be generated.
Network hardware provides a similar dilemma. If an Ethernet device is
not in use, it makes sense to power it
down. If the Ethernet PHY is powered
down, however, there will be no interrupt generated if an Ethernet cable
is plugged into the device. Power has
been saved, but at the cost of some
functionality. An almost identical
problem occurs when detecting hot-plugging of monitors.
This is perhaps the most unfortunate side of power management. In
many cases, hardware consumes power because that power is required to
provide functionality. Many users may
not care about that loss of functionality, but disabling it by default causes
problems for those who do. Although
hardware support for power management has improved hugely over recent
years, the biggest challenge facing operating-system developers may in fact
be how to integrate that support in a
way that doesn’t frustrate or confuse
users.
In an attempt to encourage power
management, Intel has released a tool
called PowerTOP (referring to the top
command used to see which processes
are consuming the most CPU on Unix
systems). PowerTOP uses diagnostic
information from the Linux kernel
to determine which applications are
triggering CPU wake-ups, allowing
developers to spot misbehaving applications and optimize their power consumption.
PowerTOP has already provided
benefits for Linux desktop software.
The 7.04 release of Ubuntu ran at about
400 wake-ups a second. Optimizations
and bug fixes in response to issues
raised by Power TOP allowed this to be
reduced to fewer than 100 on most systems, with figures under 30 achievable
on systems with disabled wireless and
Bluetooth.
PowerTOP also provides information about other aspects of a system
that may be consuming power. The system is probed to determine whether it
has any configuration that may impair
power savings, such as disabled USB
autosuspend or audio codec power
management, and Power TOP suggests
ways to fix the problem. The information provided is probably excessively
technical for the average user, but it allows vendors to ensure they are taking
full advantage of available power management options.
Though developed and sponsored
by Intel, the advice provided by PowerTOP is fairly general and appropriate
to most Linux-based systems. Arguably, the most important way in which
it has been successful is not in the
functionality it provides in itself, but
the increased awareness of the issues
involved that it has generated in the
open source community. It remains to
be seen whether proprietary vendors
will start providing similar functionality to users and developers, but many
of the same issues apply and need to
be solved in similar ways.
Power management for the masses
The One Laptop Per Child XO machine is an interesting case study in
power management, perhaps sharing
more in common with the embedded
world than with traditional laptops.
Its aggressive power management
is designed to allow the platform to
suspend even when the machine is in
use, something made possible by the
display controller’s ability to scan out
the framebuffer even when the CPU
isn’t running. The mesh networking
capability of the hardware requires
machines to continue routing packets
even when suspended, and hence the
wireless hardware has also been de-
signed to forward data without processor intervention. Price considerations
have meant that the XO machine cannot depend on the latest battery technology; therefore, the machine must
consume as little power as possible to
keep the network functioning effectively.
This level of power management
would be unthinkable in the traditional laptop world, where even the
best implementations still take on the
order of a second to return to a state
where the user can interact with the
system. A major focus has therefore
been to reduce the time taken to bring
the device back from suspend, making
it practical to suspend the device when
idle without impairing the user experience. This requires a high level of
robustness, and much of the development work has been focused on ensuring that components resume in a reliable and consistent manner. A failure
rate of one in every 10,000 suspend/
resume cycles might be considered
acceptable in the mainstream laptop
world, but would impair the user experience on the XO.
As users demand longer battery life
and become increasingly concerned
about wasted energy, power management has become more important to
vendors. A well-rounded power management strategy requires integration
of hardware, firmware, and software,
as well as careful consideration of how
to obtain the maximum savings without making the user aware of any compromised functionality. Future years
are likely to see tighter integration
and a greater awareness of good power
management practices, and all-day
computing may soon become a practical reality.
Matthew Garrett ( mjg59@srcf.ucam.org) is a software
engineer at Red Hat, specializing in power management
and mobile hardware support.
A previous version of this article appeared in ACM Queue,
Nov/Dec 2007, Vol. 5, No. 7.