The Synergy in OSPM

In the previous article in this series, we examined how a modern interface was designed to enable new leaps in the software regulation of hardware. We looked at the history leading to the conception of ACPI, and its overarching design principles and components, including the central concept of states hardware could be in. This article will go a little farther into the components of this architecture and introduce an interesting trade-off between performance and power.

The Power Manager

Recall Fig. 2 from the first article, which is reproduced here for your convenience:

This graphic aims to relate the key components in an ACPI-compliant system, showing what they are and how they link together. While it is not in the scope of this series to discuss in depth the specific implementation details of each of these blocks, it is of relevance to examine the functional block marked "Power Management". What does it do?

The operating system's power manager (or governor, depending on the OS) has numerous responsibilities. Amongst them, it:

1. Communicates with the ACPI driver to effect transitions between different ACPI states
2. Remains aware of the capabilities in terms of power management of available execution units (cores)
3. Communicates status and information to other parts of the OS kernel…
4. …and assists in applying the currently active power policy.

Examples of power managers are found in all modern operating systems. In Linux, different governors are available, with the recommended ondemand governor dynamically scaling CPU frequency in response to load.

In Windows, the kernel power manager handles platform power consumption through power schemes, which are applied dynamically dependent on the current task. For example, launching applications might require a low latency scheme, media playback could allow a low power scheme, and on mobile PCs such as phones and tablets, when the battery is nearing depletion, an aggressive low power scheme might be required to conserve battery life.

In light of these facts then, perhaps a somewhat obvious implementation for a power manager comes to mind — namely, if one wished to optimise power consumption, simply set the processor to the maximum performance state when busy, and the minimum when idle.

Alas, as always, it is not that simple. What would be the challenges that such a design might face?

Caveat emptor

Again, recall the abridged list of states presented in the previous article, reproduced here for your convenience:

Processor states

1. C0: normal operation
2. C1: halted, can resume execution immediately
3. C2: clock stopped, can resume quickly
4. C3: sleeping, takes longer to resume

Performance states

1. P0: maximum performance
2. P1: reduced clocks and voltages
3. P2: reduced clocks and voltages
4. Pn: reduced clocks and voltages

For the sake of the following illustration, we refer to another class of states defined in the ACPI specification, the Global States. The essence of global states is that they represent the externally visible behaviour of the platform — that is, what the user sees.

The states are defined from G0 to G3, where the former is the normal working state, and the latter is a full shutdown with power disconnected. States G1, sleeping, is further subdivided into various sleep states. Once again, deeper, higher numbered states represent greater power savings, but in the case of global states, even more so than processor or performance states, which themselves offer in comparison more fine-grained but more incremental changes.

With this information, it is now possible to answer the question posed at the end of the last section. Why is it not a good design for a power manager to, in general, place the system completely into sleep, or even, into shutdown, during all idle periods? Although perhaps no power would be consumed if the system transitioned into G3, the key is that the power consumed by the hardware in effecting the transition itself, both to and from a state, as well as the time latency associated with such a change, may turn out to be prohibitively expensive if not managed well!

Herein lies the rub — it is not sufficient for a naive power manager to blindly transition to low power states whenever the system is not being used because the time which the system remains idle is neither constant nor trivial to predict. In fact, an inefficient algorithm may impact power usage more than one which leaves the system at full speed all the time, not least because the user may become frustrated with delays and latencies, and switch power management off entirely.

The best algorithms will consider and influence many factors to avoid spurious transitioning, and one of them is to intelligently manage the cause of power consumption on the processor in the first place — execution. Next up in this series: threads, and their scheduling thereof. Don’t miss it!