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

What did we build? Algorithms enabling practical, predictable execution of multiple real-time and non-real-time apps System implementing these algorithms

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 cant 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 Research version of ITV kernel Microsoft Interactive TV system 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

Sensitivity to Reservation Amount and Period AVI player, 89% combined reservations for player and background load activity

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 Activities:Estimate: Time with reservations and constraints Start Time:Deadline:

Example: Time Constraints & no CPU Reservations Activities:Estimate: Time with reservations Start Time:Deadline: with reservations and constraints

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

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 NP- hard 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 round- robin), and thread within it

Thread Selection Within Activity Selected in order: 1.Threads w/ pending denied constraints 2.Threads w/ late constraints 3.Round-robin among runnable threads Note: Only applies when time interval not assigned for time constraint execution

Outline 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 Times

On 200MHz Pentium Pro PC: 21.2µs median context switch time Compare w/ 8.75µs NT4, 239µs deployed ITV kernel 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 Times

Cost of Scheduling Plan Changes Time fully reserved - 58 activities, each reserving 400µs per: 1s, 1s, 500ms, 1s, 500ms, 250ms, 1s, 500ms, 250ms, 125ms, … Reasonable even in pathological cases

Costs of Feasibility Analysis Same 58 simultaneous activities, 4 threads each Threads request 300µs within 3s in future Reasonable even in pathological cases

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 complete 50ms of work, no reservations Desired responsiveness achieved under load

Achieving Bounded Response: Constraints & Reservations against Reservations Time to complete 50ms work with constraints, competing activities with 10% reservations Bounded response achieved with reservation

Adding Reservations to Existing Apps 1 MPEG & 5 AVI players, w/ reservations on Rialto CPU reservations improve performance

Outline Research Goals Programming Model Scheduling Architecture How much does it cost? What can it do? Conclusions

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