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

3. System-wideness , decisions made by the manager should not interfere with other
decisions previously taken, i.e. assigning specific resources to a newly incoming
task should not impact negatively on the already running tasks. In order to ensure
this requirement, the RM should have system-wide perspective of what's going
on in the system at any instant of time.
The previous list shows which are the main requirements for a Resource Manager to
be suitable for the job. The effective implementation of the RM depends on several
requirements related to the hardware and software architectures. Before giving an
overview of the main components defining the manager, we define which are the
classes of resource managers that can be found. This is just an adoption of the
work done in [ 16 ]. The various classes of resource management can be identified
according to the following metrics: static versus dynamic, hardware versus software
implementation, centralized versus distributed, adaptive versus static.
Static resource managers are somehow hard-coded in the system software, in
the sense that the decisions taken are defined in advance, according to a predefined
policy. Policies cannot be changed at run-time so no flexibility is achieved in this
case. In contrast, dynamic approaches let the managing process evolve according to
the needs. The policies as well as other useful parameters might be changed during
execution time, either explicitly (i.e., user-driven) or implicitly (i.e., guided by the
current scenario).
The implementation can be either hardware, software or a smart mix of the two.
Purely software approaches are very flexible, but they incur in high overhead; purely
hardware approaches, on the other hand, provide high performance at the cost of
flexibility. A mixed hardware/software co-design can optimize the performance and
the flexibility. The real challenge consists of finding which part will be in hard-
ware and which part will be in software. Examples of purely software or hardware
approaches are reported in [ 16 ].
Centralized approaches provide a single entity that gathers all the necessary in-
formation from the underlying hardware and from the upper software. Distributed
approaches, instead, provide multiple control points, that gather local information.
The former technique lacks of scalability as well as efficiency, since with a huge
amount of resources to handle, the number of information to be gathered would in-
crease exponentially. On the other hand, distributed approaches have only local view
of the problem, and thus do not provide a system-wide optimization point-of-view.
For these reasons, a more suitable approach should have a hierarchical control, i.e.
integrating both local- and system-wide views of the same problem.
Last, decisions should be taken with respect to an adaptive or non-adaptive mech-
anism. Adaptive mechanism can follow the workload changes in the system, and they
are clearly dynamic in nature. In contrast, non-adaptive (also called fixed ) approaches
are of a static nature and do not adapt their behavior to the changing context.
The selection of the implementation details of the aforementioned design param-
eters affects how the manager will behave in the target system. The most interesting
approaches reported in [ 16 ] can thus be classified as shown in Fig. 6.4 .
OMAP platform from Texas Instruments [ 4 ] provides a software and central-
ized/distributed implementation, in which a single master Resource Manager resides