kernel-power-management
There
are two types of power management that the operating system must handle:
Device Power Management and,
System Power Management.
Device power management is an alias for the so-called Runtime Power Management. This may allow, among other things, part of the device not currently in use to be turned off in order to conserve
power, such as the keyboard backlight when you are not typing.
System Power Management, also known as Sleep States: This enables platforms to enter a system-wide low-power state.
dynamic power management interfaces:
CPU Idle: Whenever a logical CPU in the system has no task to execute, it may need to be put in a
particular state in order to save power. In this situation, most operating systems simply
schedule a so-called idle thread. While executing this thread, the CPU is said to be idle,
or in an idle state. CPU Idle is a framework that manages idle threads. There are several
levels (or modes or states) of idling. It depends on the built-in power-saving hardware
embedded in the CPU. CPU idle modes are sometimes referred to as C-modes or even
C-states, which is an Advanced Configuration and Power Interface (ACPI) term.
ARM platforms only provide one or two idle states. The choice of the state to enter is based on policies managed by
governors. A governor in this context is a simple module implementing an algorithm enabling
the best C-state choice to be made, depending on some properties.
/sys/devices/system/cpu/cpu0/cpuidle/
C-state /sys/devices/system/cpu/cpuidle/current_governor_ro
hotplug /sys/devices/system/cpu/cpu2/online
CPUFreq: CPUfreq or dynamic voltage and frequency scaling (DVFS) This framework allows dynamic voltage selection and frequency scaling for the CPU,
based on constraints and requirements, user preferences, or other factors. Because this
framework deals with frequency, it unconditionally involves a clock framework. This
framework uses the concept of Operating Performance Points (OPPs), which consists of
representing the performance state of a system with {Frequency,voltage} tuples.
CPUfreq also uses the concept of governors
ondemand, conservative, performance, powersave, schedutil etc
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
Thermal:This framework is dedicated to monitoring the system temperature. It has dedicated
profiles according to temperature thresholds. The thermal framework uses the following concepts:
Thermal zones, Thermal sensors, Cooling devices, Trip points,
/sys/class/thermal/
System power management sleep states
cat /sys/power/states
Suspend to idle (freeze): This is the most basic and lightweight. This state is purely software driven and involves
keeping the CPUs in their deepest idle state as much as possible. To achieve this, the user
space is frozen (all user space tasks are) and all I/O devices are put into low-power states
echo freeze > /sys/power/state
Power-on standby (standby or power-on suspend): In addition to freezing the user space and putting all I/O devices into a low-power state,
another action performed by this state is to power off all non-boot CPUs. resume latency will generally be greater than for the
freeze state,
echo standby > /sys/power/state
Suspend-to-ram (suspend, or mem): this state goes further by powering off all CPUs and putting the memory into self-refresh so that its
contents are not lost, although additional operations may take place depending on the
platform’s capabilities. Response latency is higher than standby, yet still quite low. In this
state, the system and device state is saved and kept in memory. This is the reason why only
the RAM is fully operational
echo mem > /sys/power/state
Powe management is facilitated by the kernel providing the struct dev_pm_ops that each device driver/class/bus interested in power management must fill. This
allows the kernel to communicate with every device in the system
struct dev_pm_ops {
int (*prepare)(struct device *dev);
void (*complete)(struct device *dev);
int (*suspend)(struct device *dev);
int (*resume)(struct device *dev);
int (*freeze)(struct device *dev);
....
}:
-------------------------------------------------------------------
Some good linkes for different power management blog
Linux PSCI framework
https://www.cnblogs.com/LoyenWang/p/11370557.html
Suspend process analysis
https://www.cnblogs.com/LoyenWang/p/11372679.html
cpuidle framework
https://www.cnblogs.com/LoyenWang/p/11379937.html
cpufreq framework
https://www.cnblogs.com/LoyenWang/p/11385811.html
runtime PM capability
system power management capability
S2R
In a DRAM chip, each bit of memory data is stored as the presence or absence of an electric charge on a small capacitor on the chip.[2][3] As time passes, the charges in the memory cells leak away,
so without being refreshed the stored data would eventually be lost. To prevent this, external circuitry periodically reads each cell and rewrites it, restoring the charge on the capacitor to its original level.
Each memory refresh cycle refreshes a succeeding area of memory cells, thus repeatedly refreshing all the cells in a consecutive cycle. This process is typically conducted automatically in the background by the memory circuitry and is transparent to the user.[2]
Comments
Post a Comment