Scuola Superiore SantAnna Contract-based scheduling Giuseppe Lipari.

Scuola Superiore Sant’Anna

Contract-based scheduling

Giuseppe Lipari

23 Feb. 2007 MOTIVES - ARTIST 2 Winter School

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 TheoryClassical 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)

),,( iiii TDC

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

),,( ijijijij dcaJ

iijij

iij

iijij

ij

Dad

Cc

Taa

J1


6

Scheduling analysis

Task model(timing)

Implementation Scheduler Schedule

SchedulingAnalysis

ScheduleProperties

Designmodel

OFF- LINE

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

• 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

Task model(timing)

Implementation Scheduler Schedule

SchedulingAnalysis

ScheduleProperties

Designmodel


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

task1

task2

Temporal fault

Executingmore than expected...

task2 fails!!

task1

task2


13

Example with EDF

• Three tasks scheduled by EDF– C1=1, T1=4– C2=?, T2=6– C3=2, T3=8

It’s executing too much... (5 instead of 3)

Deadline miss!

task1

task2

task3


14

Design for average case

• Consider a soft real-time application– Worst case >> 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

Problems with a single scheduler

Task1 Task2

Component C1

Task3 Task4

Component C2

Global scheduler

Task1 Task2 Task3 Task4

prio(Task1) > prio(Task2)prio(Task3) > prio(Task4)Possible priority ordering:1. prio(Task1) > prio(Task2) >

prio(Task3) > prio(Task4)

2. prio(Task1) > prio(Task3) > prio(Task2) > prio(Task4)

3. prio(Task3) > prio(Task1) >prio(Task2) > prio(Task4)





18

Schedulability Analysis

• Scheduling analysis can only be performed when1. We already have all tasks with their code

2. 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 SchedulingContract 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

DistributionDistribution

FirstSchedulingFramework

Shared objectsShared objects

Spare capacitysharing

Spare capacitysharing

CoreCore Implementationspecific

Implementationspecific

Hierarchicalschedulers

Hierarchicalschedulers

Dynamicreclamation

Dynamicreclamation


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

P

D

Q


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

10 %

45 %25 %

20 %

1

23

4

Resource partition

Each application receives a bandwidth Ui = Qi / Pi

Resource enforcement

A mechanism that prevents a task to consume more than its reserved amount.

If a task executes more, it is delayed, preserving the resource for the other tasks.


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)

1

2 CPU

serverReady queue

EDF

U1

U2

U3

U1 + U2 + U3 1

server

server

3

4


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

2

3

1

2

3

1 2 3

1

2

3

U2

U1

U3

PrioritizedAccess

ResourceReservation

P2

P1

P3

READY QUEUE

50%

30%

20%


32

Example with reservations

• Three processes, with reservations– Q1=1, P1=4, U = 0.25– Q2=3, P2=6, U = 0.5– Q3=2, P3=8, 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

Task model(timing)

Implementation

Scheduler Schedule

SchedulingAnalysis

Sub-ScheduleProperties

Designmodel

OFF- LINE

RUN-TIME

Task model(timing)

Subsystem

Subsystem

Implementation

SchedulingAnalysis

Sub-ScheduleProperties

Contract

Contract


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 < Q < Qmax

and Pmin < P < 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

• Client/server structure:– the service thread is assigned a contract – response time:

– Service thread contract params: (Cmin, Tmax, D)– Computation time for negotiation: G

ServiceThread

msg queueUser

Thread

fsf_negotiate_contract()

msg queue

G TmaxDQmin R

DPQ

GR

1max

min


37

Scheduling techniquesScheduling 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

• Active servers – Servers not in inactive

activeS

iact

i

UU

• Initially, server is inactive

• When task is activated (1.a)– V=t, d=t+P

• 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 < t, stay in completed (2.b)– When V ≥ t, go to inactive (2.c or 3)


41

d

An example of execution

t

V

U = 0.5P= 5

Inac

Cont.

Comp.

Depl.

An example of execution (VP analogy)

• Two tasks– Task 1 requires C=[2,4], T=8; it is assigned Q=4, P=8, U=0.5– Task 2 requires C=[4,8], T=12; it is assigned Q=6, P=12, U=0.5

Task1

VP1

Task2

VP2

Uact

0 2 4 6 8 10 12 14 16

0 2 4 6 8 10 12 14 16

0 2 4 6 8 10 12 14 16

t

V1

t

t

V2

(2)

(8)

(4)

inactive


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

ApplicationsApplications


46

Hard real-time tasks

• Contract Parameters– Qmin=Qmax= WCET of the thread

– Pmin=Pmax= thread’s period

– D = thread’s 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

– Pmin=Pmax= thread’s period

– D = thread’s 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 = thread’s period

– D = thread’s deadline


49

Get remainingcapacity

If enough capacityexecute optionalpart

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 (i=0; i<N; i++) {

fsf_get_available_capacity(server, &capacity);if (capacity > O[i]) {

/* Optional Code */ }

else break; } ADDUSEC2TIMESPEC(uperiod,&acttime); fsf_schedule_next_timed_job(&acttime,&budget,&period, &budget_missed,&deadline_missed); } }


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

55% 16.93%

65% 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

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

Global scheduler

Required Interface

Provided Interface

component C1

Required Interface

Provided Interface

component C2

Local Scheduler

Task 1

Task 2

Local Scheduler

Task 3Task 4

Task 5


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


57

Global and local scheduler

C1

C2

C1

Task1

Task2

Global scheduler

Local scheduler for C1

temporalpartition


58

Analysis

Application asks resource

to Sj

Sj bids resource

to Application

If the amount of resource provided by Sj is

always enough to satisfy the requirements of Application then it is schedulable!

Sj

App.


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 α 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 α – The approximation error is Δ


62

Distributed systems

C2

C1 C3

Platform 1 Platform 2 Platform 3

(40%, 1, 1) (40%, 1, 1)(20%, 2, 1)

Single processorNode 1 Node 2

Network


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

Platform 1 Platform 2 Platform 3


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 < deadlines, schedulable


66

Quality of Service ControlQuality 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

Note: Data files are courtesy of Philips Research

• 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

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

QoS Manager

Proc P1

Proc P2

Proc P3

QoS SchedulerQoS Supervisor

Controller 1

Controller 2

Controller 3

Q1

Q2

Q3

Q’1

Q’2

Q’3

1

2

3


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

DeMux

Video Decoder

AudioDecoder

Synchro Visualizer

Disk


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

Scuola Superiore SantAnna Contract-based scheduling Giuseppe Lipari.

Documents

Transcript of Scuola Superiore SantAnna Contract-based scheduling Giuseppe Lipari.