Real-time Systems Lab, Computer Science and Engineering, ASU Scheduling Algorithm and Analysis (ESP...
-
Upload
alicia-henderson -
Category
Documents
-
view
219 -
download
0
Transcript of Real-time Systems Lab, Computer Science and Engineering, ASU Scheduling Algorithm and Analysis (ESP...
Real-time Systems Lab, Computer Science and Engineering, ASU
Scheduling Algorithm and Analysis(ESP – Fall 2014)
Computer Science & Engineering DepartmentArizona State University
Tempe, AZ 85287
Dr. Yann-Hang [email protected](480) 727-7507
Real-time Systems Lab, Computer Science and Engineering, ASU
Task Scheduling
Schedule: to determine which task is assigned to a processor at any time order of execution meet deadlines, fast response time, utilize resource effectively
Need an algorithm to generate a schedule optimal scheduling algorithm: always find a feasible schedule if and
only if a feasible schedule exists Scheduler or dispatcher: the mechanism to implement a schedule Misconcept:
RTOS will schedule tasks to meet task deadlines A good schedule will reduce CPU load
2
Real-time Systems Lab, Computer Science and Engineering, ASU
Task Functional Parameters
Preemptivity: suspend the executing job and switch to the other one should a job (or a portion of job) be preemptable context switch: save the current process status (PC, registers, etc.) and
initiate a ready job transmit a UDP package, write a block of data to disk, a busy waiting
loop Preemptivity of resources: concurrent use of resources or
critical section lock, semaphore, disable interrupts
How can a context switch be triggered?
Assume you want to preempt an executing job -- why a higher priority job arrives run out the time quantum
waiting
executing
ready
blocked suspendeddispatched
wake-up
3
Real-time Systems Lab, Computer Science and Engineering, ASU
Event- and Time-Triggered Systems
Time-triggered control system All activities are carried out at certain points in time know a priori
at design time (based on a globally synchronized time base) Transmission of messages Task execution Monitoring of external states
All nodes have a common notion of time Event-triggered control system
All activities are carried out in response to events external to the system Reception of a message Termination of a task External interrup
4
Real-time Systems Lab, Computer Science and Engineering, ASU
0 10 20 30 40 50 60
Major and Minor Cycle Model
Time is divided into equal-sized frame minor cycle = length of frame Major cycle = length of schedule = k * minor_cycle
An example: A=(10,4) B=(20,6) C=(30,5) major cycle=60, minor cycle=10 scheduling string AB_AC_AB_AC_AB_A_
Jobs must be done within a minor cycle limit timing error to one frame suspend and resume as background, continue, or abort if overrun
5
Real-time Systems Lab, Computer Science and Engineering, ASU
An Example
A1 must be done at least every 10ms, and takes 1ms A2 must be completed with 5ms when E occurs and takes 2 ms E must be detected by polling and is detectable for at least 0.5
ms
E would not occur twice within 50 ms polling of E takes 0 overhead
0.5ms
6
Real-time Systems Lab, Computer Science and Engineering, ASU
Major/Minor Cyclic Scheduling There should be a periodic polling action for E
Assume a timer of 0.5ms to activate polling operation and no polling overhead
Should be an interval of 2ms to execute A2 for an arbitrary 5ms interval May detect E in the first frame and execute A2 in the second frame
period=2.5ms A2 takes 2ms if E, otherwise is 0 WCET=2ms
Should be an interval of 1ms to execute A1 for an arbitrary 10ms interval Period= 10ms, WCET= 1ms Since 2ms + 1ms > 2.5ms, we will divide A1 into two parts of 0.5ms
A2 A1_1 A2 A1_2 A2 A2 A2 A1_1 A2 A1_2 A2 A2
7
Real-time Systems Lab, Computer Science and Engineering, ASU
Time Triggered Architecture (TTA)
Multiple CPU nodes connected by a TDMA bus. Bus schedule is divided into fixed-length time slots, Each CPU node is assigned a time slot to transmit messages. Messages are delivered to their destination CPU nodes at the
end of the time slot, regardless of their exact arrival times.
8
Real-time Systems Lab, Computer Science and Engineering, ASU
Summary of Cyclic Schedule
Pros simple, table-driven, easy to validate (knows what is doing at any
moment) fit well for harmonic periods and small system variations static schedule deterministic, static resource allocation, no
preemption small jitter, no scheduling anomalies
Cons difficult to change (need to re-schedule all tasks) fixed released times for the set of tasks difficult to deal with dependencies schedule algorithm may get complex (NP-hard) doesn’t support aperiodic tasks efficiently Processes with sizeable computation times.
9
Real-time Systems Lab, Computer Science and Engineering, ASU
Priority-Driven Scheduling of Periodic Tasks
Why priority-driven scheduling use priority to represent urgency easy implementation of scheduler (compare priorities and dispatch
tasks) tasks can be added or removed easily no direct control of execution instance
How can we analyze the schedulability if we don’t know when a task is to be executed
Let’s begin a deterministic case in one processor independent periodic tasks deadline = period preemptable no overhead for context switch
10
Real-time Systems Lab, Computer Science and Engineering, ASU
Priority-Driven Schedules
Assign priority when jobs arrive static -- all jobs of a task have a fixed priority dynamic -- different priorities to individual tasks of a task relative priorities don’t change while jobs are waiting
Static priority schedules Rate-monotonic -- the smaller a task period, the higher its priority Deadline-monotonic – if deadline period, the smaller a task’s deadline
(relative), the higher its priority Dynamic priority schedules
EDF -- earliest deadline (absolute) first Schedulable utilization:
a scheduling algorithm can feasibly schedule any sets of priority tasks if the total utilization is equal to or less than the schedulable utilization of the algorithm
11
Real-time Systems Lab, Computer Science and Engineering, ASU
Earliest-deadline First (EDF) Schedule
Priority preemptive scheduling a job with earliest (absolute) deadline has the highest priority does not require the knowledge of execution time
Optimal if single processor, no resource contention, preemption
Scheduling anomaly if non-preemptive --- the schedule fails after we reduce job execution times
T1
T2
T3
D1 D2 D3
Missed deadline
( all jobs meet their deadline under EDF after increasing e1 )
12
Real-time Systems Lab, Computer Science and Engineering, ASU
dk di
JkJi
rk ( rk )
dk di
JkJk Ji
(non-EDF)
(EDF)
Earliest-deadline First (EDF) Schedule
Priority preemptive scheduling a job with earliest (absolute) deadline has the highest priority does not require the knowledge of execution time
Optimal if single processor, no resource contention, preemption why it is optimal: assume a feasible schedule
13
Real-time Systems Lab, Computer Science and Engineering, ASU
EDF Schedule
A optimal algorithm under single processor and preemptable tasks
How do we know a set of periodic tasks are schedulable under EDF ?
If we know the schedulable utilization SU of EDF, then any sets of tasks are schedulable when U SU
Theorem: A set of n periodic tasks can be scheduled by EDF iff
This schedulability utilization is no long true if deadline < period.
11
n
i i
i
p
eU
14
Real-time Systems Lab, Computer Science and Engineering, ASU
Example of EDF Schedule
A digital robot with EDF schedule control loop: ec 8ms at 100Hz BIST: eb 50ms given
BIST can be done every 250ms
Add a telemetry task to send and receive messages with et 15ms if BIST is done every 1000ms given
the telemetry task can have a relative deadline of 100ms sending or receiving must be separated at least 100ms
150
10
8
bbc p
uu
115
1000
50
10
8
tbc D
uu
15
Real-time Systems Lab, Computer Science and Engineering, ASU
Rate-Monotonic Scheduling Algorithm
A base case: no additional overhead, simple periodic tasks with pi =Di
Assign priorities according their periods Ti has a higher priority that Tk if i < k ( pi < pk ) Is RM optimal? if there is a feasible fixed-priority schedule, then RM is
feasible How do we know RM is feasible schedulability test
Results: RM is optimal if pi Di
sufficient condition utilization test
a complete test what is the worst response time given all possible arrivals and preemptions
)12( /1
1
nn
i i
i np
eU
16
Real-time Systems Lab, Computer Science and Engineering, ASU
Critical Instant
Critical instant of Ti: a job of Ti arriving at the instant has a maximum response time
If we can find the critical instant of Ti, then check whether all jobs of Ti meet their deadlines
let’s increase ei until the maximum response time = Di schedulable utilization
In-phase instant is critical: all higher priority tasks are released at the same instant (assume all jobs are completed before the next job in the tasme task is released.) which T2 has the maximum response time
T1 T2 T1, T2 T2 T1
17
Real-time Systems Lab, Computer Science and Engineering, ASU
Schedulability: UB Test
Utilization bound (UB) test: a set of n independent periodic tasks scheduled by the rate monotonic algorithm will always meet its deadlines, for all task phasings, if
For harmonic task sets, the utilization bound is U(n)=1.00 for all n.
U(1) = 1.0 U(4) = 0.756 U(7) = 0.728
U(2) = 0.828 U(5) = 0.743 U(8) = 0.724
U(3) = 0.779 U(6) = 0.734 U(9) = 0.720
1)n(2U(n)p
e.......
p
e /n1
n
n
1
1
18
Real-time Systems Lab, Computer Science and Engineering, ASU
Schedulability Test: Time-Demand Analysis
Consider in-phase instant only If Ji is done at t, then the total work must be done in [0,t] is
(from Ji and all higher priority tasks)
Can we find a t Di such that
wi(t) t cannot check all t [0, Di]
check all arrival instants and Di
The completion time of Ji satisfies
k
i
k kii e
p
tetw )(
1
1
k
i
k ki e
p
tet
1
1
t
w(t)
time Di
19
Real-time Systems Lab, Computer Science and Engineering, ASU
Schedulability: RT Test
Theorem: for a set of independent, periodic tasks, if each task meets its first deadline, with worst-case task phasing, the deadline will always be met.
Response Time (RT) test: let an = response time of task i. an may be computed by the following
iterative formula:
Test terminates when an+1 = an
Task i is schedulable if its response time is before its deadline: an ≤ Ti
i
1jj0j
1i
1j j
ni1n ea e where
p
aea
20
Real-time Systems Lab, Computer Science and Engineering, ASU
RMA for Periodic Tasks
A Sample Problem - Periodics
100 msec
40 msec
20 msec
Periodics Servers Aperiodics
20 msec
2 msec
10 msec
10 msec
50 msec
5 msec
Data Server
Comm Server
Emergency100 msec
150 msec
350 msec
Deadline 6 msec after arrival
1
2
3
21
Real-time Systems Lab, Computer Science and Engineering, ASU
Sample Problem: UB Test
Total utilization is
.200 + .267 + .286 = .753 < U(3) =.779 The periodic tasks in the sample problem are
schedulable according to the UB test.
e p U
Task 1 20 100 0.200
Task 2 40 150 0.267
Task 3 100 350 0.286
22
Real-time Systems Lab, Computer Science and Engineering, ASU
scheduling points
Timeline for The Sample Problem
0 100 200 300 400
3
2
1
23
Real-time Systems Lab, Computer Science and Engineering, ASU
Example: Applying RT Test (1)
Taking the sample problem, we increase the compute time of 1ז from 20 to 40; is the task set still schedulable?
Utilization for the first task : 40/100=0.4 < U(1) Utilization of first two tasks: 0.667 < U(2) = 0.828
First two tasks are schedulable by UB test
Utilization of all three tasks: 0.953 > U(3) = 0.779 UB test is inconclusive Need to apply RT test
24
Real-time Systems Lab, Computer Science and Engineering, ASU
Example: Applying RT Test (2)
Use RT test to determine if 3ז meets its first deadline:
i = 3
2608080100)40(150
180)40(
100
180100
pp
aee
p
aea
1801004040eeeea
j
2
1j j
03j
1i
1j j
0i1
321
3
1jj0
25
Real-time Systems Lab, Computer Science and Engineering, ASU
Example: Applying RT Test (3)
a3 = a2 = 300 Done!
Task is schedulable using RT test. a3 = 300 < p3 = 350
300)40(150
300)40(
100
300100e
p
aea
300)40(150
260)40(
100
260100e
p
aea
j
1i
1j j
2i3
j
1i
1j j
1i2
26
Real-time Systems Lab, Computer Science and Engineering, ASU
Timeline for The Example
0 100 200300
1
3
2
3 completes its work at t=300
27
Real-time Systems Lab, Computer Science and Engineering, ASU
Summary
UB test is simple but conservative RT test is more exact but also more complicated To this point, UB and RT tests share the same
limitations: All tasks run on a single processor All tasks are periodic and noninteracting Deadlines are always at the end of the period There are no interrupts Rate monotonic priorities are assigned There is zero context switch overhead Tasks do not suspend themselves
28
Real-time Systems Lab, Computer Science and Engineering, ASU
Modeling Task Switching
C1
S
e1
e2
e1
e2
1
2
3
e1
40 40
0 100 200
e1C1 C1
e1 S
e2C1 C1
C1
S e2 S S
time
e1
p1 p2 2p1
i
ii p
S2eU
Two scheduling actions per task(start of period and end of period)
29
Real-time Systems Lab, Computer Science and Engineering, ASU
Schedulability with Interrupts
Interrupt processing can be inconsistent with rate monotonic priority assignment. interrupt handler executes with high priority despite its period interrupt processing may delay execution of tasks with shorter
periods
Effects of interrupt processing must be taken into account in schedulability model.
Question is: how to do that?
30
Real-time Systems Lab, Computer Science and Engineering, ASU
Determining Schedulability with Interrupts
Task(i) Period(p) Execution Time(e)
Priority Deadline(D)
3200 60 HW 200
1100 20 High 100
2150 40 Medium 150
4350 40 Low 350
3 is an interrupt handler
31
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Interrupt Priority
Test is applied to each task. Determine effective utilization (fi) of each task i
using
q Compare effective utilization against bound, U(n).
n = num(Hn) + 1
num(Hn) = the number of tasks in the set Hn
1n Hk
kii
i
Hj j
ji e
p
1
p
e
p
ef
Preemption form the tasks
that can hit more than once
(with period less that Di)
Execution of a task
under test
Preemption from tasks
That can hit only once
(with period greater than Di )
32
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Interrupt Priority: 3
For 3, no tasks have a higher priority:
H = Hn =H1 = { }.
Note that utilization bound is U(1): num(Hn) = 0.
Plugging in numbers:
)1(U0p
e0f
3
33
0.13.0200
60
p
ef
3
33
33
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Interrupt Priority: 1
For 1, 3 has a higher priority: H = {3}; Hn = {};
H1 = {3}.
)1(Uep
1
p
e0f
3kk
11
11
Note that utilization bound is U(1): num(Hn) = 0.
Plugging in the numbers:
0.1800.0100
60
100
20
p
e
p
ef
1
3
1
11
34
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Interrupt Priority: 2
For 2 : H={1, 3}; Hn={1 }; H1={3 };
Note that utilization bound is U(2): num(Hn) = 1.
Plugging in the numbers:
)2(Uep
1
p
e
p
ef
3kk
22
2
1j j
j2
828.0867.0150
60
150
40
100
20
p
e
p
e
p
ef
3
3
2
2
1
12
35
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Interrupt Priority:
For 4 : H={1, 2, 3}; Hn={1 , 2, 3 }; H1={};
Note that utilization bound is U(4): num(Hn) = 3.
Plugging in the numbers:
)4(U0p
e
p
ef
4
4
3,2,1j j
j4
756.0882.0350
60
200
60
150
40
100
20
p
e
p
e
p
e
p
ef
4
4
3
3
2
2
1
14
36
Real-time Systems Lab, Computer Science and Engineering, ASU
Priority Inversion in Synchronization
1(H)B
2(M)
3(L)
Time
1 :{…P(S1)…V(S1)…}
3 :{…P(S1)…V(S1)…} S1 unlocked
Attempt to lock S1 (blocked) S1 locked
S1 unlockedS1 locked
37
Real-time Systems Lab, Computer Science and Engineering, ASU
Priority Inversion
Delay to a task’s execution caused by interference from lower priority tasks is known as priority inversion
Preemption is normal, but priority inversion should be avoided
Priority inversion is modeled by blocking time Identifying and evaluating the effect of sources of priority
inversion is important in schedulability analysis Sources of priority Inversion
Synchronization and mutual exclusion Non-preemtable regions of code FIFO (first-in-first-out) queues
38
Real-time Systems Lab, Computer Science and Engineering, ASU
Accounting for Priority Inversion
Recall that task schedulability is affected by preemption: two types of preemption
can occur several times per period can occur once per period
execution: once per period blocking: at most once per period for each source
The schedulability formulas are modified to add a “blocking” or “priority inversion” term to account for inversion effects
39
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test with Blocking
Include blocking while calculating effective utilization for each tasks:
Hn Preemption(can hit n times)
Execution
Blocking H1 Preemption(can hit once)
1n Hk
kii
i
i
i
Hj j
ji e
p
1
p
B
p
e
p
ef
40
Real-time Systems Lab, Computer Science and Engineering, ASU
RT Test with Blocking
Blocking is also included in the RT test
Perform test as before, including blocking effect
i
1jji0
j
1i
1j j
nii1n
eBa ere wh
ep
aeBa
41
Real-time Systems Lab, Computer Science and Engineering, ASU
Consider the following examplePeriodic tasks
What is the worst case blocking effect (priority inversion) experienced by each task ?
Example: Considering Blocking
25 msec
100 msec
50 msec
200 msec
100 msec
300 msec
10 msec
30 msec
Data Structure
1
2
3
42
Real-time Systems Lab, Computer Science and Engineering, ASU
Example: Adding Blocking
Task 2 does not use the data structure. Task 2 does experiences no priority inversion
Task 1 shares the data structure with 3 . Task 1 could have to wait for 3 to complete its critical section. But worse, if 2 preempts while 1 is waiting for the data structure, 1 could have to wait for 2’s entire computation.
This is the resulting tabletask Period Execution
TimePriority Blocking
delayDeadline
1100 25 High 30+50 100
2200 50 Medium 0 200
3300 100 Low 0 300
43
Real-time Systems Lab, Computer Science and Engineering, ASU
UB Test for Example
Recall UB test with blocking:
1n Hk
kii
i
i
i
Hj j
ji e
p
1
p
B
p
e
p
ef
00.105.1100
80
100
25
p
B
p
ef
1
1
1
11
)2(U5.0200
50
100
25
p
e
p
ef
2
2
1
12
)3(U84.0300
100
200
50
100
25
p
e
p
e
p
ef
3
3
2
2
1
13
Not schedulable
with additional RT test, 3 is shown to be schedulable
44
Real-time Systems Lab, Computer Science and Engineering, ASU
Nonpreemption Protocol
2:{…P(S1)…V(S1)…}
4:{…P(S1)…V(S1)…}
readyblocked
ready
ready
S1 locked S1 unlocked
Time
1(H)
4(L)
2
3
45
Real-time Systems Lab, Computer Science and Engineering, ASU
Basic Inheritance Protocol (BIP)
2:{…P(S1)…V(S1)…}
4:{…P(S1)…V(S1)…}
ready
ready
S1 locked S1 unlocked
1(H)
4(L)
2
3
blocked
attempts to lock S1
S1 unlockedS1 locked
ready
inherits the priority of 2
after 2 is blocked46
Real-time Systems Lab, Computer Science and Engineering, ASU
Highest Locker’s Priority Protocol
2:{…P(S1)…V(S1)…}
4:{…P(S1)…V(S1)…}
ready
ready
S1 locked S1 unlocked
1(H)
4(L)
2
3
BB
run with the priority of 2
47
Real-time Systems Lab, Computer Science and Engineering, ASU
Summary of Synchronization Protocols
1 Only if tasks do not suspend within critical sections2 PCP is not affected if tasks suspend within critical sections.
ProtocolBounded Priority
InversionBlocked at Most Once
Deadlock Avoidance
Nonpreemptible critical sections
Yes Yes1 Yes1
Highest locker's priority
Yes Yes1 Yes1
Basic inheritance Yes No No
48
Real-time Systems Lab, Computer Science and Engineering, ASU
Case Study
The target system responds to 6 events each event is processed by an ISR and an application routine ISRs are nonpreemption and set up event ready flags Main program checks ready flags in round-robin manner
if flag is set, calls the application routing
Main program
E1 E6E5E4E3E2
RTOS and ISRs
49
Real-time Systems Lab, Computer Science and Engineering, ASU
Scheduling Discipline
wait for signals
50
Real-time Systems Lab, Computer Science and Engineering, ASU
Task Data
The total utilization is only 55% in the worst-case
ei ea e p U
event 1 2.0 0.5 2.5 40 0.063
event 2 7.5 8.5 16 75 0.213
event 3 6.0 0.6 6.6 125 0.053
event 4 21.0 27.0 48.0 250 0.192
event 5 5.0 24.0 29.0 1050 0.028
event 6 3.0 1.0 4.0 4000 0.001
total 0.550
51
Real-time Systems Lab, Computer Science and Engineering, ASU
A Possible Scenario
Examine a possible scenario of event 1, 3 and 4 The main program just checked the flag for event 3
and then three interrupts arrives
0 40 80 120 160 200 240
0 125 250
0 250
event 1
event 4
event 3
miss deadline
52
Real-time Systems Lab, Computer Science and Engineering, ASU
Applying RMA in the Case Study
Event 4 application is schedulable (f4<69%)
Event Period Preempt{Hn} Execute Preempt
{H1}total(fi)
E1a 40 0.013
E2a 75 0.113
E3a 125 0.005
E4a 250 0.198 0.108 0.254 0.56
E5a 1050 0.023
E6a 4000 0.0003
56.0
250
35211240.68.50.5
250
27
125
6
75
7.5
40
2.0 a4E
53
Real-time Systems Lab, Computer Science and Engineering, ASU
Improving Response Times
Process events in RM order go back to the main loop after completing an application routine
Streamlined ISR move the work done in ISR to application routines
Preemptable services
Main program
E1 E6E3
RTOS and ISRs
E2 E5E4
54
Real-time Systems Lab, Computer Science and Engineering, ASU
Analysis After Improvements
Is it scheduable?
ei ea e p U
event 1 2.0 0.5 2.5 40 0.063
event 2 1.5 14.5(1.7) 16 75 0.213
event 3 6.0 0.6 6.6 125 0.053
event 4 6.5 41.5(4.5) 48 250 0.192
event 5 5.0 24(3.9) 29 1050 0.028
event 6 3.0 1.0 4.0 4000 0.001
total 0.550
609.075
0.355.60.65.15.4
75
5.14
40
5.2 f a2E 2a
55