Hardware Reference
In-Depth Information
CONCLUDING REMARKS
The elastic model offers a flexible way to handle overload conditions. In fact, when-
ever a new task cannot be guaranteed by the system, instead of rejecting the task, the
system can try to reduce the utilizations of the other tasks (by increasing their periods
in a controlled fashion) to decrease the total load and accommodate the new request.
As soon as a transient overload condition is over (because a task terminates or vol-
untarily increases its period) all the compressed tasks may expand up to their original
utilization, eventually recovering their nominal periods.
The major advantage of the elastic method is that the policy for selecting a solution is
implicitly encoded in the elastic coefficients provided by the user (e.g., based on task
importance). Each task is varied based on its elastic status and a feasible configuration
is found, if one exists. This is very useful for supporting both multimedia systems and
control applications, in which the execution rates of some computational activities
have to be dynamically tuned as a function of the current system state. Furthermore,
the elastic mechanism can easily be implemented on top of classical real-time kernels,
and can be used under fixed or dynamic priority scheduling algorithms.
It is worth observing that the elastic approach is not limited to task scheduling. Rather,
it represents a general resource allocation methodology that can be applied whenever
a resource has to be allocated to objects whose constraints allow a certain degree of
flexibility. For example, in a distributed system, dynamic changes in node transmis-
sion rates over the network could be efficiently handled by assigning each channel
an elastic bandwidth, which could be tuned based on the actual network traffic. An
application of the elastic model to the network has been proposed by Pedreiras et al.
[PGBA02].
Another interesting application of the elastic approach is to automatically adapt task
rates to the current load, without specifying worst-case execution times. If the system
is able to monitor the actual execution time of each job, such data can be used to
compute the actual processor utilization. If this is less than one, task rates can be
increased according to elastic coefficients to fully utilize the processor. On the other
hand, if the actual processor utilization is a little greater than one and some deadline
misses are detected, task rates can be reduced to bring the processor utilization to a
desired safe value.
The elastic model has also been extended to deal with resource constraints [BLCA02],
thus allowing tasks to interact through shared memory buffers. In order to estimate
maximum blocking times due to mutual exclusion and analyze task schedulability,
critical sections are assumed to be accessed through the Stack Resource Policy [Bak91].
Search WWH ::
Custom Search