Energy Aware Scheduling (EAS) in the Android Kernel: Concepts, Models, and Thread Selection

Energy Aware Scheduling (EAS) is the fundamental feature of the Linux thread scheduler used in Android phones. It enables the scheduler to predict the impact of its decisions on CPU energy consumption. By leveraging the CPU Energy Model (EM), EAS selects the CPU that saves the most energy for each thread while minimizing the effect on system performance.

EAS operates only on heterogeneous CPU topologies (e.g., Arm big.LITTLE), where its energy‑saving potential is greatest.

Note: This analysis is based on the open‑source code of the OPPO Reno9 Pro+ (https://github.com/oppo-source/android_kernel_oppo_sm8475).

Key Concepts

1. Capacity – Capacity is a normalized metric that reflects a CPU’s computational ability. It can be read from the file nodes /sys/devices/system/cpu/cpu*/cpu_capacity . The maximum computational ability of a CPU is calculated as:

capacity = capacity-dmips-mhz * cpuinfo_max_freq / 1000

where capacity-dmips-mhz is the number of dmips a CPU can execute at 1 MHz (obtained from the device‑tree) and cpuinfo_max_freq is the maximum supported frequency in kHz.

For comparison, the strongest CPU in a processor is normalized to a capacity of 1024.

When CPU capacity and frequency have a linear relationship, the capacity at any frequency point is:

(frequency / max_frequency) * max_capacity

2. OPP (Operating Performance Point) – An OPP represents a voltage/frequency tuple that a CPU can operate at. Higher frequencies require higher voltages.

3. Power – After determining the capacity at a given frequency, the power consumption at that frequency can be read from the Energy Model via the file nodes /sys/kernel/debug/energy_model/pd0/*/power (values in mW).

4. Energy‑Efficiency Ratio – The ratio power / capacity indicates energy efficiency; a lower value means better efficiency. Generally, small‑core clusters have better efficiency than big‑core clusters, and big‑core clusters are more efficient than super‑big clusters, though the relationship reverses at certain frequency ranges.

Energy‑Aware Thread CPU Selection

EAS replaces the CFS wake‑up load‑balancing code. It uses the Energy Model together with PELT/WALT statistics to choose the most energy‑efficient CPU for a waking thread.

find_energy_efficient_cpu() – This function searches each performance domain (typically a CPU cluster) for the idle CPU with the highest capacity and then uses the Energy Model to determine which candidate offers the greatest energy saving. Migration occurs only if the selected CPU saves more than 6 % energy compared with the current CPU.

compute_energy() – Estimates the energy consumption of a thread if it were migrated to a destination CPU, taking into account the maximum utilization and total utilization of the performance domain and invoking the Energy Model API em_cpu_energy() .

em_cpu_energy() – API that estimates the total energy consumption of all CPUs in a performance domain. It takes four parameters: the performance domain, the maximum utilization ( max_util ), the sum of utilizations ( sum_util ), and the allowed maximum capacity ( allowed_cpu_cap ). The calculation uses the lowest performance state that satisfies the required frequency and applies the formula ps->cost * sum_util / cpu_capacity , where ps->cost = ps->power * max_freq / ps->frequency .

EAS and Load Balancing

EAS is most effective under light to moderate CPU utilization. When any CPU’s utilization exceeds 80 % of its capacity, the whole root domain is marked “over‑utilized,” EAS is disabled, and traditional load‑balancing is re‑enabled. When utilization stays below this threshold, EAS overrides wake‑up load‑balancing and selects the most energy‑saving CPU without harming performance.

Conclusion

EAS is enabled only when system load is light (all CPUs below 80 % of capacity) and a migration yields at least a 6 % energy saving. Consequently, its impact is limited in heavy‑load scenarios such as gaming, where other power‑optimization techniques may be more appropriate.

References

[1] Documentation/scheduler/sched-energy.rst

[2] Documentation/power/energy-model.rst

[3] Documentation/power/opp.rst