Run-Time Resource Management at the Operating System Level - Multi-objective Design Space Exploration of Multiprocessor SoC Architectures - page 126

/sys/devices/system/cpu/cpuX/cpuidle

User−level
interfaces

/sys/devices/system/cpu/cpuidle

step-wise latency-based

In−kernel
governors

decide the
target C-State

ladder menu

governor interface

data structures
initialization and registration
idle handling
system state change handling

Generic CPUidle Framework

driver interface

acpi−cpuidle halt_idle

CPU−specific
drivers

Processor driver

compile frequency
tables populate supported

C-States

Fig. 6.10 A simple representation of the CPUidle framework

power contribution, exit latency and a target residency time which is considered as
necessary to get an advantage from entering that state. Every idle state could also be
associated to a specific callback function which implements all the required low-level
code needed to actually enter the state.
The high-level interface provides support for the definition of a governor ,a
processor-independent algorithm for choosing the effective idle state to enter, ac-
cording to system constraints on maximum latency. There might be more than one
governors registered in the core, but just one can be used at any time. Widely used im-
plementations provide two governors, called ladder and menu . The ladder governor
adopts a step-wide policy: every time the CPU is idle, a deeper idle state is entered
only if we were previously able to remain in that state for a period greater than its
corresponding target residency. Instead of relying on a simple heuristic approach,
the policy implemented by the menu governor is latency-based. This policy exploits
the information on the maximum allowed system latency in order to identify the
idle state that should be reached every time there is an opportunity. This governor is
certainly more efficient but requires a closer collaboration among applications and
kernel drivers, to collect such requirements.
The core implementation is completely platform independent and provides the
glue code that defines the required data structures, support drivers, governors regis-
tration and run-time selection. A proper monitoring interface is also exported to the
collecting statistics on idle states usage.

CPUFreq

CPUfreq [ 20 ] focuses on the optimization of dynamic power consumption by ex-
ploiting DVFS mechanisms. A processor is in an active state when there is some