Hardware Reference
In-Depth Information
can further assume that there exist several
types
, that are clearly dependent on the
context.
C
= {
c
1
,
c
2
,
...
,
c
M
}
is the set of
M
types (or classes) of resources. A static
mapping from the resources to the corresponding classes exist, and it can be meant
as being (quasi) independent on the target application. Such mapping
M
C
is defined by an ad-hoc function
map
(
r
i
,
c
j
), taking as inputs a generic resource
r
i
⊆
R
×
R
of the resources is available, representing the resources that are not in use by any
other task in the system. Complementary, the set
BR
∈
R
and a generic class
c
j
∈
C
. At any instant of time, only a subset
AR
⊂
AR
c
=
keeps track of the
used (busy) resources. Considering the set
T
of
P
tasks in the
system, there will exist a mapping from the system resources to the tasks:
U
= {
t
1
,
t
2
,
...
,
t
P
}
=
u
uses
r
i
,
c
j
,
C
. The obvious relation
∈
R
×
Tandu
=
with r
i
∈
R
,
c
j
∈
U
operator is the projection operator, returning the
set of resources from a collection of pair-like sets.
The choice
U
of how to map resources to tasks, i.e. the implementation of the
uses
function depends upon a specific objective function. Such objective function
gives priorities to specific resources for requesting tasks, and such priority changes
according to the objective function. Generally, the objective function can be mod-
eled through a set of metrics: performance, memory throughput, execution latency,
power consumption, and so on. Thus, roughly speaking, the role of the Resource
Manager is to fill in the set
U
with the appropriate entries, according to the
current
implementation of the
uses
function. Such implementation can change at run-time,
for instance due to changing workloads or application requirements. Hence, there is a
need for a Run-Time Resource Manager component, that can cope with the changing
application scenario, resources availability and requirements.
⊥
R
=
BR
holds, where the
⊥
6.2.2
Resource Manager Overview
Not every RTRM is suitable for each application/platform configuration. Several
differences are experienced passing from one application to one other, and so the
mapping would change. For this reason, a minimal set of requirements has to be
guaranteed from the RTRM view-point. The following presents a subset of such
requirements;
1.
Flexibility
, RTRM should be able to work with the expected specifications under
different scenarios. Flexibility ensures the reuse of the overall methodology, im-
pacting positively on the design and implementation costs of the entire project.
In addition, flexibility leads multiple applications to efficiently use the resources,
without incurring in unwanted overheads;
2.
Scalability
, RTRM should work well for an increasing number of cores and, in
general, of active resources. This is dictated by the growing and broad convergence
toward multi- and many-core architectures. Scalability is hereby intended from
two view-points: performance (latency, overhead) and energy efficiency (it should
not consume more power than required, otherwise benefits will be outperformed);
Search WWH ::
Custom Search