Overload handling methods Local Local Global Global Are - PDF document

Overload handling methods Local Local Global Global Are implemented as an Are implemented as an Are part of the system Are part of the system adaptive behavior of adaptive behavior of and can act on the task and can act on the task application tasks. application tasks. set and on the kernel. set and on the kernel. Reactive Reactive Proactive Proactive Let the overload to Let the overload to Prevent the overload to Prevent the overload to occur and react to occur and react to occur by reducing the occur by reducing the contain its effects. contain its effects. computational request. computational request. Local Policies Global Policies They are implemented inside specific application tasks as an They are implemented as a component (Overload Manager) adaptive behavior to reduce their computational demand: that can operate both on the kernel and on the entire task set: Real-Time System adaptive Task Task task mechanisms probes Real-Time System Controlled actual exec. times e i Set Set  i response times R i Plant mechanisms probes deadline misses sensors sensors e i R i dmiss i … Load Load task set state variables Policy Policy  (t) estimator estimator parameters Overload Manager Example of reactive approach Reactive methods If  * is a critical task that has to finish by a deadline d, They let the overload to occur, detect it and react with a proper They let the overload to occur, detect it and react with a proper action aimed at containing its effects. action aimed at containing its effects. a timer can be set at its activation to interrupt after d. They must handle three phases: If the task finishes before d, the timer is canceled, otherwise an exception is raised: 1. Overload detection: this is done by proper kernel probes and timers for catching deadline misses, execution overruns, etc. 2. Exception notification: this is done by generating an interrupt for the kernel and a message for the user.  * 3. Exception handling: depending on the criticality of the exception, possible actions are: timer  system reset canceled exception handler  abortion of the running task  rejection of least important tasks In the worst case, the exception handler can reset the system.  performance degradation  no action: just notification 1

Proactive methods Existing proactive approaches Depending on the type of performed action, the following They prevent the overload to occur by proper admission tests They prevent the overload to occur by proper admission tests proactive approaches can be distinguished: and by reducing the computational demand of the application. and by reducing the computational demand of the application.  Admission control methods The computational demand can be reduced by: The load is reduced by rejecting one or more tasks.  rejecting tasks  Performance degradation methods  reducing computation The load is reduced by degrading the system performance  reducing priority (under fixed priority systems) acting on the task set parameters (computation times, periods, or skipping specific jobs).  postponing the deadline (under deadline-based systems)  skipping specific jobs  Resource Reservation methods The load of each task is contained by a proper isolation  reducing the activation rate of periodic tasks mechanism that delays only those tasks experiencing the overrun, without affecting the other tasks. Simple admission control Admission by feedback The load is estimated at every task activation based on worst- The load is estimated at every task activation based on actual case task set parameters: if   1, the task is accepted, execution behavior detected by kernel probes [Stankovic, '99]: otherwise it is rejected: e i R i dmiss i … probes  i Task Task Real-Time Real-Time  i Task Task Real-Time Real-Time Load Load NO Load Load NO  > 1  > 1 estimator estimator Set Set System System estimator estimator Set Set System System reject  i reject  i YES YES Pros : Pros : Simplicity (like the telephone system). Simplicity (like the telephone system). Pros : Pros : It increases system efficiency, accepting more tasks. It increases system efficiency, accepting more tasks. Accepted tasks are guaranteed to receive full service. Accepted tasks are guaranteed to receive full service. Cons : Load estimation is pessimistic (using WCETs and MITs) Cons : Load estimation is pessimistic (using WCETs and MITs) Cons : Tasks can experience deadline misses (not good for Cons : Tasks can experience deadline misses (not good for so tasks could be unnecessarily rejected. so tasks could be unnecessarily rejected. safety-critical systems). safety-critical systems). Task importance is not taken into account. Task importance is not taken into account. Task importance is not taken into account. Task importance is not taken into account. Taking value into account Highest Value First A possible scheduling algorithm could schedule tasks How to take task importance into account? based on their importance value (Highest Value First):  Under RM and EDF , the value of a task is implicitly encoded in its period or its deadline.  i READY queue READY queue CPU  However, in a chemical plant controller, a task reading ordered by value the steam temperature every 10 seconds is more important than a graphic task that updates the clock  This policy guarantees that high importance tasks are icon every second. always executed. Then, should we schedule tasks based on Then, should we schedule tasks based on  However, system efficiency could be quite low. their importance value? their importance value? 2

Considering only value is not good Only deadline is not good either Guaranteeing the execution of high importance tasks is a In overload conditions, EDF is not optimal: good thing in a RT system, but considering only importance is not efficient: Schedule produced by EDF Scheduler: Highest Value First high value high value low value low value A better schedule achieving more value Scheduler: Earliest Deadline First high value high value low value low value How to use value? Robust EDF scheduling The load is estimated at every task activation: if   1, the task  If   1, EDF is optimal (value is not needed). is accepted, otherwise the overload manager is invoked.  If  > 1, all tasks cannot finish within their deadline. probes Task Task  To avoid domino effects, the load has to be reduced,  i Load Load NO  > 1 Real-Time System estimator estimator Set Set hence some task has to be rejected. READY queue READY queue YES  We would like to reject the least important tasks. Recovery Recovery Reject Reject Policy Policy Policy Policy To manage overload conditions, the system must be To manage overload conditions, the system must be able to handle tasks with both timing constraints and able to handle tasks with both timing constraints and Separated policies importance value. importance value.  Tasks are scheduled by deadline and rejected by value.  Under early completions, rejected tasks can be recovered. Example: task rejection Example: task rejection V i V i  1  1 7 7  2  2 10 10  3  3 5 5  4  4 2 2  5  5 3 3 0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20 At time t = 4 , the arrival of  1 generates an overload.  3 is the least value task that, if rejected,  3 is the least value task that, if rejected, can resolve the overload. can resolve the overload. Which task should be rejected? 3

Example: task rejection Example: task recovery  = {  1 ,  2 ,  3 } V i V i  rej =  3  1  1  1 7 7  2  2  2 10 10 d * = 13  3  3 5 5  4  4 2 2  5  5 L max = 3 3 3 0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20 Rejection policy: if d * is the first deadline miss after t , reject at time t = 8, 3 units are saved   3 can be recovered  = {  i | ( d i  d * ) AND ( c i (t)  L max )} the least value task in Performance evaluation Value as a function of time In a real-time system, the value of a task depends How can we evaluate the performance of different How can we evaluate the performance of different on its completion time and criticality: scheduling algorithm in overload conditions? scheduling algorithm in overload conditions? Every time a task is completed, the system v i (f i ) v i (f i ) accumulates a score, which depends on hard soft  the task value f i f i r i d i -  r i d i  the time at which the task is finished. v i (f i ) v i (f i ) A value v i can be target v i = V i arbitrary constant sensitive assigned according firm v i = C i computation time to different criteria: f i f i r i d i r i d i v i = V i / C i value density Performance evaluation Optimality under overloads The performance of a scheduling algorithm A on a The maximum value that can be accumulated is: task set T can be evaluated by computing the   A  * Cumulative Value : ( T ) max ( T ) A n    v f Hence, the performance of an algorithm can be ( T ) ( ) A i i evaluated with respect to  * .  i 1  Note that, in overload conditions: In overload conditions, there are no optimal In overload conditions, there are no optimal n on-line on-line algorithms algorithms able able to to guarantee guarantee a a      V ( T ) ( T ) cumulative value equal to  * . cumulative value equal to  * . A i max  i 1 4