The Linux power management summit

On 11 April 2006, 42 attendees from 17 different companies (and 3 universities) arrived in Santa Clara, California for the 2006 Linux Power Management Summit. The Summit was organized by your author, in conjunction with the Consumer Electronics Linux Forum (CELF), which held its Embedded Linux Conference the same week, and with the OSDL Desktop Linux Working Group. Along with CELF, summit sponsors included Intel, Nokia, Google, AMD, FreeScale, and Texas Instruments. The attendees represented over a dozen open source projects, from the low-level embedded (DPM/PowerOp) to the high-level (freedesktop.org) to the broadest (Fedora, SUSE, and Ubuntu distributions). With such a diverse crowd of people, if nothing else, it promised to be an interesting week of discussions.

The Summit spanned 3 days, starting with a welcome reception on Tuesday evening, 11 April and going until mid-day on Friday, 14 April. Wednesday and Thursday were filled with hour-long sessions led by an individual from a project or a company. The sessions were designed to foster discussion, though the format was left entirely up to the presenter. Most had a backing presentation of talking points, and each one succeeded in keeping the discussions flowing.

Wednesday's presentations were centered around various Open Source Power Management projects. First Pavel Machek talked about Linux Suspend [PDF] (Suspend-to-Disk and Suspend-to-RAM), giving an overview of its history, its implementation, and the issues that continue to inhibit the suspend operations from "just working" in the way that people want them to. He spoke about uSwsusp, which moves the suspend functionality to userspace, allowing for less in-kernel complexity and an easier implementation of the user-friendly features found in Nigel Cunningham's Suspend2 patches; and he spoke about the main problem with getting Suspend-to-RAM to work: video drivers.

Len Brown next talked about ACPI [PDF], and what that meant to power management. Len gave an overview of the generic ACPI components (the tables, the ASL compiler. the AML interpretor, and the ACPICA (Component Architecture)), and the Linux implementation (code organization, ACPI device drivers, acpid). He then dove into ACPI power states, and specifically how it represented and implemented CPU C States (idle states that vary in latency to return) and P States (performance states that vary in CPU speed).

Len's session provided a good lead-in to Dominik Brodowski's session about cpufreq [PDF], which does dynamic CPU frequency scaling based on policy and intelligence about measuring and predicting the load. Dominik described the architecture of the subsystem, how decisions were made, and how they were effected via the CPU drivers. He then spoke about the desire to extend cpufreq beyond just frequency scaling (and include voltages and clocks), beyond single CPUs (to be smarter about managing multiple cores and threads), and beyond CPUs in general (to include policy and drivers for other devices with similar functionality).

Todd Poynor and Matthew Locke's session about DPM and PowerOp [PDF] followed, providing a perspective on the same topic from the other end of the tunnel. DPM (Dynamic Power Management) is infrastructure to manage the "Operating Points" of a system, which are states consisting of pre-defined tuples of voltages and clocks (and therefore frequencies). To coordinate and set the voltages and clocks (which usually must be done for several devices in unison), DPM uses a low-level interface called PowerOp. DPM is practically ubiquitous in embedded Linux implementations, though it lives in an out-of-kernel patch.

The next hour was split between Holger Macht -- who talked about SUSE power management -- Dave Jones, who spoke about Fedora power management, and a guest speaker who spoke about Ubuntu power management. SUSE provides an application called powersave that provides a command-line interface (which can then be wrapped by a GUI) for managing suspend states, CPU PM, and some device states (recently added). The Fedora and Ubuntu power management concerns have both centered around getting suspend/resume to work reliably for their users. Both Fedora and Ubuntu seem to use gnome-power-manager as the primary interface for managing power; this tool doesn't expose as many knobs and levers (literally and figuratively) as the powersave family of utilities do.

All of the distributions now provide quite a large list of support for power management (especially suspend/resume) on various laptop models.

• Ubuntu Laptop Support List
• Fedora Laptop Compatibility List
• openSuSE Laptop Compatibility List

To finish off the day, Jim Gettys and Mark Foster from the One Laptop Per Child project spoke about the design and challenges of the $100 Laptop [PDF], especially around power management. Specifically, they are looking for very efficient hardware and software solutions so that charging the battery requires minimal energy and so that the battery lasts an exceptionally long time (by today's standards). Mark presented a proposal [PDF] of a mechanism for achieving a resume-from-RAM in < 300ms.

Sampsa Fabritius from Nokia started the Thursday sessions [PDF] off with a presentation of the power management framework used on the Maemo platform (which is used in the Nokia 770). Maemo is based on GNOME, but it uses a custom power configuration and management scheme, rather than one based on Utopia/HAL/DBUS. At a lower level, they have also written a "clocks" framework for articulating and controlling clock domains (of which the OMAP platform has many). Based on the previous day's discussions, Sampsa presented the question of whether or not it was possible (and prudent) to define a common solution of power configuration and management (or common set of solutions), since many platforms and interfaces are trying to accomplish similar things, sometimes with a set of similar components.

A set of people from the Texas Instruments OMAP division -- Eric Thomas, Shiv Ramamurthi, and Richard Woodruff -- spoke about the OMAP platform, its goals, and the challenges faced with leveraging its power management potential. OMAP has a rich set of power management techniques, and unlike most desktop platforms, it exposes all of the low-level components (clocks, clock domains, power domains, and voltage domains) to the kernel and requires it to coordinate the scaling of each. This is currently done with a modified version of DPM, along with a custom set of scripts and control framework to set and manage the operating points of the system.

Quinn Jensen from FreeScale used the next hour to speak about the MX31 platform [PDF], an ARM 11-based system-on-a-chip that is similar in nature to the OMAP. It has many power management features centered around dynamic voltage and frequency scaling (aka DVFS). Not surprisingly, they are also using a custom version of DPM and associated control infrastructure to control the hardware. Like the others, they are running into limitations of the framework, since it only deals with the lowest-level components and doesn't provide a rich(er) policy framework (like cpufreq does).

Mark Gross, representing CELF, presented a summary of the CELF power management requirements [PDF], as expressed by the CELF member companies. The most important items seemed to be the refinement and inclusion of a dynamic tick/tick-less idle solution (which underscored the use of such solutions by previous presenters), and a mainstream solution for DVFS (a la DPM) that provided a robust policy management (a la cpufreq). Much of the discussion that followed was about the details of a common interface for these solutions.

Jacob Shin from AMD presented next about the low-level details of AMD CPU PM [PDF], specifically how PowerNow works on multi-core K8 processors, and the changes that were necessary to the CPU hotplug and cpufreq bodies of code to support it.

Thursday ended with a birthday celebration for Adam Belay, then an open discussion about the topics covered so far and the issues that were on peoples' minds.

Friday began with another open discussion about what the overall architecture and framework that is needed for power management on any system. After several diagrams, doodlings and lists went up on the wall on gigantic Post-It Notes, the group broke into three smaller groups to talk about the three primary layers of power management and how they might be able to share functionality or features between different platforms and solutions.

• Low level hardware configuration and control. This discussion was centered around how to describe different levels of "on-ness" and "off-ness" to high levels in a manner that made the most sense (to both the device drivers and the consumers of such an interface).

• The kernel-user space interface. This discussion was based on the assumption that the gap between DPM's low-level management framework and cpufreq's policy framework can and should be bridged in some manner. From there, this group discussed how to design a common interface (via sysfs) which could be used by a user-space policy mechanism to control CPU operating points.

• The user space framework that must exist in user space to provide good power management. There are a number of existing solutions for monitoring various types of hardware, monitoring and predicting system load, handling PM-related events, and managing policy. But, they are all disjoint, overlapping only occasionally, and most do not do as good of a job as anyone would like.

It was a long three days, filled with many discussions about system control and management throughout the software stack, and the many interdependencies and special cases that exist on many platforms that Linux supports. Such is the nature of power management. The introductions to new topics and people, as well as the brainstorming about better and more common solutions were top-notch, and bode well for the future of efficiency in Linux.

However, in the meantime, we still have a lot of work to do in the fixing category. Besides the fact that the primary embedded solution (DPM), and it's variants don't exist in a mainstream kernel, there is also this quote to consider about what we're working with today. As Andrew Morton expressed it (via email):

Fortunately, we now have a lot more people familiar with the types of Power Management problems, and many more upcoming events to discuss the progress as we move forward.