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

workload ready to be executed. A workload can either be CPU-bounded or I/O-
bounded; the former requires intensive CPU computations on memory located data,
while the latter presents a more heavy information exchange toward relatively slow
peripherals such as disks or low-bandwidth buses. In general, a single task cannot
be exclusively classified in a single class; it happens that some portions are more
CPU-intensive, while others are more like I/O operations. This means that the nature
of a task could change during its execution; the combination of different workloads
is even more evident if we consider a multi-tasking system with many concurrent
applications running at the same time and sharing the few available processors.
The CPUfreq framework considers these combined behaviors in order to optimize
power against performance. The basic idea is to exploit the possibility to perform
computations at different operative frequencies. The set of available frequencies de-
fine the performance states of the platform; lower frequencies correspond to lower
voltages and thus also less performing states with reduced power consumption and
increased execution time. Switching from one performance state to an another one
inserts an overhead that must be kept into consideration. Moreover, there is a need
to identify efficiently the real system performance requirements. These observations
make the CPU frequency scaling a rather complex mechanism to exploit. The frame-
work available in Linux simplifies the implementation by a proper software design
which aims at decoupling low-level software mechanisms from high level policies.
An overall view of the software architecture is depicted in Fig. 6.11 .
The low-level software mechanisms [ 11 ] are implemented by drivers , required to
define both platform specific information, and a set of control routines. The required
information is related to the available performance state and the corresponding transi-
tion overheads, while the platform specific hardware mechanism to actually perform

User−level
governors

powersave

conservative

aggressive battery-fair

decide the
target P−State In−kernel

governors

userspace

on−demand conservative

governor interface data structures

initialization and registration
transition handling
policy and transition notifiers

Generic CPUfreq Framework

driver interface

acpi−cpufreq speedstep

CPU−specific
drivers

Processor driver

compile frequency
tables

define supported
policy values

Fig. 6.11 A simple representation of the CPUfreq framework software design