Hardware Reference
In-Depth Information
and resources must be adapted dynamically (e.g. by adjusting the processor clock
frequency, or by switching off some processors) in order to control platform
performance (i.e., the power consumption and the heat dissipation of the platform).
Such a resource management problem is a Multi-Objective Optimization (MOO)
problem (known as Multi-dimension Multiple-choice Knapsack Problem or
MMKP) falling into a complexity category of NP-Hard problems [
11
]. Since
our RRM is intended for embedded platforms, it is implemented as a lightweight
heuristic implementation which consumes during its execution as little platform
resources as possible and does not impact heavily execution time of the running
application.
With respect to discussions in this Chapter, run-time manager consists of only RRM.
Hence we have used term run-time manager and RRM interchangeably.
To alleviate run-time decision making (i.e., to reduce computational complex-
ity at run-time) and to avoid conservative worst-case assumptions, our run-time
management methodology consists of two phases:
First, a design-time Design Space Exploration (DSE) per application derives
a multi-dimensional Pareto set of optimal configurations on a given multi-core
platform. During this phase, optimization and modeling techniques presented in
Chaps. 3 and 4 are adopted.
Second, a low-complexity Run-time Resource Manager (RRM) is incorporated
on top of the basic services of the platform Operating System (OS) and is acting
as an exception handler at run-time to optimize the usage of resources.
In the first phase, at design time, each configuration is characterized by a code
version together with an optimal combination of constraints, used resources, and
costs. The different code versions refer to different parallelizations of the application
into parallel tasks and data transfers to shared and local memories. To enable the
design-time DSE phase, the methodology presented in this Chapter considers only
applications within a set defined at design-time. System-wide approaches, for re-
source management at coarse grain, considering software applications for which the
platform was not directly designed (as the approach proposed in [
4
]), are discussed in
Chap. 6.
In the second phase of run-time management presented in this Chapter, whenever
the environment is changing dynamically (e.g. when a new application or use case
starts, or when the user requirements change), RRM reacts as follows:
It selects a configuration from the Pareto set of each active application, according
to the available resources, in order to minimize the costs, while satisfying the
constraints.
Second, it reconfigures and maps the application on the platform i.e., it assigns
the platform resources, it adapts the platform parameters, it loads the application
tasks, and it issues the application executions according to the newly selected
configurations.
Search WWH ::
Custom Search