CPU Reservations and Time Constraints:
Efficient, Predictable Scheduling of
Independent Activities
Michael B. Jones, Microsoft Research
Daniela Roşu, Georgia Tech
Marcel-Cătălin Roşu, Georgia Tech
Goal: Coexisting Independent
Real-time Applications


Independently developed
Predictable concurrent execution of


real-time and non-real-time apps
Meeting all apps’ timing needs

Informing apps when not possible
Teaser Capability

Apps can ask scheduler:


“Can I do 5ms of work between
now+30ms and now+40ms?”
Scheduler answers either:
“I guarantee it” or
 “You probably can’t”


Guaranteeing this 5ms work in future
10ms interval does not require reserving
50% of CPU for next 40ms
How did we do it?


Explicitly represent future time
Map app declarations of timing
needs into grants of future time
Enables:
 Advance guarantees to applications, or
 Denial of requests up front
Scheduling of Independently
Authored Applications


System support for adaptive apps
Apps requests based only on their
local properties
No inter-app coordination needed
 As opposed to priorities


Guarantees hold independent of
other activities’ behavior
Research Context

Rialto real-time operating system


Microsoft Interactive TV system


Research version of ITV kernel
Commercial trial in Yokosuka, Japan
Tiger Video Fileserver
Outline
Research Goals
Programming Model
Scheduling Architecture
How much does it cost?
What can it do?
Conclusions
Programming Model



Activities
CPU Reservations
Time Constraints
Abstraction: Activity



Resources allocated to, charged against
Each application typically a distinct
activity
Each thread belongs to an activity


Threads within activity assumed to
cooperate
Rialto kernel also uses activities
Abstraction: CPU Reservation

Guaranteed execution rate and
granularity for an activity


X units of time out of every Y units, e.g.
 800µs every 5ms
 7.5ms every 33.3ms
 one second every minute
Continuously guaranteed
% Frames Rendered
Sensitivity to Reservation
Amount and Period
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
0
10
20
30
40
Reservation Period (ms)
20% Res
15% Res
50
10% Res
AVI player, 89% combined reservations for
player and background load activity
60
Abstraction: Time Constraint

Deadline-based thread execution
Guarantees execution within interval, or
 Proactively denies constraint request

schedulable = BeginConstraint (time_interval, estimate);
if (schedulable) then
Do normal work under constraint
else
Transient overload -- shed load if possible
time_taken = EndConstraint ();
Example: CPU Reservation &
Time Constraints
Time
with reservations
Time
with reservations
and constraints
Activities:
Start Time:
Deadline:
Estimate:
Example: Time Constraints &
no CPU Reservations
Time
with reservations
Time
with reservations
and constraints
Activities:
Start Time:
Deadline:
Estimate:
Related Work
Two classes of related work
 Those using virtual time


Goyal et al., Stoica et al., Mercer et al.,
Nieh & Lam
Those using real time

Schwan & Zhou, Maruti project at UMD
Our system
 Uses compact representation of real time:

Precomputed Scheduling Plan
Outline
Research Goals
Programming Model
Scheduling Architecture
How much does it cost?
What can it do?
Conclusions
Key Insight

Precomputed Scheduling Plan


Allocation of future time intervals to
 Activities: for CPU Reservations
 Threads: for Time Constraints
Enables efficient:
Scheduling decisions
 Feasibility analysis for constraints
 Guarantees for reservations, constraints

Scheduling Plan Example
4: A
3: B
1: E
2: free
2: C
3: free
1: D
5: F
B
C
D
E
F
Activity A
Amount 4ms 3ms 2ms 1ms 1ms 5ms
Period 20ms 10ms 40ms 20ms 10ms 40ms
Scheduling Graph Construction


Occurs only when reservations change
Goals
Minimize context switches
 Maximize execution intervals
 Distribute free nodes evenly over time
 Account for context switch time


Quick, non-optimal solution to NPhard problem
Constraint Feasibility
Analysis

Feasibility Analysis
First considers activity reservation nodes
 Then considers free graph nodes



Infeasible constraints denied
Feasible constraints accepted and
guaranteed

Time intervals in graph are assigned to
their execution
EDF Constraint Execution

Constraints executed in EDF order


During the intervals assigned to
constraints
Improves cache locality

Eliminates timeslicing among constraints
Additional Goals


Fair sharing of free CPU among activities
Fair sharing of CPU among threads within
same activity


Unless threads use constraints or
synchronization objects
Best effort to:
finish underestimated constraints
 expedite denied constraints

Next Thread Selection
1. If time remaining within node below
threshold, select next node
2. If during assigned time interval,
execute constraint EDF
3. If reserved node, select best thread
within activity (default round-robin)
4. Select best activity (default roundrobin), and thread within it
Outline
Research Goals
Programming Model
Scheduling Architecture
How much does it cost?
What can it do?
Conclusions
Micro-benchmark Times
On 200MHz Pentium Pro PC:
 21.2µs Context switch time
 32µs (10µs + 22µs trap) Atomic
EndConstraint()/BeginConstraint()
 CPU reservation operations:
150µs (19µs + 131µs RPC) Incr. Add()
 98µs (11µs + 87µs RPC) Release()

Cost of Scheduling Plan Changes
Reasonable even in pathological cases
3
2
1
56
51
46
41
36
31
26
21
16
11
6
0
1
Time to Make
Reservation (ms)
4
Reservation Number
Time fully reserved - 58 activities, each reserving 400µs per:
1s, 1s, 500ms, 1s, 500ms, 250ms, 1s, 500ms, 250ms, 125ms,
Costs of Feasibility Analysis
Feasibility Analysis
(µs)
Reasonable even in pathological cases
140
120
100
80
60
40
20
0
0
40
80
120
160
200
240
Time Constraint Request
No Reservations
With Reservations
Same 58 simultaneous activities, 4 threads each
Threads request 300µs within 3s in future
Outline
Research Goals
Programming Model
Scheduling Architecture
How much does it cost?
What can it do?
Conclusions
Achieving Bounded Response:
Time Constraints against Time Sharing
Time to Finish Work (ms)
Desired responsiveness achieved under load
800
700
600
500
400
300
200
100
0
0
1
2
3
4
5
6
# of Competing Activities
7
8
Work w ith no reservations or constraints
Work w ith 50ms/200ms constraints
Time to complete 50ms of work, no reservations
Achieving Bounded Response:
Constraints & Reservations against Reservations
Time to Finish Work (ms)
Bounded response achieved with reservation
1400
1200
1000
800
600
400
200
0
0
1
2
3
4
5
6
# of Competing Activities
7
8
Work w ith 50ms/200ms constraints but no reservation
Work w ith 50ms/200ms constraints & 10% reservation
Time to complete 50ms work with constraints,
competing activities with 10% reservations
Adding Reservations to Existing Apps
100%
80%
60%
Round-robin
scheduler
40%
20%
Rialto
Scheduler
I5
AV
I4
AV
I3
AV
I2
AV
I1
AV
EG
0%
M
P
% Frames Rendered
CPU reservations improve performance
Application
1 MPEG & 5 AVI players, w/ reservations on Rialto
Conclusions

Precomputed scheduling plans enable
efficient implementation of:
Continuously guaranteed CPU reservations
 Time constraints with accurate a priori
feasibility analysis



Abstractions support incremental
development, co-existence of independent
real-time applications
General-purpose OSs can provide
practical, efficient, real-time services
Acknowledgments



OS Research Group at
Microsoft Research
Microsoft Interactive TV Team
Kevin Jeffay, Karsten Schwan,
Patricia Jones, Susan Owicki,
George Candea, Jason Nieh
For More Information
SOSP ’97 CD includes simulator used to
develop algorithms
Also see
http://research.microsoft.com/~mbj/
http://www.cc.gatech.edu/~daniela/
http://www.cc.gatech.edu/~rosu/