The problem
Platform 1
New platform
A
A
B
Giorgio Buttazzo
Platform 2
g.buttazzo@sssup.it
B
Consider two applications, A and B, independently
developed on dedicated platforms.
How can we guarantee them when they are
concurrently executed in the same platform?
Scuola Superiore Sant’Anna
Example with fixed priorities
RM schedule (S = 1)
A
3 (2,5)
2 (4,8)
4 (6,12)
0
4
8
A
5
0
1 (4,8)
2 (2,12)
10
B
4
3 (1,5)
8
5
2 (2,8)
10
s
4 (3,12)
A
UB 
2 5
17


 1
3 18 18
16
overrun
2 (2,12)
deadline
miss
12
16
B
deadline miss
5
18
1 (4,8)
3 (5,18)
0
0
3 (5,18)
EDF schedule
A+B
15
8
B
1 1 2
 
2 6 3
Ci
16
12
Application B
U TOT 
1 (1,4)
A
UA 
12
RM schedule (S = 2)  assuming C’i =
A+B
Application A
RM schedule (S = 1)
B
1 (2,4)
Example with EDF
2
4
6
8
10
12
14
16
18
20
12
© Scuola Superiore Sant’Anna
3
Resource partitioning
© Scuola Superiore Sant’Anna
4
Resource Reservation
In general, what we really need is to have:
Clearly, when multiple applications execute
on the same platform, they compete for the
same resources and may delay each others.
A
4
Each application receives a fraction i < 1
of the processor sufficient to meet its
execution requirements.
B
What we need is a mechanism able to partition the processor
in two subsystems (virtual processors), each dedicated to a
single application.
In this way, an overrun occurring in an
application does not propagate to the others,
but only affects the application itself.
10 %
Resource partitioning
V1
A
V2
B
3
45 %
20 %
1
2
25 %
Enforcement mechanism
A mechanism that prevents an application
to consume more than its reserved
fraction.
In this way, the application executes as it
were executing alone on a slower
processor with speed i.
1
Priorities vs. Reservations
Prioritized
Access
Resource
Reservation
A1
A2
A3
P1
READY QUEUE
Priorities vs. Reservations
A1 A2 A3
P2
1
2
3
Prioritized
Access
P3
A1
1 = 0.5
50%
A1
A2
2 = 0.3
30%
A2
3 = 0.2
20%
A3
A3
Priorities vs. Reservations
Tasks  vehicles
Resource  road
Resource
Reservation
1
50%
2
3
30%
20%
Prioritized approach
Problems in overload conditions
High priority
Medium priority
Low priority
Shared resource
Resource Reservation
Each type of vehicle has a reserved lane
service
lane
car
lane
Benefits of Res. Reservation
1. Resource allocation is easier than priority mapping.
2. It provides temporal isolation: overruns occurring in
a reservation do not affect other tasks in the
system.
 Important for modularity and scalability
3. Simpler schedulability analysis:
truck
lane
 Response times only depends on the application
demand and the amount of reserved resource.
4. Easier probabilistic approach
2
Implementing Reservations
1
server
2b
server
2a
3
server
Fixed priorities
Dynamic priorities
Guaranteeing Reservations
1
1
2
3
server
2b
Ready queue
server
2a
CPU
3
scheduler
scheduler
server
RM/DM
Sporadic Server
EDF
CBS
server
1
Ready queue
2
CPU
3
scheduler
If a processor is partitioned into n reservations, we
n
must have that:

i 1
i
A
 U lub
where A is the adopted scheduling algorithm.
Hard vs. Soft reservations
Constant Bandwidth Server
SOFT reservation
 It assigns deadlines to tasks as the TBS, but keeps track
of job executions through a budget mechanism.
It guarantees that the served application receives
at least a budget Q every P.
 When the budget is exhausted it is immediately
replenished, but the deadline is postponed to keep the
demand constant.
CBS parameters
HARD reservation
It guarantees that the served application receives
at most a budget Q every P.
Maximum budget: Qs
Server period:
Ts
Server bandwidth: Us = Qs/Ts
assigned
by the user
Current budget:
Server deadline:
maintained
by the server
qs (initialized to 0)
ds (initialized to 0)
16
Basic CBS rules
Example of Soft CBS
Arrival of job Jk at time rk  assign ds
1
if (rk + qs /Us  ds) then recycle (qs, ds)
else
ds = rk + Ts
q s = Qs
Budget exhausted
ds = ds + Ts
q s = Qs
8
4
0
12
16
24
20
2
0
16
d1
d0
6
ape
r1
qs
 postpone ds
The server
remains active
0
2
d2
d3
d4
14
20
26
1
r1
4
6
8
8
10
12
14
16
18
20
22
24
26
CBS: Qs = 2, Ts = 6
17
18
3
Problem of Soft CBS
Example with Hard CBS
If more bandwidth is allocated during idle intervals, the server
deadline goes far away (deadline aging) and the executions
tend to become less regular.
The deadline aging problem can be avoided by suspending the
server when qs = 0 and recharging the budget at ds:
1
1
16
16
0
4
8
12
16
20
24
0
4
8
12
16
20
24
d0
d1
d2
d3
d4
d5
d6
d0
d1
d2
d3
d4
d5
d6
s
5
1
4
qs
0
2
4
1
8
6
8
1
16
12
10
12
14
16
20
18
s
1
20
24
22
24
5
1
26
8
4
qs
0
2
4
1
6
CBS: Qs = 1, Ts = 4
8
1
16
12
10
12
1
14
16
20
18
20
24
22
24
Hierarchical scheduling
Resource reservation can be used to develop
hierarchical systems, where each component is
implemented within a reservation:
28
20
Hierarchical scheduling
In general, a component can also be divided in other
sub-components
Application N
Application 1
Local Scheduler
Local Scheduler
Local Scheduler
  
Component N
Local Scheduler
Component 1
Global Scheduler
Global Scheduler
Computing Platform
Global scheduler: the one managing the system ready queue
Local schedulers: the ones managing the servers queues
Server S4
Local Scheduler
Local Scheduler
  
Computing Platform
Hierarchical scheduling
Component N
Hierarchical Analysis
Global analysis: Servers must be schedulable by the global
scheduler running on the physical platform.
Local analysis: Applications must be scheduled by the local
schedulers running on the components.
Server S1
Application N
Application 1
9 8
26
CBS: Qs = 1, Ts = 4
19
Component 1
28
3 2 1
  
Local scheduler
Local scheduler
Local Scheduler
Component 1
S4 S3 S2 S1
Local Scheduler
  
Component N
CPU
Global Scheduler
Global scheduler
Computing Platform
4
Analysis under RR
Analysis under RR
Under EDF, the analysis of an application within a
reservation is done through the Processor Demand
Criterion:
To describe the time available in a reservation, we
need to identify, for any interval [0, t], the minimum
time allocated in the worst-case situation.
Under Fixed Priority Systems (FPS), the analysis is
done through the Workload Analysis:
Supply bound function sbf(t):
t  0,
dbf (t )  t
 t  (0, Di ] : Wi (t )  t
i  1,..., n
minimum amount of time available in reservation
Rk in every time interval of length t.
The difference is that in an interval of length t the
processor is only partially available.
Example: Static time partition
Analysis under RR
Example of reservation providing 4 units every 10
(bandwidth = 0.4).
Hence the Processor Demand Criterion can be
reformulated as follows:
t  0,
0
2
4
6
8
10
12
14
16
18
20
22
dbf (t )  sbf (t )
t
24
sbf(t)
sbf(t)
t
8
dbf(t)
4
0
2
4
6
8
10
12
14
16
18
20
t
t
Analysis under RR
Supply bound function
A simpler sufficient test, can be derived by replacing
sbf(t) with a lower bound, called linear supply bound
function lsbf(t):
t  0,
A linear supply bound function has the following form:
lsbf (t )  max{0,  (t   )}
dbf (t )  lsbf (t )
t
sbf(t)
lsbf(t)
lsbf(t)

dbf(t)
t
 = bandwidth
 = service delay

t
5
Deriving  and 
Deriving  and 
Given a generic supply function sbf(t), the bandwidth
 is the equivalent slope computed for long
intervals:
sbf (t )
  lim
t 
t
While the delay  is the highest intersection with the
time axis of the line of slope  touching the sbf(t):
 sbf (t ) 
  sup t 

 
t 0 
sbf(t)
sbf(t)
sbf(t)



sbf(t)
t

Example: Periodic Server
Example: Periodic Server
For a periodic server with budget Qs and period Ps
running at the highest priority, we have:
Qs
Ps
 
Ps
Qs
For a periodic server with budget Qs and period Ps
running at unknown priority, we have:
  Ps  Qs
Ps
sbf(t)
Qs
Qs
Ps – Qs
Qs
Ps
  2( Ps  Qs )
2(Ps – Qs)
Observation
Observation
In a periodic server with bandwidth , we have that:
It is worth comparing the following supply functions:
Supply function
of a fluid partition
with bandwidth 
Supply function of a real
partition with bandwidth 
of a periodic server Q,P
Q  P
  2( P  Q)  2 P (1   )
t
The delay  is proportional
to the server period P
t




 
Qs
sbf(t)
Supply
function of a
full processor
t
t

t

t
6
Observation
Taking overhead into account
Note that, for a given bandwidth , reducing P
reduces the delay  and improves schedulability,
tending to a fluid reservation, but …
smaller periods generates
higher runtime overhead
If  is the context switch overhead, we have:
P
Q

smaller P
Allocated bandwidth:
 
Effective bandwidth:
 eff
 eff  0
Pmin 
Q
  2 P (1   )
P
Q 


 
P
P
1 
 min  2 Pmin (1   )  2 

  


t
Effective bandwidth
Reservation interface
Hence reducing the server period P reduces the delay
, but also reduces the effective bandwidth eff that
can be exploited:
Note that the (, ) parameters offer an alternative
interface, which is independent of the implementation
mechanism (static partitions or Q-P server):
eff
1

2
3
/
QoS1
2
2
QoS2
3
3
QoS3
Example of sporadic waste
service
lane
truck
lane
1
P
Avoiding resource wastes
car
lane
1
demanded
bandwidth
allocated
bandwidth
avg
A reservation can be wasted because of
time
 occasional load reduction due to early terminations
 wrong bandwidth allocation at design time
 application changes due to environmental changes
under utilized
correctly utilized
over utilized
7
Bandwidth allocation error
Resource Reclaiming
Unused bandwidth in a reservation can be used to
satisfy extra occasional needs in another reservation:
Bandwidth
Demanded
Allocated


allocation error
Bandwidth
Bandwidth
Resource is insufficient
(application is delayed)
bandwidth
allocation
error
R1
time
R2
The application
demands less
(resource is wasted)
Budget reclaiming
1
2
3
2
3
2
4
1
2
4
Capacity Sharing algorithm
3
1
1
2
3
2
3
2
1
4
2
5
3
3
CASH: Capacity Sharing algorithm
 When a job finishes and qs > 0, the residual budget is put in
a global queue of spare capacities (the CASH queue), with
a deadline equal to the server deadline.
 A server first uses the capacity in the CASH queue with the
earliest deadline dq  ds, otherwise qs is used.
 Idle times consume the capacity in the CASH queue with
the earliest deadline.
3
3
CASH queue Handling wrong allocations
There are situations in which the reservation error is
caused by a wrong bandwidth allocation:
2
2
1
4
2
3
5
1
1
3
2
1
Need for adaptivity
In these cases, the only solution is to design the
system to be adaptive so that reservations can be
changed based on runtime requirements:
any reservation is not appropriate
resource
needs
safe but
not efficient
resource
needs
efficient but
not enough
time
time
8
Adaptive QoS Management
Reservation parameters can be changed at run time
by a Reservation Manager (Global adaptation):
Local adaptation
A local adaptation approach is also possible for a task
to comply with the assigned reservation:
demand
i
Reservation Manager
Ci
1
2
3
1
1
QoS1
2
2
QoS2
3
3
QoS3
Ti
Reservation
Si

Local Policy
Real-Time
System

probes
Shared Resources
1
server
2b
R
server
2a
3
server
2
3
Ready queue
CPU
scheduler
Tasks are usually not independent as they share
resources (e.g., data structures, peripherals,
common memory areas).
Problems with Reservations
 Resource sharing may break isolation:
Problems with Reservations
 Resource sharing may break isolation:
The major problem is that
the resource is locked but
no task is actually using it
normal blocking due extra blocking due to
to reasource sharing budget exhaustion
deadline miss
1
wait
2
deadline miss
1
wait
2
Ts
Ts
server
server
S2
S2
9
Possible approaches
Reactive approaches
Let the budget finishes and react with a given strategy:
Overrun without Payback
When the budget exhausts inside a critical section, do
nothing.
 Overrun
Isolation is broken!
 Without payback
 With payback
 Proxy execution (BWI)
1
Proactive approaches
2
Prevent the budget to finish inside a critical section:
 Check and wait (SIRAP)
 Check and recharge (BROE)
wait
Ts
server
S2
The budget goes negative
Overrun without Payback
Let k be the length of the critical section to be entered.
In the worst-case the server consumes Qs +k budget units
Overrun with Payback
When the budget exhausts inside a critical section, do
nothing. Payback at the next budget replenishment.
Isolation is broken!
Note that the worst-case bandwidth consumption does not change
wait
2
k
1
2
wait
Ts
Ts
server
server
S2
S2
k
The budget goes negative
Proxy Execution
When the budget exhausts inside a critical section, inherit the
bandwidth of another server
1
wait
2
1
Budget payback
Proactive Approaches
 Let k be the length of the critical section to be entered,
and qs be the budget of the server at the lock time;
 Proactive approaches are based on a budget check
before locking the resource (i.e., qs  k ?);
 The scheduler requires the knowledge of k at run-time.
server
S1
2
qs  k ? NO
qs  k ? YES
Ts
server
S2
10
SIRAP
SIRAP
If (qs  k) then enter, else wait for the next replenishment.
 Penalizes the response-time of the task wishing
to access the resource;
Check and wait
Note that off-line we must guarantee that Qs  max{k}.
1
checking point
 Potentially inserts idle-time (unused budget).
1
2
checking point
2
Ts
Ts
server
server
S2
S2
BROE
BROE
Check and recharge
 Performs better than SIRAP in most situations;
If (qs  k) then enter, else recharge the budget at full value
and proportionally postpone the server deadline.
Note that off-line we must guarantee that Qs  max{k}.
1
checking point
 BROE works only with EDF-scheduled reservation
servers.
1
2
2
server
server
S2
S2
checking point
BROE
BROE
 BROE is designed to guarantee a bounded-delay
partition (, ).
Note that a deadline shift of X/ guarantees that the
server never consumes a bandwidth higher than ,
provided that
 A budget recharge of X time units reflects as a
proportional deadline shift of X/
Ts
S2
j i
In fact, since D 
2
server
i   j  1
X/
Q

The deadline increment D that guarantees a bandwidth 
with a budget (Q + x) can be found by imposing:
Qx

D  D
thus:
D  D 
Qx

D
Q


x


x

11
BROE
BROE: bandwidth guarantee
BROE Design Goals
Overcome to the problem of budget depletion inside
critical sections
 Avoiding budget overruns;
 Ensuring bandwidth isolation (i.e., each server
of the processor
must consume no more than
bandwidth);
 Guaranteeing a bounded-delay partition to the
served tasks.
 When the budget is not enough to complete the
critical section, BROE performs a full budget
replenishment;
 To contain the server bandwidth, the budget
replenishment must be reflected in a proportional
deadline postponement
 To bound the service delay, the server must be
suspended until a proper time.
BROE: bounded-delay
 To guarantee real-time workload executing upon a
reservation server, the server must ensure a
bounded-delay service
∆
BROE: bounded-delay
 The budget replenishment and the corresponding
deadline postponement can easily result in a
violation of the worst-case delay ∆ 2
, if
not properly handled!
2
BROE: bounded-delay
 Consider a BROE server with Q=4 and P=8

accesses a resource having
2
BROE: bounded-delay
 Consider a BROE server with Q=4 and P=8

1
1
server
server
accesses a resource having
2
12
BROE: bounded-delay
 Consider a BROE server with Q=4 and P=8

2
accesses a resource having
 The worst-case delay ∆
2
is violated!
BROE: bounded-delay
 How to solve this problem?
 The idea is to prevent the server to execute “too
earlier” with respect to its deadline, after a budget
replenishment
The worst‐case the delay can be potentially unbounded!
11
1
2
8
8
11
8
server
1
2
8
8
8
server
BROE: bounded-delay
 If the server is “not executing too earlier”, it is not
possible to violate the worst-case delay ∆
BROE: bounded-delay
 For how long the server must be suspended?
Depending on the execution state, BROE decides to suspend the server or not
no server suspension
is needed
This execution
must be delayed
6
∆
2
1
1
server
server
BROE: bounded-delay
How to compute time tr such that the bandwidth in [tr, d] is
exactly ?
q (t )

d  tr
explicit server
suspension
1
server
d - tr
tr
tr  d 
tr  8 
d
The slack is greater than (P-Q)
=8
8
8
BROE: bounded-delay
How to compute time tr such that the bandwidth in [tr, d] is
exactly ?
q (t )

d  tr
q(t )

1
6
0.5
explicit server
suspension
1
d - tr
tr
tr  d 
q(t )

P
d
server
13
BROE: bounded-delay
Note that, thanks to the suspension, the worst-case service
delay is still  = 2(P - Q):
BROE: goals
BROE Design Goals
Overcome to the problem of budget depletion inside
critical sections
• Avoiding budget overruns;
• Ensuring bandwidth isolation (i.e., each server
of the processor
must consume no more than
bandwidth);
explicit server
suspension
∆
1
2
8
8
• Guaranteeing a bounded-delay partition to the
served tasks.
server
BROE: rules
BROE Resource Access Policy
Consider a BROE server having budget Q and period P. The
current budget at time t is denoted as q(t).
of length k at time t:
When a task wishes to access a resource
 if
, enter the critical section (there is enough budget);
 else compute a recharging time
 If
, the server is suspended until time , the budget is
replenished to Q and the deadline is shifted to
BROE: constraints
 The BROE resource access policy can work only with EDF
due to the proportional deadline shift. The support for FP is
currently an open problem;
 To perform the budget check, BROE requires the
specification of the worst-case holding time for the shared
resources;
 BROE is intrinsically designed for the worst-case: the
budget check can cause a scheduling decision that could be
unnecessary.
 Otherwise, the budget is immediately replenished to Q and
BROE: recap
 The BROE server is a scheduling mechanism providing
resource reservation including the support for shared
resources

Hard reservation implementing the Hard-CBS algorithm;

Resource access protocol that guarantees both bandwidth
isolation and bounded-delay to the served application.
Resource Holding Time
 In general, the BROE budget check has to be performed
using the Resource Holding Time (RHT) of a shared
resource;
 RHT = budget consumed from the lock of a resource until its
unlock
14
Resource Holding Time
Resource Holding Time
 In general, the BROE budget check has to be performed
using the Resource Holding Time (RHT) of a shared
resource;
 Interference from high-priority task has to be accounted in
the budget consumed when a resource is locked
 RHT = budget consumed from the lock of a resource until its
unlock
2
s
2
s
lock
unlock
lock
1
unlock
1
server
budget
RHT
Resource Holding Time
Resource Holding Time
 RHT = Critical Section WCET + Worst-case Interference
 The interference is caused by the task preemptions
 If resources are accessed in a non-preemptive manner, the
RHT is equal to the worst-case critical section length;
 Trade-off: lower threshold for the budget check, but greater
task blocking due to non-preemptive blocking
non-preemptive blocking
2
s
2
lock
s
unlock
1
RHT
unlock
RHT
BROE: example
Consider 2 BROE servers: (Q1 = 4, P1 = 8)
Implementation Issues
(Q2 = 5, P2 = 10)
2
t r  20 
 16
0.5
2
tr  8 
4
0.5
1
lock
1
 Goal: Implementation of a two-level Hierarchical Scheduling
Framework using the BROE algorithm.
S1
0
2
4
6
t r  10 
8
10
12
14
16
18
20
22
24
26
2
6
0.5
2
Server scheduling according to EDF
S2
0
2
4
6
8
10
12
14
16
18
20
22
24
26
15
Implementation Issues
Implementation Issues
 Goal: Implementation of a two-level Hierarchical Scheduling
Framework using the BROE algorithm.
 Goal: Implementation of a two-level Hierarchical Scheduling
Framework using the BROE algorithm.
BROE Server: Hard‐CBS + resource access policy
Local scheduler: can be either EDF and FP
Implementation Issues
 Multi-layer scheduling infrastructure
Task
Task
Task
Implementation Issues
 Ready queue structure
Task
VCPU 1
TASK 1.1
TASK 1.2
TASK 1.3
VCPU 2
TASK 2.1
TASK 2.2
EDF
order
VCPU 3
TASK 3.1
VCPU n
TASK n.1
Classical Resource Sharing
EDF/FP Scheduler
BROE Resource Access Policy
Hard CBS
EDF Scheduler
EDF
order
TASK n.2
TASK 1.4
FP
order
TASK n.3
CPU
Implementation Issues
 OS with tick: the kernel comes into operation periodically,
even if there are no scheduling events to be handled;
 OS tick-less: the kernel come into operation only when is
needed, i.e., in correspondence of scheduling events.
Implementation Issues
 EDF scheduling implementation needs a timing reference
having both
 High-resolution;
 Long life-time (to handle absolute deadlines).
 Example: budget management for reservation
It Requires 64‐bit data structure for time representation
 We look at tick-less RTOS implementation on small
microcontrollers.
 Dealing with 64-bit data structures in small microcontrollers
imposes a significant overhead in the scheduler
implementation.
16
Implementation Issues
Implementation Issues
 Circular timer: avoid an absolute timing reference. The
notion of time is relative with respect to a free running timer.
 Let T the lifetime of the free running timer.
 It is possible to handle temporal events having a maximum
spread of T/2.
 Consider two events
and
.
be the absolute time of an event, and
 Let
relative representation by using the circular timer.
 To compare two events having

If
0 then

If
0 then

If
Implementation Issues
its
/2
0 then
Implementation Issues
 Warning: a relative representation becomes inconsistent
after T/2!
 Hard-CBS Server: its implementation requires to manage
two main operations
 Inactive servers: It is necessary to perform a periodic check
of inconsistent deadlines;
 Budget enforcement;
 Budget recharge.
 A special timer has to be reserved for that job.
5
The implementation of EDF requires 2 timers:
• Free running timer
• Periodic timer for deadline consistency
server
8
4
qs
0
2
Implementation Issues
4
6
8
16
12
10
12
14
16
20
18
20
24
22
24
26
Implementation Issues
 Budget enforcement: when then server starts to execute at
time , set up an one-shot timer with the current budget
.
 If a preemption occurs, the timer is reconfigured; otherwise,
it will fire to notify a budget exhaustion.
 Budget recharge: when a server exhaust its budget, it has
to be suspended until its deadline, where the budget will be
recharged.
 A deadline-ordered queue of suspended server has to be
provided. Another one-shot timer triggers the budget
recharge event for the first server in the queue.
5
5
server
server
8
4
qs
0
2
4
6
8
16
12
10
12
14
16
20
18
20
24
22
24
26
8
4
qs
0
2
4
6
8
16
12
10
12
14
16
20
18
20
24
22
24
26
17
Implementation Issues
 Budget recharge: when a server exhaust its budget, it has
to be suspended until its deadline, where the budget will be
recharged.
 A deadline-ordered queue of suspended server has to be
provided. Another one-shot timer triggers the budget
recharge event for the first server in the queue.
One‐Shot Timer d=10
VCPU 1
d=10
VCPU 3
d=40
VCPU 6
d=120
Queue of suspended servers
waiting for budget replenishment
Implementation Issues
 Hard-CBS Server: its implementation requires to manage
two main operations
 Budget enforcement;
 Budget recharge.
The implementation of the Hard CBS requires 2 timers:
• One‐shot timer for budget enforcement
• One‐shot timer for budget recharge
Implementation Issues
 BROE server suspension: can be implemented exploiting
the budget recharge queue
 “If
One‐Shot Timer d=10
, the server is suspended until time
VCPU 1
d=10
VCPU 3
d=40
”
VCPU 6
d=120
Queue of suspended servers
waiting for budget replenishment
Implementation Issues
 BROE server suspension: can be implemented exploiting
the budget recharge queue
 “If
One‐Shot Timer d=10
, the server is suspended until time
VCPU 1
d=10
VCPU 3
d=40
”
VCPU 2
=50
VCPU 6
d=120
Queue of suspended servers
waiting for budget replenishment
18