Overload Scheduling in Real-Time Systems

1
Overload Scheduling in Real-Time Systems
Dr. Pedro Mejía Alvarez Sección de
Computación. CINVESTAV-IPN, México
2
Outline

• Motivation
• Related Work
• Methodology
• The INCA Server Algorithm
• The Approximate Algorithm
• Analysis of the INCA Server
• Simulation Results

3
Motivation

• Many systems are provisioned incorrectly
• Correctly provisioned systems have
• Changes in the environment,
• Many arrivals of asynchronous events or
• Faults of peripheral devices.
• Overloads occur when safety is at stake ? need
  efficient algorithm

4
Related Work

• Best effort scheduling algorithm (Locke and
  Jensen)
• The RED (Robust Earliest Deadline) algorithm
  (Buttazzo)
• Imprecise Computations
• Skip Model
• The (m,k) Model
• The Elastic Task Model
• The Incremental Server Model.

5
Best effort scheduling algorithm

• Rejection policy for overloaded systems based on
  removing tasks with the minimum value density
  (introduced time valued functions).

U
U
U
(b)
(c)
(a)
t
d
t
d
t
d
6
The RED (Robust Earliest Deadline) algorithm

• aperiodic tasks in overloaded systems. Combines
  criticality-based scheduling and deadline
  tolerance. Remove the task with least value on
  overload.

task
Scheduling policy
Planning
Ready queue
RUN
Reclaiming policy
Rejection policy
Reject queue
7
Imprecise Computation Model

• Each Task is composed by a mandatory and an
  optional part.
• Mi mandatory part of task ?i
• Oi optional part of task ?i
• Mi precceds in execution to a Oi
• Oi could not execute or it may execute partially
• The deadline of Mi must be guaranteed.
• The deadline of Oi could be missed if necesarry.
• Execution of Oi refines the result obtained by Mi
• The goal in the scheduling of imprecise tasks is
  to execute the most possible number of optional
  parts such that
• No deadline of mandatory parts is missed
• The error is minimized. Error is greater when
  more optional parts are not executed

8
Example of Execution of Imprecise Tasks
Task 3 misses the deadline of If optional part on
its first Job At time t 50
0 20 40 60
80 100 120 140
160
9
The Skip Model

• Some Jobs can be skipped, ocassionally
• On-line guarantee
• A job is either executed within its deadline or
  it is rejected.
• Each Task is characterized by (Ci,Ti,Di,Si)
• Si is the minimum number of Jobs that must be
  executed
• between two consecutive skips

10
The Skip Model (Example)
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16
C1 1, T1 3 C2 2, T2 4, Si 2
11
The Elastic Tasks Model

• The idea is to control the processor load by
  tuning the task periods
• Task utilization are variable with given elastic
  coefficients
• A periodic task is characterized by (Cu, Ti0,
  Timin, Timax, Ei)
• The actual period Ti ? Timin,Timax

Ei
Ri Timin Ti0
Timax
12
Problems with Related Work

• Criteria for rejection discard the
  lesser-valued tasks.
• The time valued functions
• difficult to obtain
• performance may be degraded if the system
  designers are not familiar with these functions.
• How far from optimal is the performance of the
  algorithms?
• Discarding less critical tasks during overload
  requires
• exploration of a large search space (combination
  of tasks) to discard ? solution not practical.

13
Incremental Server for Scheduling Overloads

• Goal Selecting Optional Parts to schedule in
  real-time systems under overloads.
• Problem Selection while maximizing system value
  requires the exploration of a large number of
  combinations.
• Approach Adjust the system workload by
  executing a sequence of approximate algorithms in
  incremental steps.
• At every phase, load is adjusted and solution is
  refined.
• Property The most critical tasks in the systems
  are always scheduled and the total value is
  maximized.

14
OVERLOADED SYSTEM
M1
M3
O1
O2
M2
O4
M4
O3
M5
O5
M6
O6
Optional Parts
Mandatory Parts
15
OVERLOADED SYSTEM
M1
M3
O1
O2
M2
O4
M4
O3
M5
O5
M6
O6

• Optimal Solution
• High Complexity

Mandatory Parts
Optional Parts
16
OVERLOADED SYSTEM
M1
M3
M2
M4
M5
M6

• Low Cost
• Poor Solution

Mandatory Parts
Optional Parts
17
INCREMENTAL EXECUTION OF A SEQUENCE OF
APPROXIMATE ALGORITHMS
Solutions
O1
O2
O1
O6
O3
O4
O2
O4
...AP(0)....................AP(1)
.............. ..........AP(k)

• Solution is Refined
• Complexity Increases

18
INCREMENTAL EXECUTION OF A SEQUENCE OF
APPROXIMATE ALGORITHMS
Overload
1
Slack
U
0
Time
AP(0)...............AP(1).....................
..................AP(k)

• AP(1) runs on the Slack Time recovered by AP(0)

19
Task Model

• Imprecise periodic tasks 0/1 constraints
• The arrival of each task is aperiodic (ri
  instances per task).
• Overload is caused by optional parts.
• Overloads only due to new task arrivals (comp
  times are fixed)
• Optional parts may be discarded under overloaded
  conditions.
• Each task has an associated criticality value vi.
• Earliest Deadline First (EDF) dispatching.

20
Methodology Proposed

1. Define the search space and the objective
   functions,
2. Define the conditions for the feasibility of a
   solution,
3. Find a feasible element within the search space
   that satisfies an optimality criteria.
4. Execute the Approximate Algorithms in an
   incremental fashion, during system idle times.

21
Search Space
Set
Search Space
S4 1,1,1,1 S3 1,1,1,0 1,1,0,1
1,0,1,1 0,1,1,1 S2 1,1,0,0 1,0,1,0
1,0,0,1 0,1,1,0 0,1,0,1 0,0,1,1
S1 1,0,0,0 0,1,0,0
0,0,1,0 0,0,0,1 S0 0,0,0,0

• Each element in S denotes either a Feasible or
  Non-Feasible Solution
• Xi 1, optional part i is chosen for execution.

22
Objective Functions and Feasibility test

• Objective Functions
• Utilization ?(s) ? mi/Ti ? xj
  (pj/Tj)
• Criticality Value ?(s) ? xi
  (vi/Ti)
• Feasibility Test (utilization based)
• true if ?(s) lt 1
• UBT(s)
• false otherwise

23
The Optimization Problems
Maximize Utilization Maximize
the Value maximize ?(s)
maximize ?(s) Subject to UBT(s)
Subject to UBT(s)
24
Formulation for Maximizing Utilization

• Problem If an arriving task ?I causes an
  overload
• Decide whether to accept the new task.
• Determine the time for the scheduling of the new
  task.
• Determine the optional parts to shed.
• Maximize the usage of the resources at a low
  cost.

25
Incremental Scheduling Server

• Adjust the workload in response to transient
  overload requests.
• Executes a sequence of Approximate Algorithms
• AP(0), ..., AP(n) during idle time.
• At each level k, AP(k) determines which optional
  parts to shed to satisfy optimality criteria
• AP(k) obtains a solution closer to optimal than
  AP(k-1) but with longer execution time.

26
Incremental Scheduling Server

• Metodology for Handling Overload
• Activating the Incremental Server
• Execution of AP(0) Overload Removal
• Scheduling the New Task.
• Execution of AP(1),..., AP(n)
• Stopping the execution of the Server

27
Incremental Scheduling Server

• Triggers for activating the INCA Server
• A new task arrives and causes an overload UBT
  Test
• A task leaves the system.
• While waiting for new tasks, the INCA server do
  not cause overhead in the system.

28
Incremental Scheduling Server

• Execution of AP(0) yields Overload Removal
• shed the less critical optional parts
• AP(0) is a greedy algorithm O(n) ? finds a
  sub-optimal solution.
• If overload persists after AP(0) ? the new task
  is rejected.
• Optional Tasks are temporarily suspended, not
  discarded.

29
Incremental Scheduling Server

• Scheduling the New Task occurs only at the end of
  the longest period of all preempted tasks.
• The resulting utilization can not be immediately
  subtracted.

30
Incremental Scheduling Server

• Incremental Execution of AP(1), ..., AP(n)
• AP(1) runs on the slack time recovered by AP(0).
• Similarly, slack from AP(1) is used to run
  AP(2), ... And so on...
• INCA server will execute as many AP(k)s as
  possible
• AP(i) solution better than AP(i-1)
• AP(i) runtime longer than AP(i-1)
• Results from AP(i) may increase the utilization,
  reducing the amount of available slack.

31
Incremental Scheduling Server

• Triggers for stopping the execution of the INCA
  Server
• There is no slack in the schedule to execute
  AP(k) ? stop server
• AP(k) gives a solution no better than AP(k-1) ?
  stop server
• After AP(n) is executed ? stop server
• Another task arrives in the system ? stop and
  re-start server
• A Task leaves the system ? stop and re-start
  server

32
Incremental Scheduling Server

INCA Server input Set of tasks, including the
newly arrived task 1 Execute AP(0) 2 if
the system is still overloaded then exit 3
Compute the start time of the new task 4
Schedule the new task at its start time 5
k1 6 while (there is slack in the
schedule) do 7 Execute AP(k) (during
slack time) 8 if the result
(utilization) from AP(k) is better than
AP(k-1) 9 then Adjust the workload
(remove optional parts) 10 else exit
11 k k 1 12 end

33
Each Approximate Algorithm

• Greedy algorithm to select optional parts for
  execution.
• AP(k) considers all possible (feasible) subsets
  in the search space with al least k optional
  parts.
• Characteristics
• The time complexity of AP(k) is O(nk1)
• The worst-case performance ratio is k/(k1)
• For a small value of k, AP(k) give a solution
  close to optimal.

34
Performance of the Approximate Algorithm
Number of Solutions within x percent near
optimal

• 1000 Simulations
• 10 tasks
• U 120

35
Analysis of the INCA Server

• Results.
• Using INCA gives better results than using
  NON-INCA, when the objective is to maximize ?(s)
  (utilization).

36
Simulation Experiments setup

• Measure the quality of results over a set of
  dynamic tasks.
• Measure and compare the performance among several
  stages of our different optimality criteria
• 100 independent simulations (first 5 stages of
  AP(k))
• 5,000 tasks (life time of each task 400-600
  instances)

37
Performance Evaluation Metrics
Utilization Ratio CU(I)

Total Utilization
Criticality Ratio CV(I)

Total Criticality
CU(I) ?i ri pi ri number of
instances of task i
CV(I) ?i ri vi
38
Simulation Results
Utilization Ratio for up to 5 stages
39
Simulation Results
Criticality Ratio for up to 5 stages
40
Conclusion on the INCA Server

• Only few stages of the INCA server are necessary
  for achieving near-optimal results.
• INCA Algorithm is easy to implement.
• Performance metrics (utilization and criticality)
  are easy to obtain for system designers.