RIStAL Centre de Recherche en Informatique, Signal et Automatique - - PowerPoint PPT Presentation
Real-Time scheduling under uncertainty : challenges and solutions G. Lipari EDIS 2017, 17-18 December 2017 1 RIStAL Centre de Recherche en Informatique, Signal et Automatique de Lille Outline 1 Plan of the talk 2 Introduction to Real-Time
Centre de Recherche en Informatique, Signal et Automatique de Lille
EDIS 2017, 17-18 December 2017
1
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 2
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 3
1 General introduction to real-time scheduling
Real-time systems Scheduling and scheduling analysis
2 Worst-case execution time
How to compute WCET sources of variability Modern multi-core processors
3 Temporal isolation
Soft and hard real-time tasks How to isolate tasks A real-time scheduler in Linux
4 Multicore Systems
Additional variability how to isolate on multicore 4
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 5
From “Wikipedia” : An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, sometimes with real-time computing
device including hardware and mechanical parts. Interaction with physical process
sensors, actuators → timing constraints (latency, jitters) 6
In real-time systems, the correct behaviour of a system depends, not only on the values of results that are produced, but also on the time at which they are produced.
John Stankovic. Misconceptions about real-time computing . IEEE Computer, October 1988
Predictable system :
we want to know a-priori if the system will respect its timing constraints
Real-time systems are predictable
(and not necessarily fast) 7
Modern cars : ABS, Power Train, Intelligent braking system, etc.
8
Set of concurrent real-time tasks
simple periodic structure
void * PeriodicTask(void *arg) { <initialization>; <start periodic timer, period = T>; while (cond) { <read sensors>; <update outputs>; <update state variables>; <wait next activation>; } }
9
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
Example : two periodic control tasks
Task 1 : controls gas injection in engine, period 6 msec Task 2 : controls cooling system, period 10 msec
Tasks’ execution is graphically represented with GANNT charts
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
τ1 τ2
10
A task is said hard real-time if all its deadlines must be respected, otherwise a critical failure occurs in the system
we have to guarantee a-priori (before the system runs) that all deadlines will be respected under all possible conditions ;
In a soft real-time task, nothing catastrophic happens if a deadline is missed ;
Some deadline can be missed with little or no consequences on the correctness of the system ; However, the number of missed deadline must be kept under control, because the quality of the results depend upon on the number of deadline missed ; 11
Fixed priority scheduling : Orders all active tasks according to their priority
every task τi is assigned a fjxed priority pi ; the active task with the highest priority is scheduled. priorities are integer numbers : the higher the number, the higher the priority ;
Scheduling analysis
Given a set of concurrent tasks with their priorities, check if all task will meet their deadlines 12
Given a task set, how can we guarantee if it is schedulable of not ?
The fjrst possibility is to simulate the system to check that no deadline is missed ; For periodic tasks, simulate until the hyperperiod (least common multiple of all periods)
Compare the hyperperiod of these two task sets : T1 = 8, T2 = 12, T3 = 24 T1 = 7, T2 = 12, T3 = 25
13
Given a task set, how can we guarantee if it is schedulable of not ?
The fjrst possibility is to simulate the system to check that no deadline is missed ; For periodic tasks, simulate until the hyperperiod (least common multiple of all periods)
Compare the hyperperiod of these two task sets : T1 = 8, T2 = 12, T3 = 24 ⇒ H = 24 T1 = 7, T2 = 12, T3 = 25
13
Given a task set, how can we guarantee if it is schedulable of not ?
The fjrst possibility is to simulate the system to check that no deadline is missed ; For periodic tasks, simulate until the hyperperiod (least common multiple of all periods)
Compare the hyperperiod of these two task sets : T1 = 8, T2 = 12, T3 = 24 ⇒ H = 24 T1 = 7, T2 = 12, T3 = 25 ⇒ H = 2100
13
Every task is characterized by a Worst-Case Execution Time Ci
it is the largest execution time experienced by the task
Each task is characterised by a period Ti The utilisation of a task is computed as Ci
Ti
it is the fraction of the processor that is needed by the task
A task with execution time Ci = 4 msec and period Ti = 10 msec, has an utilisation of Ui = 0.4 → 40%. Total utilisation : the sum of the utilisations of all tasks An easier test
if the total utilization is less than or equal to the utilization least upper bound, then it is schedulable 14
Every task is characterized by a Worst-Case Execution Time Ci
it is the largest execution time experienced by the task
Each task is characterised by a period Ti The utilisation of a task is computed as Ci
Ti
it is the fraction of the processor that is needed by the task
A task with execution time Ci = 4 msec and period Ti = 10 msec, has an utilisation of Ui = 0.4 → 40%. Total utilisation : the sum of the utilisations of all tasks An easier test
if the total utilization is less than or equal to the utilization least upper bound, then it is schedulable 14
Consider n periodic (or sporadic) tasks with relative deadline equal to periods, whose priorities are assigned in Rate Monotonic order. Then, Ulub = n(21/n − 1) n Ulub n Ulub 2 0.828 7 0.728 3 0.779 8 0.724 4 0.756 9 0.720 5 0.743 10 0.717 6 0.734 11 …
15
An important class of scheduling algorithms is the class of dynamic priority algorithms
the priority of a task can change during its execution
The most important (and analyzed) dynamic priority algorithm is Earliest Deadline First (EDF)
The priority of a job is inversely proportional to its absolute deadline ; the highest priority job is the one with the earliest deadline ; If two tasks have the same absolute deadlines, chose one of the two at random (ties can be broken arbitrarily) 16
We schedule the following task set with FP (RM priority assignment).
τ1 = (1, 4), τ2 = (2, 6), τ4 = (3, 8). U = 1
4 + 2 6 + 3 8 = 23 24
The utilization is greater than the least upper bound : there is a deadline miss !
1 2 3
17
We schedule the following task set with FP (RM priority assignment).
τ1 = (1, 4), τ2 = (2, 6), τ4 = (3, 8). U = 1
4 + 2 6 + 3 8 = 23 24
The utilization is greater than the least upper bound : there is a deadline miss !
2 4 6 8 10 12 14 16 18 20 22 24
τ1 τ2 τ3
17
Now we schedule the same task set with EDF. τ1 = (1, 4), τ2 = (2, 6), τ4 = (3, 8). U = 1
4 + 2 6 + 3 8 = 23 24 2 4 6 8 10 12 14 16 18 20 22 24
τ1 τ2 τ3
18
If a set of jobs J is schedulable on a single processor by an algorithm A, then it is schedulable by EDF.
EDF is an optimal algorithm for single processors.
Given a task set of periodic or sporadic tasks, with relative deadlines equal to periods, the task set is schedulable by EDF if and only if U =
N
Ci Ti ≤ 1
19
Advantages of EDF over FP
EDF can schedule all task sets that can be scheduled by FP
but not vice versa
There is no need to defjne priorities EDF has less context switches
Advantages of FP over EDF
FP is more predicatable With FP it is easier to control the response time
by raising the priority
More efficient implementation in microcontrollers 20
In case of overload U > 1 :
2 4 6 8 10 12 14 16 18 20 22 24
τ1 τ2 τ3 τ4
21
FP is more predictable : only lower priority tasks miss their deadlines ! In the previous example, if we use FP :
2 4 6 8 10 12 14 16 18 20 22 24
τ1 τ2 τ3 τ4
22
Fixed Priority is the de facto standard in industry
Supported in all RTOS Easier to understand and to implement
EDF is used in some specifjc settings
Supported in Linux (see later)
However, beware of overloads !
Several tasks in the system the higher priority task controls the spark timing of the engine the lower priority task reads the position of the accelerator pedal…
23
In order to do analysis, we need to compute the Worst-Case Execution Time of each tasks The execution time depends on different factors
input data ; internal state ; hardware architecture (cache, pipeline, etc.).
while (cond) { a = // external input; if (a > 10) { // long computation } else { // short computation } }
variables a and cond infmuence the execution time if data for the long computation are not in cache, the execution time could be even longer
24
Measuring execution time is not safe Computing WCET is possible in principle
compute the program path that takes the longest under all possible conditions In practice computing an exact WCET is an intractable problem We can provide an upper bound 25
For certain applications, execution time may vary considerably
The image processing task exhibits a distribution with a long tail Design based on the worst-case would be very expensive
26
The WCET bound can be much higher than average execution time
due to the approximations in computing WCET due to intrinsic variability
This brings extra costs to the design of RT systems
the cost of WCET analysis (expensive tools) the extra resources to account for the WCET :
U =
n
Ui =
n
Ci Ti ≤ Ulub This extra cost is often acceptable for safety critical systems
cars, airplanes, etc.
However, it may be too much for less critical systems
27
Any RT systems contains task with different levels of criticality
More critical tasks that interact with external devices and environment, must never miss a deadline less critical tasks are computation intensive (e.g. encoding/decoding, logging, user interface, etc.) and they can sometimes miss a deadline Some control task can also be non critical ; for example, in a robotic system, some actuation may be delayed a little with negligible consequences (degradation of the quality of the control).
So, we often have a mixture of
hard real-time ⇒ no deadline must be missed soft real-time ⇒ deadline may be missed sometimes
We would like to control the deadline miss of each task separately
28
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 29
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) U = 0, 983 < 1 ⇒ schedulable
2 4 6 8 10 12 14 16 18 20 22
τ1 τ2 τ3
30
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) U = 0, 983 < 1 ⇒ schedulable
2 4 6 8 10 12 14 16 18 20 22
τ1 τ2 τ3
30
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) U = 0, 983 < 1 ⇒ schedulable
2 4 6 8 10 12 14 16 18 20 22
τ1 τ2 τ3
30
We want to isolate tasks
a temporal fault in one task should not impact on another one here temporal fault means that a task executes more than expected
Where is temporal isolation important ?
Mixed criticality systems Integrating tasks from different providers on the same systems 31
Assign each task to a server
a watchdog that monitors execution and enforces an execution budget
A server S = (Q, P)
Q : maximum execution budget P : minimim serving period U = Q/P : reserved bandwidth
Different algorithms in the literature
FP : Polling Server, Deferrable Server, Sporadic Server EDF : Dynamic Sporadic Server, Constant Bandwidth Server
Implementations
Sporadic Server is a POSIX standard (optional) CBS implemented in Linux (since 3.14), (available as SCHED_DEADLINE) 32
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
Consider τ1 = (1, 4), τ2 = (2, 5), τ3 = (2, 6) Assign τ1 a server S1 = (1, 4)
2 4 6 8 10 12 14 16 18 20
τ1 τ2 τ3 τ2 and τ3 are not infmuenced
33
CBS takes care of other possible cases
jobs arriving earlier (or later) than expected jobs executing more or less than expected server period can be different from task period
Properties :
Temporal isolation : no server misses its ”scheduling deadlines”
all server jobs execute the maximum budget before their scheduling deadlines
Hard Schedulablity : if a task is assigned Qi ≥ Ci and Pi ≤ Ti, then it will never miss its deadlines
Thanks to this properties we can easily mix hard and soft real-time tasks simply by assigning the correct parameters (budget/periods)
34
Two dynamic variables
q : remaining budget (init to Q, decreases while executing) d : scheduling deadline
Idle Idle Active Ahead
q = Q , d = t + P if q < (d − t)Q/P if q ≥ (d − t)Q/P when q = (d − t)Q/P
Q = 4, P = 12
2 4 6 8 10 12 14 16
τ1 t 0 : q 4, d 12 t 4 : q 2 t 7 : q 1 t 9 : zero lag time
35
Two dynamic variables
q : remaining budget (init to Q, decreases while executing) d : scheduling deadline
Idle Active Active Ahead
q = Q , d = t + P q = Q , d = t + P if q < (d − t)Q/P if q ≥ (d − t)Q/P when q = (d − t)Q/P
Q = 4, P = 12
2 4 6 8 10 12 14 16
τ1 t = 0 : q ← 4, d ← 12 t 4 : q 2 t 7 : q 1 t 9 : zero lag time
35
Two dynamic variables
q : remaining budget (init to Q, decreases while executing) d : scheduling deadline
Idle Active Active Ahead
q = Q , d = t + P if q < (d − t)Q/P if q ≥ (d − t)Q/P when q = (d − t)Q/P
Q = 4, P = 12
2 4 6 8 10 12 14 16
τ1 t = 0 : q ← 4, d ← 12 t = 4 : q ← 2 t 7 : q 1 t 9 : zero lag time
35
Two dynamic variables
q : remaining budget (init to Q, decreases while executing) d : scheduling deadline
Idle Active Ahead Ahead
q = Q, d = t + P if q < (d − t)Q/P if q < (d − t)Q/P i f q ≥ ( d − t ) Q / P when q = (d − t)Q/P
Q = 4, P = 12
2 4 6 8 10 12 14 16
τ1 t = 0 : q ← 4, d ← 12 t = 4 : q ← 2 t = 7 : q ← 1 t 9 : zero lag time
35
Two dynamic variables
q : remaining budget (init to Q, decreases while executing) d : scheduling deadline
Idle Idle Active Ahead
q = Q , d = t + P if q < (d − t)Q/P if q ≥ (d − t)Q/P when q = (d − t)Q/P when q = (d − t)Q/P
Q = 4, P = 12
2 4 6 8 10 12 14 16
τ1 t = 0 : q ← 4, d ← 12 t = 4 : q ← 2 t = 7 : q ← 1 t = 9 : zero lag time
35
Setting the budget
the Hard Schedulability Property tells us that, to meet all deadlines, Qi ≥ Ci and Pi ≤ Ti If we allow some deadline to be missed, we can set the budget between the average value and the worst case value of the execution time We need some sort of probabilistic characterization of the execution time
Probability of deadline miss
For a periodic task, given the stochastic process of the execution time, the probability of missing a deadline can be computed under different conditions 36
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 37
With recent processor architectures, the difference between BCET and WCET became larger and larger
Figure – Courtesy of AbsInt
Impact of cache and shared resources Situation even worse on multi-core systems
38
Preemption :
preempting tasks could evict cache lines next time the task executes the data is not in the cache anymore
while (i < 10) { data = getInput(); // ... // possible preemption function(data); // is data in cache ? }
Some (partial) solution is available
avoid (or limit) preemption additional blocking time for higher priority tasks lock cache to some task try to minimise cache confmicts by properly placing tasks in memory 39
Preemption :
preempting tasks could evict cache lines next time the task executes the data is not in the cache anymore
while (i < 10) { data = getInput(); // ... // possible preemption function(data); // is data in cache ? }
Some (partial) solution is available
avoid (or limit) preemption → additional blocking time for higher priority tasks lock cache to some task try to minimise cache confmicts by properly placing tasks in memory 39
In multicore systems
a task running on another core could evict cache lines from a common cache need to coordinate task execution to minimize cache eviction while a task is executing
Confmicts on shared bus :
different cores may need to access memory at the same time, further delaying memory access instructions 40
Automotive systems are now turning to multicore Freescale Qorivva 32-bit MCU
41
One of the main drivers of multi-core technology
possibility to integrate different applications in the same ECU thus reducing the number of ECUs and the lenght of the network cables
It is important to isolate one application from another
Applications can have different level of criticalities But they share the same memory, bus, etc. They are developed by different companies / teams 42
Memory isolation
Use MMU and separate address spaces
Reduce confmicts on bus
Time triggered architecture, fjxed slots Every core/peripheral is assiged a slot Reduces performances !!
Reduce cache evictions
1 Cache coloring 2 Cache locking 3 Separate caches as much as possible 4 Use scratchpad memory 5 Disable cache entirely
Time isolation
Use resource reservations EDF + CBS ! 43
Memory isolation
Use MMU and separate address spaces
Reduce confmicts on bus
Time triggered architecture, fjxed slots Every core/peripheral is assiged a slot Reduces performances !!
Reduce cache evictions
1 Cache coloring 2 Cache locking 3 Separate caches as much as possible 4 Use scratchpad memory 5 Disable cache entirely
Time isolation
Use resource reservations EDF + CBS ! 43
Memory isolation
Use MMU and separate address spaces
Reduce confmicts on bus
Time triggered architecture, fjxed slots Every core/peripheral is assiged a slot Reduces performances !!
Reduce cache evictions
1 Cache coloring 2 Cache locking 3 Separate caches as much as possible 4 Use scratchpad memory 5 Disable cache entirely
Time isolation
Use resource reservations EDF + CBS ! 43
Memory isolation
Use MMU and separate address spaces
Reduce confmicts on bus
Time triggered architecture, fjxed slots Every core/peripheral is assiged a slot Reduces performances !!
Reduce cache evictions
1 Cache coloring 2 Cache locking 3 Separate caches as much as possible 4 Use scratchpad memory 5 Disable cache entirely
Time isolation
Use resource reservations EDF + CBS ! 43
An interesting confmict of interests : Hardware designers
need to increase performance they reduce average latency … … by adding complexity … … thus increasing worst-case
Real-Time software designers
need predictability they disable complex hw solutions … … to limit worst-case … … at the price of wasted resources
This is the main reason for the slow adoption of multicore architectures in the embedded domain !
44
1 Plan of the talk 2 Introduction to Real-Time Systems 3 Temporal isolation 4 Multicore systems 5 Conclusions 45
Need for integration of mixed criticality systems Isolation is the key Solutions exist for critical hard real-time systems Some (difficult) solution is available for multicore
at the price of reduced performance 46
47