CPU Reservations and Time Constraints:CPU Reservations and Time Constraints:Efficient, Predictable Scheduling of Efficient, Predictable Scheduling of

Independent ActivitiesIndependent Activities

Michael B. Jones, Microsoft Research

Daniela Roşu, Georgia Tech

Marcel-Cătălin Roşu, Georgia Tech

Goal: Coexisting Independent Goal: Coexisting Independent Real-time ApplicationsReal-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 CapabilityTeaser Capability Apps can ask scheduler:

“Can I do 5ms of work betweennow+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?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 Scheduling of Independently Authored ApplicationsAuthored 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 ContextResearch Context

Rialto real-time operating system Research version of ITV kernel

Microsoft Interactive TV system Commercial trial in Yokosuka, Japan

Tiger Video Fileserver

OutlineOutline

Research Goals

Programming ModelScheduling Architecture

How much does it cost?

What can it do?

Conclusions

Programming ModelProgramming Model

Activities CPU Reservations Time Constraints

Abstraction: ActivityAbstraction: 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 ReservationAbstraction: 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

Sensitivity to Reservation Sensitivity to Reservation Amount Amount andand Period Period

0%10%20%30%40%50%60%70%80%90%

100%

0 10 20 30 40 50 60

Reservation Period (ms)

% F

ram

es R

ende

red

20% Res 15% Res 10% Res

AVI player, 89% combined reservations for player and background load activity

Abstraction: Time ConstraintAbstraction: 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 constraintelse

Transient overload -- shed load if possibletime_taken = EndConstraint ();

Example: CPU Reservation &Example: CPU Reservation &Time ConstraintsTime Constraints

Activities: Estimate:

Time

Time

with reservations

with reservationsand constraints

Start Time: Deadline:

Example: Time Constraints & Example: Time Constraints & nono CPU Reservations CPU Reservations

Activities: Estimate:

Time

Time

with reservations

Start Time: Deadline:

with reservationsand constraints

Related WorkRelated WorkTwo 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

OutlineOutline

Research Goals

Programming Model

Scheduling ArchitectureHow much does it cost?

What can it do?

Conclusions

Key InsightKey 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 ExampleScheduling Plan Example

Activity A B C D E FAmount 4ms 3ms 2ms 1ms 1ms 5msPeriod 20ms 10ms 40ms 20ms 10ms 40ms

3: B 1: E

4: A 2: free

1: D

3: free2: C

5: F

Scheduling Graph ConstructionScheduling 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 NP-hard problem

Constraint Feasibility Constraint Feasibility AnalysisAnalysis

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 ExecutionEDF Constraint Execution

Constraints executed in EDF order During the intervals assigned to

constraints Improves cache locality

Eliminates timeslicing among constraints

Additional GoalsAdditional 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 SelectionNext 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 round-robin), and thread within it

OutlineOutline

Research Goals

Programming Model

Scheduling Architecture

How much does it cost?What can it do?

Conclusions

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

Micro-benchmark TimesMicro-benchmark Times

Cost of Scheduling Plan ChangesCost of Scheduling Plan Changes

Time fully reserved - 58 activities, each reserving 400µs per:

1s, 1s, 500ms, 1s, 500ms, 250ms, 1s, 500ms, 250ms, 125ms, …

0

1

2

3

41 6 11 16 21 26 31 36 41 46 51 56

Reservation Number

Tim

e to

Mak

e R

eser

vatio

n (m

s)Reasonable even in pathological cases

Costs of Feasibility AnalysisCosts of Feasibility Analysis

Same 58 simultaneous activities, 4 threads each

Threads request 300µs within 3s in future

020406080

100120140

0 40 80 120 160 200 240

Time Constraint Request

Fea

sibi

lity

Ana

lysi

s (µ

s)

No Reservations With Reservations

Reasonable even in pathological cases

OutlineOutline

Research Goals

Programming Model

Scheduling Architecture

How much does it cost?

What can it do?Conclusions

Achieving Bounded Response:Achieving Bounded Response: Time Constraints against Time SharingTime Constraints against Time Sharing

0100200300400500600700800

0 1 2 3 4 5 6 7 8

# of Competing Activities

Tim

e t

o F

inis

h W

ork

(m

s)

Work w ith no reservations or constraints

Work w ith 50ms/200ms constraints

Time to complete 50ms of work, no reservations

Desired responsiveness achieved under load

Achieving Bounded Response: Achieving Bounded Response: Constraints & Reservations against ReservationsConstraints & Reservations against Reservations

0200400600800

100012001400

0 1 2 3 4 5 6 7 8

# of Competing Activities

Tim

e to

Fin

ish

Wor

k (m

s)

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

Bounded response achieved with reservation

Adding Reservations to Existing AppsAdding Reservations to Existing Apps

0%

20%

40%

60%

80%

100%

Application

% F

ram

es R

ende

red

Round-robinscheduler

RialtoScheduler

1 MPEG & 5 AVI players, w/ reservations on Rialto

CPU reservations improve performance

ConclusionsConclusions 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

AcknowledgmentsAcknowledgments

OS Research Group at Microsoft Research

Microsoft Interactive TV Team Kevin Jeffay, Karsten Schwan,

Patricia Jones, Susan Owicki, George Candea, Jason Nieh

For More InformationFor 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/