Contract-based%20scheduling

1
Contract-based scheduling

• Giuseppe Lipari

2
Summary

• Overview of classical scheduling theory
• Limitations of classical scheduling
• Contract based scheduling
• Techniques
• Resource Reservations and periodic servers
• Bandwidth Inheritance
• Applications
• Hard and soft real-time tasks
• Supporting imprecise computation model with
  contracts
• Hierarchical scheduling
• Component based systems
• Adaptive Systems
• Feedback control

3
Classical Scheduling Theory
4
Classical Scheduling Theory

• In this presentation we address scheduling in
  mono-processor systems
• The methodologies we describe are more general,
  and can be applied to other resources
• Scheduling algorithm
• An on-line algorithm that selects which task is
  to be executed at each instant of time
• Problem
• given a set of real-time tasks and a scheduling
  algorithm, check a-priori if all timing
  constrains will be respected

5
Classical Task Model

• Real-Time system set of concurrent real-time
  tasks
• Task sequence of jobs (or instances)

• Periodic or sporadic task
• T is the period (or minimum inter-arrival time)

6
Scheduling analysis
OFF- LINE
Task model (timing)
Scheduling Analysis
Schedule Properties
Design model
Implementation
Scheduler
Schedule
RUN-TIME
7
Scheduling Algorithms

• Table driven
• Schedule is entirely computed off-line and stored
  in a table
• Maximum degree of predictability, but too rigid
• E.g. Time Triggered Architecture
• Fixed Priority
• Each task is assigned a priority
• Predictable but also flexible
• The most popular (all RTOS implement FP)
• Earliest Deadline First
• Each job has a priority inversely proportional to
  its deadline
• Flexible and optimal
• But not implemented in practice

8
Hard real-time systems

• Safety critical hard real-time applications
• Severe consequences if some timing constraint is
  violated
• Most important objective is to meet all timing
  constraints
• Cost is a secondary issue
• Fault-tolerance is a major issue
• Design for Worst-Case
• Overestimation of resources
• Examples
• Avionic and space systems
• Nuclear plants
• Etc.

9
Modern real-time applications

• A new class of real-time applications
• Cost is an important factor
• Overestimation of resources can unnecessarily
  increase the cost
• Strong push toward adaptive and robust
  techniques
• E.g. automotive
• Soft real-time systems
• Cost is a major factor
• Optimization of resources is very important
• Some timing constraint can be missed
• Emphasis on Quality of Service control
• Design for average case
• E.g. Consumer Electronics, Multimedia systems,
  etc.

10
Limitations of classical scheduling
Task model (timing)
Scheduling Analysis
Schedule Properties
Design model
Implementation
Scheduler
Schedule

• An accurate timing analysis requires
• An accurate model of the Hardware platform
• An accurate model of the software
  (inputs/outputs/frequencies of events)
• Long and expensive
• WCET can be much higher than average
• Design for worst-case ? waste of resources ?
  increases the cost

11
Limitations of FP and EDF

• There is no temporal protection
• Suppose that we underestimate the WCET of a task
• The analysis will not report any problem
• At run-time one or more tasks can miss their
  deadlines
• Not all code is always under our control
• In large projects, it is common to include code
  from third-parties
• A non critical task written by someone else could
  compromise the schedulability analysis

12
Temporal fault
task1
task2
Executing more than expected...
task2 fails!!
13
Example with EDF

• Three tasks scheduled by EDF
• C11, T14
• C2?, T26
• C32, T38

task1
task2
task3
Its executing too much... (5 instead of 3)
Deadline miss!
14
Design for average case

• Consider a soft real-time application
• Worst case gtgt Average case
• Allow deadline miss but
• keep them under control!
• If we use classical scheduling algorithms (FP or
  EDF)
• Design for worst-case ? waste of resources
• Design for average-case ? difficult to give
  guarantees
• Probabilistic schedulability analysis
• The model is too complex (requires probabilistic
  characterization of all tasks)
• The behavior of one task depends on the behavior
  of every other task
• No easy knob to control QoS of tasks

15
Limitations of Fixed Priority

• Fixed Priority Scheduling
• Each task is assigned a priority
• The highest priority active task executes
• Rate Monotonic assignment is optimal for
  schedulability and resource utilization
• How to assign priorities?
• What is the relation between priority and
  importance / criticality?
• More important / critical task should have higher
  priority
• The most important tasks are not necessarily the
  ones with the shorter periods
• Lower priority tasks could be delayed by higher
  priority ones

16
Fixed priority and Components

• Example
• Consider two components developed independently.
  Each one consists of two tasks, for a total of 4
  tasks. The scheduler is FP (Fixed Priority).
• Problem
• Priorities are relative
• The designer of one component can only assing
  local priorities
• It is not clear how to transform local priorities
  into global priorities at integration phase
• No temporal isolation
• A failing task of one component can delay the
  execution of other components

17
Problems with a single scheduler
prio(Task1) gt prio(Task2)
prio(Task3) gt prio(Task4)
Possible priority ordering
1. prio(Task1) gt prio(Task2) gt prio(Task3) gt
prio(Task4)
2. prio(Task1) gt prio(Task3) gt prio(Task2) gt
prio(Task4)
3. prio(Task3) gt prio(Task1) gt prio(Task2) gt
prio(Task4)
4. prio(Task3) gt prio(Task4) gt prio(Task1) gt
prio(Task2)
5. prio(Task1) gt prio(Task3) gt prio(Task4) gt
prio(Task2)
6. prio(Task3) gt prio(Task1) gt prio(Task4) gt
prio(Task2)
18
Schedulability Analysis

• Scheduling analysis can only be performed when
• We already have all tasks with their code
• We have performed WCET analysis
• It is the final step!
• Most of the times it comes too late
• If the system is not schedulable, it is not easy
  to understand how to change the system
• Scheduling analysis is not composable
• Cannot be done separately on smaller subsystems
• Requires too much effort and time
• Only useful for safety critical systems

19
Summary why RT analysis?

• What we ask real-time embedded system
  developers
• develop correct concurrent and distributed
  software
• measure WCETs
• make a real-time analysis
• short time-to-market cheap
• What do we give them
• low level OS primitives
• no integrated methodology for measuring WCETs
• analysis tools not integrated in the process
• Real-time theory regarded as solution to the
  wrong problem

20
What we propose

• High-level real-time services
• with built-in analysis
• platform-independent
• high-level quality of service management
• Temporal encapsulation of subsystems
• Support the composability of independently
  developed components
• full view of resource protection (processors,
  networks, busses, memory, power, ...)
• Designed for component-based design methodologies
• as an enabling technology

21
Contract Based Scheduling
22
Objectives

• A scheduling algorithm
• Temporal protection
• On-line admission control
• Appropriate OS primitives
• Platform-independent
• standard
• That allow QoS management and control
• A scheduling analysis
• Composable

23
FIRST and FRESCOR projects

• The FIRST project
• 5th framework EU project, concluded in 2004
• A platform independent API for contract-based
  scheduling
• Implemented in two OS MARTE and Shark
• Implementation and documentation available at
  http//shark.sssup.it
• The FRESCOR project
• 6th framework EU project, started July 2006
• Extend API to multiple resources,
  multiprocessors, Quality of service management
• Implementation will be performed on Linux and
  RT-Linux

24
Contracts

• The contract model
• The application specifies its resource
  requirements in a contract
• The system performs an admission control test
• If the contract is accepted, the application is
  admitted and reserved a certain amount of
  resources
• The contract can only be broken by the
  application itself
• Application
• A single task
• A set of tasks plus a local scheduler (for
  hierarchical scheduling)

25
Real-Time Contracts
26
The contract model in FIRST

• Set of modules, each one contains the API for a
  specific and well defined subset of
  functionalities

Core
Implementation specific
First Scheduling Framework
Shared objects
Hierarchical schedulers
Dynamic reclamation
Distribution
Spare capacity sharing
27
Contract parameters

• Core parameters
• (Qmin, Qmax) min and max budget
• (Pmin, Pmax) min and max budget
• Deadline
• Granularity (discrete continuous)
• Signaling
• Negotiation
• If it can be admitted, selects (Q, P)
• At run-time, it guarantees Q every P units of
  time, within D from the start

28
Resource Reservations

• The underlying scheduling mechanism is based on
  Resource Reservations
• Each application is reserved a fraction of the
  resource in terms of (budget, period)
• The application is guaranteed to receive at least
  that amount of resource
• Resource Reservation algorithms
• There are many, for FP and for EDF
• FP Polling server, Sporadic Server, Deferrable
  Server
• EDF Constant Bandwidth Server (CBS), GRUB, CASH,
  

29
Resource Reservations
30
Scheduling

• Each reservation is managed by a server
• SERVER An object internal to the OS that
  updates run-time state of the reservation
• Each Reservation can handle more than one task
  (hierarchical scheduling)

U1
t1
server
Ready queue
U2
t2
CPU
server
t3
EDF
U3
server
U1 U2 U3 ? 1
t4
31
Virtual Processor Analogy

• A task in a reservation behaves approximately
  like on a dedicated virtual processor
• The approximation is given by the time
  granularity of the allocation (the period of the
  reservation P)

?1
P1
?1
?2
?3
Prioritized Access
READY QUEUE
?2
P2
?3
P3
?1
?1
U1
50
Resource Reservation
?2
U2
?2
30
U3
?3
?3
20
32
Example with reservations

• Three processes, with reservations
• Q11, P14, U 0.25
• Q23, P26, U 0.5
• Q32, P38, U 0.25

Needs to execute 5 instead of 3...
Needs to execute 2
33
Properties

• Individual timing guarantees
• The ability of a task to meet its deadline
  depends only on the amount of resources reserved
  to it
• If a task wants to use more than reserved, it is
  delayed and does not influence the rest of the
  tasks
• Approximation of Virtual Processor
• Independence from underlying scheduling algorithm
• The designer needs not to know about FP or EDF,
  but only about the reservation
• Toward a component-based methodology
• It is possible to analyze a subsystem
  independently of the others!

34
Design Process
OFF- LINE
Design model
Task model (timing)
Subsystem
Scheduling Analysis
Sub-Schedule Properties
Task model (timing)
Scheduling Analysis
Sub-Schedule Properties
Subsystem
Contract
Implementation
Scheduler
Schedule
Contract
Implementation
RUN-TIME
35
Guarantees and reclamation

• Negotiation
• Schedulability test depends on underlying
  scheduling algorithm
• FP response time analysis for servers
• EDF utilization-based test or pseudo-polynomial
  test
• Admission based on Qmin and Tmax
• Spare Capacity
• If there is free space, the algorithm computes
  Qmin lt Q lt Qmax and Pmin lt P lt Pmax
• Distribution of free space based on weights
• Dynamic reclamation
• At run-time, use the extra capacity not used by
  other tasks
• If (Q, P) has been negotiated, at run time the
  task can get more than Q

36
Contract Negotiation
Service Thread
User Thread
msg queue
fsf_negotiate_contract()
msg queue

• Client/server structure
• the service thread is assigned a contract
• response time
• Service thread contract params (Cmin, Tmax, D)
• Computation time for negotiation G

37
Scheduling techniques
38
Resource Reservation Scheduling

• Many scheduling algorithms
• Aperiodic servers (Polling, Deferrable, Sporadic,
  Constant Bandwidth Servers)
• Many reclamation algorithms (CASH, BASH, IRIS, )
• We present GRUB
• (Greedy Reclamation of Unused Bandwidth)
• A RR scheduling algorithm based on EDF
• Based on CBS
• Properties
• Virtual processor analogy
• Dynamic reclamation of bandwidth
• Can be used for hierarchical system

39
GRUB

• System set of servers
• A server is the run-time object that manages a
  reservation
• Server
• Parameters (Q, P), U Q / P
• Variables d server deadline, V virtual
  time
• States and transitions

40
Rules

• Initially, server is inactive
• When task is activated (1.a)
• Vt, dtP
• While task execute
• dV dt U / Uact
• If V d (and task not completed) (4)
• Go to depleted until d t
• When budget recharged (5)
• V t, d d P
• When task completes
• until V lt t, stay in completed (2.b)
• When V t, go to inactive (2.c or 3)

• Active servers
• Servers not in inactive

41
An example of execution
U 0.5 P 5
V
Cont.
Depl.
Inac
Comp.
t
42
An example of execution (VP analogy)

• Two tasks
• Task 1 requires C2,4, T8 it is assigned Q4,
  P8, U0.5
• Task 2 requires C4,8, T12 it is assigned
  Q6, P12, U0.5

(2)
(4)
Task1
0
2
4
6
8
10
12
14
16
t
inactive
VP1
V1
(8)
Task2
t
VP2
V2
Uact
t
43
Shared Resources

• Resource Reservations are for independent tasks
• Interaction model
• Shared memory
• Critical sections guarded by mutex semaphores
• Blocking time due to locked critical sections
• Tasks cannot be considered independent anymore
• Bandwidth Inheritance Protocol (BWI)
• Extends Priority Inheritance to Resource
  Reservations
• Temporal isolation between non-interacting
  servers is maintained
• Limited interference between interacting servers

44
Bandwidth Inheritance

• Priority Inheritance
• A task inside a critical section inherits the
  priority of the blocked tasks
• Bandwidth Inheritance
• A task inside a critical section inherits the
  bandwidth (i.e. the pair Q, P) of the blocked
  tasks
• Interference a task can steal the reservation of
  someone else only for the duration of one
  critical section
• It is possible to compute maximum interference
  (under certain conditions)
• Temporal isolation is broken but
• Interference limited to interaction tasks and
  limited to critical sections
• Non interacting tasks are temporally isolated

45
Applications
46
Hard real-time tasks

• Contract Parameters
• QminQmax WCET of the thread
• PminPmax threads period
• D threads deadline
• budget overrun exception handling
• Advantages
• The thread is protected from the other non-RT and
  soft RT threads in the system (temporal
  isolation)
• if dynamic reclaimation, the spare capacity of
  this thread can be given to others

47
Soft real-time tasks

• Contract Parameters
• Qmin Qmax variation of the execution time
• PminPmax threads period
• D threads deadline
• Advantages
• Does not impact on other threads (temporal
  isolation)
• minimum service is guaranteed
• Takes advantage of capacity sharing and dynamic
  reclamation (to minimize deadline misses)
• can re-negotiate if it needs more

48
Imprecise computation model

• Thread consists of a mandatory part and N
  optional parts
• WCET of mandatory part M
• WCET of i-th optional part Oi
• What is needed
• Core (capacity sharing) (dynamic recl.)
  (shared res. synch.)
• Contract Parameters
• Cmin M
• Cmax M O1 ... ON
• Tmin Tmax threads period
• D threads deadline

49
Example thread structure for imprecise
computation
void task_body(void arg) ... pthread_t
my_pid (pthread_t)(arg) int i
sys_gettime(acttime) fsf_get_server(server,
my_pid) while(1) / Mandatory Body /
for (i0 iltN i) fsf_get_available_capacit
y(server, capacity) if (capacity gt Oi)
/ Optional Code / else break
ADDUSEC2TIMESPEC(uperiod,acttime)
fsf_schedule_next_timed_job(acttime,budget,peri
od, budget_missed,deadline_misse
d)
50
Evaluation of dynamic reclamation

• First experiment
• 4 periodic tasks
• with variable execution time 1,15 msec, 100
  msec period
• Each one is assigned a budget of 15 msec over a
  period of 100 msec (15)
• 2 non-periodic tasks trying to reclaim as much as
  they can
• they are assigned two servers
• budget Qmin,max 3 msec, period Pmin,max
  60 msec (5 each)
• Results

Task Expected bandwidth Actual received bandwidth
?5 5 16.93
?6 5 16.94
51
Evaluation of dynamic reclaimation

• Imprecise computation task experiment
• workload, same as in the previous experiment
• 4 tasks, execution time 1,15 msec, period 100
  msec (15)
• One imprecise computation task, a mandatory part
  and 3 optional parts
• mandatory execution requirement 5 msec
• budget 5 msec, period 50 msec

Part exec time exec exec
mand. 5 400 100
opt. 1 1 195 48.75
opt. 2 2 186 46.5
opt. 3 4 69 17.25
Part exec time exec exec
mand. 5 400 100
opt. 1 4 75 18.75
opt. 2 2 75 18.75
opt. 3 1 75 18.75
52
Hierarchical Systems and Components
53
Why Hierarchical Real-Time systems?

• Simplify the design of complex distributed
  systems
• system as hierarchy of components
• Independent design and implementation of
  sub-systems
• separation between interface and implementation
• Re-use of existing and well-tested components
• to reduce development cost
• Dynamic and on-line (re-)configuration
• possibility to easily substitute or upgrade a
  component, possibly on-line

54
Hierarchical systems
component C1
component C2
Required Interface
Provided Interface
Required Interface
Provided Interface
Global scheduler
55
Local scheduler

• Why?
• Priorities are local (implementation dependent)
• Different components may need different
  schedulers
• By defining the schedule (i.e. the order of
  execution), it is easier to test and validate the
  component in isolation
• It is possible to change priorities (or even the
  entire scheduler) without changing the interface
• Existing research
• Feng and Mok RTSS 03, Shih and Lee RTSS 04 and
  05, Lipari and Bini ECRTS 03 and JEC 05

Hierarchical scheduling 3/6
56
Global and local scheduling

• Separation of concerns
• Role of the global scheduler
• Partition the time line into time slices, and
  allocate time slices to different components
• The global scheduler does not need to know the
  internal structure of the components
• Role of the local scheduler
• Schedule tasks inside the allocated time slices

C1
C2
57
Global and local scheduler
Global scheduler
C1
C2
Local scheduler for C1
58
Analysis
Application b asks resource to Sj
Sj bids resource to Application b
If the amount of resource provided by Sj is
always enough to satisfy the requirements of
Application b, then it is schedulable!
59
Analysis

• Resource provided by a time partition
• Can be done statically (e.g. TDMA)
• Or dynamically (e.g. Resource Reservations)
• Parameters of a partition
• Delay ? maximum delay before execution
• Rate a average rate of resource allocation

at
60
Partitioning the time

• The amount of processing resources assigned to a
  component can be modeled by three parameters

rate
burstiness
delay
61
Virtual processor analogy

• The Resource Reservation behaves like a virtual
  processor
• A processor of speed a times the speed of the
  original processor
• With a maximum delay ?
• The delay is a measure of the time granularity
• A resource reservation approximates a fluid
  allocation of rate a
• The approximation error is ?

62
Distributed systems
(40, 1, 1)
(20, 2, 1)
(40, 1, 1)
Single processor
63
Analysis

• Analysis is done in the virtual processors
• We have a distributed system, where each
  component executes in a different virtual node
• Communication is done through a virtual network
• if two virtual processors are mapped onto the
  same physical node, communication has zero delay

64
Holistic Analysis

• We adapted the holistic analysis (Tindell et al.,
  94) to the case of virtual processors
• The system is transformed into a set of
  transactions
• A transaction is a chain of tasks
• A task is a portion of a thread

65
Holistic Analysis

• Fix the reservation parameters (Q, P)
• derive parameters (?, ?)
• Iterative algorithm
• Each task in a transaction has offset and jitter
• Initially all jitters 0
• Calculate response time for each task (depends on
  ?, ?)
• jitter response time of previous task
• iterate until response time converges
• If response times lt deadlines, schedulable

66
Quality of Service Control
67
QoS management

• Problem with resource reservation
• Thanks to resource reservation, we can analyze a
  task in isolation!
• ... but how much bandwidth should a task be
  assigned?
• The execution requirements of a task depend on
  the hardware of the system and on the input data
• Two different sub-problems
• For a normal task, with constant execution time,
  we must assign the initial reservation
• For tasks with highly variable execution times,
  we must dynamically adjust the bandwidth
• Example MPEG players

68
Feedback control

• Possible solution
• feedback control to dynamically adjust the
  assigned bandwidth
• Why feedback control?
• Resource demand vary in time
• A static allocation can, at certain times, be
  overly conservative and, at others determine
  performance degradations

Note Data files are courtesy of Philips
Research
69
Feedback scheduling

• One controller per task
• the controlling strategy depends on the kind of
  application
• Each controller tries to set the scheduling error
  to 0
• The scheduling error ? is the difference between
  the expected finishing time and the actual
  finishing time

70
Case study the Xine media player

• A multi-standard video player
• multi-thread (two pipelines of threads)
• resource reservation and feedback applied only to
  the Video Decoder thread

Disk
Video Decoder
DeMux
Synchro
Visualizer
Audio Decoder
71
Results

• Fixed bandwidth equal to average (U 12.6)

• Great degradation of the quality of service

72
Results

• Fixed bandwidth equal more than average (U 14)

• Not enough for peak, but also some wasted
  bandwidth

73
Results

• Bandwidth dynamically adapted via feedback control

• Average allocated bandwidth U 13

74
AQuOSA manager component

• Components
• Kernel module
• Application library
• feedback controller sub-components
• Features
• possibility to specify min / max budget
  allocations
• the actual budget may vary between min/max
• possibility to specify a different feedback
  scheduler for each process

75
Bibliography

• GRUB algorithm
• Lip00 G.Lipari and S.K. Baruah "Greedy
  reclaimation of unused bandwidth in constant
  bandwidth servers" IEEE Proceedings of the 12th
  Euromicro Conference on Real-Time Systems,
  Stokholm, Sweden, June 2000
• Sco07 Claudio Scordino, Giuseppe Lipari, A
  Resource Reservation Algorithm for Power-Aware
  Scheduling of Periodic and Aperiodic Real-Time
  Tasks, IEEE Transactions on Computers (2006)
• IRIS Algorithm
• Mar04 Luca Marzario, Giuseppe Lipari, Patricia
  Balbastre, Alfons Crespo, "IRIS a new reclaiming
  algorithm for server-based real-time systems",
  Real-Time Application Symposium (RTAS 04),
  Toronto (Canada), May 2004

76
Bibliography

• BWI protocol
• Lip06 Lipari G., Abeni L., Lamastra G. Task
  Synchronisation in Reservation-Based Real-Time
  Systems, IEEE Transactions on Computers (2004)
• Hierarchical Systems
• Bin04 Giuseppe Lipari, Enrico Bini, A
  methodology for designing hierarchical scheduling
  systems, Journal of Embedded Computing (2004)
• Lor06 José Lorente, Giuseppe Lipari, Enrico
  Bini, A Hierarchical Scheduling Model for
  Component-Based Real-Time Systems Workshop on
  Parallel and Distributed Real-Time System, (2006)

77
Bibliography

• QoS adaptation mechanisms
• Pal05 Luca Abeni, Tommaso Cucinotta, Luca
  Marzario, Luigi Palopoli, Giuseppe Lipari, QoS
  Management through Adaptive Reservations,
  Real-Time Systems (2005)
• FSF framework
• Gon06 M. Aldea et al. FSF A Real-Time
  Scheduling Architecture Framework, Proceedings
  of the 12th IEEE Real-Time and Embedded
  Technology and Applications Symposium (2006)
• Summary on Soft Real-Time Systems
• But06 Giorgio Buttazzo, Giuseppe Lipari, Luca
  Abeni and Marco Caccamo, Soft Real-Time Systems
  Predictability vs. Efficiency, Springer, January
  2005