Processor power management can be broadly classified
into two classes.
Processor active – various states a processor can be in
while actively executing and retiring instructions.
Processor frequency scaling, in which a proces-
sor can run at different frequencies and or voltages
falls under this class. So does processor thermal
throttling, where processor runs slower due to duty
cycle throttling.
Linux cpufreq, extensively discussed in [4], [6],
and [5], is a generic infrastructure that handles
CPU frequency scaling.
Processor idle – various states a processor can be in
while it is idle and not retiring any instructions.
The states here differ in amount of power the pro-
cessor consumes while being in that state and also
the latency to enter-exit this low-power idle state.
There may also be other differences like preserv-
ing the processor state across these idle states, etc.
based on a specific processor. For example, a pro-
cessor may only flush L1 cache in one idle state,
but may flush L1 and L2 caches in another idle
state. There can also be differences around when
an idle state can be entered and what its impact
will be on other logical or physical processors in
the system.
System-generic information
This information is under /sys/devices/system/
cpu/cpuidle/.
available_drivers is a read-only interface that
lists all the drivers that have successfully registered
with cpuidle.
current_driver is a read-write interface that con-
tains the current active cpuidle driver. By writ-
ing a new value to this interface, the idle driver can
be changed at run time.
available_governors is a read-only interface
that lists all the governors that have successfully
registered with cpuidle.
current_governor is a read-write interface that
contains the current active cpuidle governor. By
writing a new value to this interface, the idle gov-
ernor can be changed at run-time.
Note there can be single governor and single driver
for all processors in the system.
4.1 New governors
The ladder governor takes a step-wise approach to se-
lecting an idle state. Although this works fine with pe-
riodic tick-based kernels, this step-wise model will not
work very well with tickless kernels. The kernel can go
idle for a long time without a periodic timer tick and it
may not get a chance to step-down the ladder to the deep
idle state whenever it goes idle.
A new idle governor to handle this, called the menu
governor, is being worked on. The menu governor looks
at different parameters like what the expected sleep timeis (as seen by dyntick), latency requirements, previous
C-state residency, max_cstate requirement, and bm
activity, etc., and then picks the deepest possible idle
state straight away. This governor aims at getting max-
imum possible power advantage with little impact on
performance.
cpuidle: use menu gov , 现在是无嘀嗒idle: CONFIG_NO_HZ . 每个cpu有自己的idle loop:
arch\arm\kernl\process.c cpu_idle(idle loop)--> cpuidle_idle_call-->调用平台相
关的idle实现（idle set 0 ,1 ...）,4x12 core0 进入idle set 1时候lpa/aftr一定只能有一个core在线
4x12每个core开始进入idle loop的过程：
init\main.c rest_init --> cpu_idle(cpu0)
arch\arm\kernel\smp.c: secondary_start_kernel --> cpu_idle (cpu 1 2 3 )