ARMv8 power management

0 power management

Many ARM systems are battery powered mobile devices. In such systems, power consumption is a key design constraint. Programmers often spend a lot of time trying to conserve battery life in such systems. There are many hardware design techniques built into the ARM core aimed at reducing power consumption.

Even in systems that don't use batteries, power saving can be an issue. For example, for environmental reasons, you may want to minimize energy use to reduce electricity costs for consumers, or to minimize the heat generated by equipment.

Power usage can be divided into two categories:

Static
Static power consumption (also known as leakage) occurs when core logic or RAM blocks are powered on. In general, the leakage current is directly proportional to the total silicon area, which means that the larger the chip, the higher the leakage current. As you move to smaller manufacturing geometries, leakage contributes a higher percentage of power dissipation.
Dynamic
Dynamic power consumption occurs due to transistor switching and is a function of the core clock speed and the number of transistors changing state per cycle. Obviously, higher clock speeds and more complex cores consume more power.

Power management is aware of the operating system and dynamically changes the power state of the cores, balancing available computing capacity based on the current workload while attempting to use the least amount of power. Some of these techniques turn cores on and off dynamically, or place them in a quiescent state where they no longer perform computations. This means they consume very little power.

1 Idle management

Idle management is usually controlled by the operating system. In this case, operating system power management (OSPM) moves the core to a low-power state when it is idle. Typically, states can be selected, with different entry and exit latencies, and different power consumption levels associated with each state. The state used usually depends on how fast the core is needed again. The power states available at any time may also depend on the activity of other components in the SoC besides the core. Each state is defined by a set of components that are clock-gated or power-gated when the state is entered.

The time it takes to move from a low-power state to a running state (known as wake-up latency) is longer in deeper states. Although idle power management is driven by the behavior of threads on the kernel, OSPM can put the platform into states that affect many other components besides the kernel itself. If the last core in the cluster becomes idle, OSPM can target power states that affect the entire cluster. Likewise, if the last core in the SoC becomes idle, OSPM can target power states that affect the entire SoC. The choice also depends on the use of other components in the system. A typical example is putting memory in a self-refresh state when all cores and any other bus masters are idle.

OSPM must provide the necessary power management software infrastructure to determine the correct state selection. In idle management, when a core or cluster is in a low power state, it can be reactivated at any time via a core wakeup event. That is, events that can wake the core from a low-power state such as an interrupt. OSPM does not require explicit commands to bring a core or cluster back into operation. OSPM considers the affected core or cores to always be available, even if they are currently in a low power state.

1.1 Power Consumption and Clocking

One way energy consumption can be reduced is by turning off the power, which removes both dynamic and quiescent current (sometimes called power gating), or by stopping the clock to the core, which removes only dynamic power, which can be called clock gating.

ARM cores generally support several levels of power management, as follows:

Standby.
Retention.
Power down.
Dormant mode.
hot plug.

For some operations, state needs to be saved and restored before and after power is removed. The time required to perform saves and restores and the power consumed by this extra work are both important factors in the software's selection of appropriate power management activities.

SoC devices containing cores can have other named low-power states, such as STOP and deep sleep. These refer to the ability of the hardware phase-locked loop (PLL) and voltage regulator to be controlled by the power management software.

1.2 Standby

In Standby mode of operation, the core remains powered but most of its clocks are stopped or clock-gated. This means that almost all parts of the core are in a quiescent state, and the only power consumption is due to leakage current and the clocking of a small amount of logic looking for a wake-up condition.

This mode is entered using the WFI (wait for interrupt) or WFE (wait for event) instructions. ARM recommends using the Data Synchronization Barrier (DSB) instruction before WFI or WFE to ensure that pending memory transactions complete before changing state.

If the debug channel is active, it will remain active. The core stops executing until a wakeup event is detected. The wake-up condition depends on the input command. For WFI, an interrupt or an external debug request will wake up the core. For WFE, there are multiple named events, including another core in the cluster executing a SEV instruction.

Requests from the Snoop Control Unit (SCU) can also wake up the clocks for cache coherency operations in the cluster. This means that the cache of the core on standby is coherent with the caches of the other cores (but the core on standby does not necessarily execute the next instruction). A core reset always forces the core out of standby.

Various forms of dynamic clock gating can also be implemented in hardware. For example, SCUs, GICs, timers, instruction pipelines, or NEON blocks can be clock-gated automatically to save power when an idle condition is detected.

Standby mode can be entered and exited quickly (typically in two clock cycles). Therefore, its impact on the latency and responsiveness of the kernel is almost negligible.

For OSPM, the standby state is mostly indistinguishable from the reserved state. This difference is obvious to external debuggers and hardware implementations, but not to the operating system's idle management subsystem.

1.3 Retention

Core state (including debug settings) is preserved in a low-power structure, enabling the core to be at least partially powered off. Changing from low-power hold to run operation does not require a core reset. The saved core state is restored when changing from a low-power holdover state to a running operation. As mentioned earlier, from the operating system's perspective, there is no difference between reserved and standby states other than the method of entry, latency, and usage-related constraints. However, from the point of view of an external debugger, the status is different because external debug requests debug events remain pending and the debug registers in the core power domain cannot be accessed.

1.4 Power down

As the name suggests, in this state, the core will turn off the power (Power down). Software on the device must save all kernel state so that it is preserved when power is lost. Changes from power down to running operation must include:

A reset of the core, after the power level has been restored.
Restoring the saved core state.

The defining characteristic of powered-off states is that they are destructive to the context. This means that all data, operating conditions and operating states will be lost. This affects all components shut down in a given state, including the kernel, as well as shutting down other components of the system in deeper states, such as the GIC or platform-specific IP. Depending on how the debug and trace power domains are organized, one or both of the debug and trace contexts may be lost in certain power down states. Mechanisms must be provided to enable the operating system to perform the relevant context saves and restores for each given state. Resuming execution begins at the reset vector, after which each operating system must restore its context.

1.5 Dormant mode

Dormant mode is an implementation of a power-off state. In Hibernate mode, the core logic is powered down, but the cache RAM remains powered. Typically, RAM is in a low-power reserved state, where they hold their content but are otherwise inactive. This provides a faster restart than a full shutdown, as live data and code remain in cache. Likewise, in a cluster, individual cores can be put into sleep mode.

In clusters that allow individual cores to go into sleep mode, there is no room for consistency when power to the core is removed. Therefore, these cores must first isolate themselves from the coherent domain. They clean up any dirty data before doing so, and usually use another core to wake up external logic to reapply power.

The awakened core must then restore the original core state before rejoining the coherency domain. Since the memory state may change while the core is in sleep mode, you may have to invalidate the cache anyway. Therefore, hibernate mode is more useful in a single core environment than in a cluster. This is because of the additional cost of leaving and rejoining the consistency realm. In a cluster, hibernate mode may often only be used by the last core when other cores are powered off.

1.6 hot plug

Hotplug (Hotplug) is a technology that can dynamically open or close the core. OSPM can use hot plugging to change the available computing capacity based on current computing requirements. For reliability reasons, hot swapping is also sometimes used.

There are several differences between hotplugging and using the power-off state for idle:

When a core is hot unplugged, the supervisory software stops all use of that core in interrupt and thread processing. The core is no longer considered to be available by the calling OS.
The OSPM has to issue an explicit command to bring a core back online, that is, hotplug a core. The appropriate supervisory software only starts scheduling on or enabling interrupts to that core after this command.

Operating systems typically perform most of the kernel boot process on one primary core and bring the secondary core online at a later stage. Assisted boot acts like hotplugging a kernel into the system. The operation in both cases is almost the same.

2 Dynamic voltage and frequency adjustment

Many systems operate under conditions where their workloads vary. Therefore, it is very useful to be able to reduce or increase core performance to match the expected core workload. Clocking the cores more slowly reduces dynamic power consumption.

Dynamic Voltage and Frequency Scaling (DVFS) is an energy saving technology that utilizes:
Linear relationship between power consumption and operating frequency.
Quadratic relationship between power dissipation and operating voltage. This relationship is given as follows:

P = C × V2 × f

P is dynamic power. C is the switched capacitance of the logic circuit in question. V is the operating voltage. f is the service frequency.

Power savings are achieved by adjusting the frequency of the core clock. At lower frequencies, the core can also operate at lower voltages. The advantage of lowering the supply voltage is that it reduces dynamic and static power consumption.

There is an implementation-specific relationship between the operating voltage of a given circuit and the frequency range over which the circuit can safely operate. A given operating frequency and its corresponding operating voltage are expressed as a tuple called the operating performance point (OPP). For a given system, the achievable OPP range is collectively referred to as the system DVFS curve.

The operating system uses DVFS to save power and stay within thermal limits when necessary. The operating system provides DVFS policies to manage power consumption and desired performance. Strategies for high performance choose higher frequencies and use more power. Strategies aimed at saving energy choose lower frequencies, thus resulting in lower performance.

3 Assembly power instructions

ARM assembly language includes instructions that can be used to put the core into a low-power state. The architecture defines these instructions as hints, meaning that the kernel doesn't need to take any specific action when executing them. However, in the Cortex-A processor family, these instructions are implemented in such a way that nearly all parts of the core are clocked off. This means that the power dissipation in the core is reduced, so only static leakage current is consumed and there is no dynamic power dissipation.

Using the WFI instruction will suspend execution until the core is woken up by one of the following:

An IRQ interrupt, even if the PSTATE I-bit is set.
An FIQ interrupt, even if the PSTATE F-bit is set.
An asynchronous abort.
If the core is woken up by an interrupt while the associated PSTATE interrupt flag is disabled, the core will implement the next instruction after WFI.

The WFI command is widely used in battery powered systems. For example, a mobile phone can put the core into standby mode many times per second while waiting for you to press a button.

WFE is similar to WFI. It suspends execution until an event occurs. This can be one of the event conditions listed, or an event signaled by another core in the cluster. Other cores can signal events by executing the SEV instruction. SEV signals events to all cores. A general purpose timer can also be programmed to trigger a periodic event to wake up the core from the WFE.

4 Power state coordination interface

The Power State Coordination Interface (PSCI) provides an OS-independent method for implementing power management use cases where kernels can be turned on or off. This includes:

Core idle management.
Dynamic addition and removal of cores (hotplug), and secondary core boot.
big.LITTLE migration.
System shutdown and reset.

Messages sent using this interface are received by all relevant execution levels. That is, if EL2 and EL3 are implemented, the hypervisor must receive messages sent by the operating system executing in the guest. If the hypervisor sends a message, the message must be received by the secure firmware, which then coordinates with the trusted OS. This allows each operating system to determine whether context saving is required.