This is a study note, original text: https://mp.weixin.qq.com/s/6GFHt6JY1eyz85k6xZtCVA
1. Introduction
In this world, the operation of any system requires energy. Just as trees grow by relying on light energy, horses run by relying on food, and computer systems operate by relying on electrical energy. However, acquiring energy comes at a cost, so if we can minimize energy consumption while ensuring the system operates, it will greatly enhance the system’s competitive survival. Nature has done well in this regard, such as trees shedding leaves and animals hibernating, etc. In the world of computers (taking embedded systems running Linux OS as an example), this is called Power Management.
Simply put, power management is: “Want the horse to run, but don’t want it to eat grass.” However, from the perspective of energy conservation, if you want the horse to run fast and for a long time, you must let it eat a corresponding amount of grass. So we compromise: “Only let the horse eat grass when it needs to run.” This is the core idea of power management. What are the methods? They can be as follows:
Method 1: When the horse does not need to run, kill it, so it won’t eat grass. When the horse needs to run, raise another one.
In the real world, aside from fools, no one should use this method. Because raising a horse again takes time—where would I find the time? It also requires grass—possibly more than what is needed for keeping a horse idle.
Method 2: When the horse does not need to run, let it sleep, cannot open its eyes, cannot move, cannot make noise.
Not to mention whether the horse is willing to sleep all the time, this method can only reduce the amount of grass the horse eats, because its heart is still beating, blood is still circulating, and these also consume energy. However, fortunately, when the horse needs to run, it should not take too long to wait.
Method 3: Isn’t it said that the heart beating and blood circulating also consumes energy? Then let’s stop those too, save as much as we can.
This is indeed a good method, but we should first ask a veterinarian if it can be done. However, with current medical levels, it is probably not achievable.
In the computer world, the above methods are quite common, and the control is much more refined. Because computers are designed by humans, while horses are created by the hand of God. However, through the example of the horse, we can summarize the basic behaviors of power management:
a. Real-time shutdown of temporarily unused parts (can be called “transition from working state to non-working state”). For example, the screen does not need to be on when the phone is in the pocket.
b. When needing to reuse those parts that have been shut down (can be called “transition from non-working state to working state”), there should not be too long a wait, and the transition process should not consume too much energy. The above method 1 is a negative example, but in the computer world, the situation is much better.
2. Components of Linux Power Management
Power Management in the Linux Kernel is a relatively large subsystem, involving power supply, charging, clock, frequency, voltage, sleep/wake, and other aspects (as shown in the figure below), which will be discussed one by one in the Linux power management series of articles.
Note 1: This image is just a schematic diagram and does not delineate software layers, so the relationships between modules may not be the actual relationships.
Before detailing these components (which can also be called Framework), let’s first understand some basic concepts.
Note 2: A Framework is a middleware software that provides a framework for software development. Its purposes are threefold:
First, to shield specific implementation details and fix the interfaces for the upper layers, making it easier for upper-layer software development and maintenance; second, to abstract common logic as much as possible and implement it within the Framework to improve reusability and reduce development workload; third, to provide a series of callback functions to the lower layers, as lower-layer software may face significantly different realities, but as long as these callback functions are filled in, all logic can be completed, reducing development difficulty.
Power Management Framework |
Function Description |
Application Scenario |
Power Supply |
A class for user-space programs to monitor the system’s power supply status (battery power, USB power, AC power, etc.). Simply put, it is a Battery & Charger driver Framework. |
Battery level display, charging status management. |
Clock Framework |
Manages system clock resources, controls clock on/off and frequency adjustments. |
CPU/GPU/peripheral clock management. |
Regulator Framework |
A Framework for Voltage/Current Regulator drivers, adjusting voltage and current (e.g., CPU/GPU power supply), optimizing power consumption. |
Dynamic Voltage Scaling (DVS), low power modes. |
Dynamic Tick/Clock Event |
In traditional Linux Kernel, the system Tick is a fixed period (e.g., 10ms), so every Tick generates a Timer interrupt. This wakes up the CPU in Idle or Sleep state, and often this wake-up is meaningless. Therefore, the new Kernel introduces the concept of Dynamic Tick, where the Tick is no longer periodic but generated irregularly based on the timers in the system, thus reducing many unnecessary Timer interrupts. |
Reducing CPU power consumption in idle state. |
CPU Idle |
Controls CPU idle states (C-states), entering low power modes. |
Reducing CPU power consumption when the system is idle. |
Generic PM |
Traditional power management, such as power off, suspend to RAM, suspend to disk, hibernate. |
System sleep/wake management. |
Runtime PM & Wakelock |
Runtime Power Management, no longer requiring user program intervention, managed uniformly by the Kernel, dynamically shutting down or turning on devices to find the best balance between performance and power saving. Note 3: Runtime PM is the native runtime power management mechanism of the Linux Kernel, while Wakelock is a mechanism proposed by Android. The purposes of these two mechanisms are the same, so only one needs to be supported. Additionally, due to the Wakelock mechanism being too wild, it has been scorned by the Linux community, so we will not describe this mechanism in detail. |
Dynamic device power management (Wi-Fi, sensors, etc.). |
CPU Freq/Device Freq |
Adjusts the operating frequency of the CPU and devices (e.g., GPU) (DVFS). |
Adjusting performance and power consumption based on load (e.g., ondemand, powersave governors). |
OPP (Operating Performance Point) |
Refers to the voltage and frequency combinations that allow SOCs or devices to operate normally. The kernel provides this layer to filter out some relatively fixed combinations from numerous voltage and frequency combinations, making things simpler. |
Dynamic adjustment of CPU/GPU voltage and frequency. |
PM QOS (Quality of Service) |
PM QOS refers to the quality of work of the system under specified operating conditions (different voltage, frequency, switching between different modes, etc.), including latency, timeout, and throughput parameters, with units of us, us, and kb/s respectively. Through QOS parameters, system performance can be analyzed and improved. |
Optimizing the responsiveness of real-time tasks (e.g., audio playback). |
3. Compilation of Source Code Related to Power Management in the Kernel
In the Linux kernel version 3.10.29 used, the source code related to power management is located at:
kernel/power/ *drivers/power/drivers/base/power/*drivers/cpuidle/*drivers/cpufreq/*drivers/devfreq/*include/linux/power_supply.hinclude/linux/cpuidle.hinclude/linux/cpufreq.hinclude/linux/cpu_pm.hinclude/linux/device.hinclude/linux/pm.hinclude/linux/pm_domain.hinclude/linux/pm_runtime.hinclude/linux/pm_wakeup.hinclude/linux/suspend.hDocumentation/power/*.txt