Hardware Reference
In-Depth Information
is neither a DVFS algorithm, nor a power-aware OS and even nor a mechanism
such as ACPI. Its relevance comes from the integrated engineering that has been
applied to provide a highly efficient power management solution. To this purpose,
the framework architecture is based on few abstraction objects: operating points,
task states and policies. Each one cooperates information for performance and power
management purposes. An overall representation of these abstractions is depicted in
Figure 6.12 .
An Operating Point (OP) is the lowest level abstraction which encapsulates a
mixture of physical and logical parameters, representing a power-related sensible
characterization. Each OP is thus a specific set of
pairs corre-
sponding to a precise system power/performance configuration. At any given instant
of time, the system is allowed to execute in a specific OP. Examples of operating
points for a processor [ 17 ], as specified for the PowerPC architecture, are: core volt-
age, CPU operating frequency, bus frequency, and memory timing. The designer is
in charge of the choice and setting of the OPs, as many as required by the capabilities
of the target platform and the desired complexity of the framework implementation.
The framework allows also the definition of congruence classes (CCs) which are sets
of OPs that could be considered to be equivalent from certain power/performance
optimization strategy. A task state (TS) is the high-level abstraction corresponding to
a possible system operating state. In the control model defined by DPM, the system
is seen as a state machine defined on a limited and well defined set of states. Example
of states could be: idle, interrupt handling, CPU-bound process, I/O-bound process.
The definition of the actual set of TS is once again in charge of the integration en-
gineer. At run-time, each task could be associated with a task state. This mapping
allows to identify in which task state the system is by simply looking at what task
is scheduled to run at every time instant. Thus, switching from one task to another
could imply the switching of the system among different task states.
Since each task state might have its own power/performance profiles, it is worth
defining a mechanism to map task states to operating points, or more in general to a
congruence class. This is achieved through the introduction of the policy abstraction,
representing such mapping. According to the time of running task, the DPM core
parameter , value
Operating Points
Power
Considerations
OP
OP
Congruence
Class
OP
OP
Operating
CC
State
Policy
OP
OS
OP
OP
OP
OP
Device
Constraints
Power Management
Strategy
Fig. 6.12 The DPM architecture abstraction objects
Search WWH ::




Custom Search