Hardware Reference
In-Depth Information
MOO problem in the Step 3. In particular, for the multimedia scenario proposed
in Chap. 9 the design-time DSE flow is able to solve the optimization problem
simulating less than the 1% of the overall run-time candidate configurations.
5.4.2
The Run-Time Management Methodology
We assume that a series of events change the application deadlines
τ
max
and trigger
the RRM to identify a new
c
α
for every active application
α
. The RRM layer is
invoked as an exception handler within the OS layer and elaborates the following
input information:
Optimal application configurations
C
α
, for each
α
as determined by the design-
time methodology. This information is stored within the OS layer once at the
startup so there is no execution time overhead.
QoS requirements
τ
max
for each
α
. In our case related to multi-media applications,
this is set to average
time-per-frame
.
A priority
ω
(
α
) function which ranks each
α
(low
ω
(
α
) corresponds to low
priority).
We define, for each application
α
, the following input tuple:
C
α
,
τ
max
,
ω
(
α
)
ξ
α
=
(5.7)
The output of the run-time algorithm is a set of working operating points (
γ
) achiev-
ing QoS (
c
α
[
τ
]
τ
max
) while meeting overall constraints: in our case resource
≤
(
α
c
α
[
ρ
]
ρ
max
) and power consumption (
α
c
α
[
π
]). The operating points are
then set by loading an appropriate application binary version (if the number of re-
sources was varied) or modifying the frequency of each core as dictated by the
frequency vector
c
α
[
φ
].
The overall run-time management algorithm is shown in Fig.
5.3
. Mainly the
algorithm starts trying to find a solution which satisfies all run-time QoS constraints
and then, if no solutions have been found, it iteratively relax the QoS constraint of
the lowest priority application until a feasible solution is identified. In particular the
algorithm consists of the following steps:
≤
Fig. 5.3
Priority based
QoS-aware run-time
management
Search WWH ::
Custom Search