1. 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

2. 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

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

4. 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

5. 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

6. 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

7. Research Context Rialto real-time operating system Research version of ITV kernel Microsoft Interactive TV system Commercial trial in Yokosuka, Japan Tiger Video Fileserver

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

9. Programming Model Activities CPU Reservations Time Constraints

10. 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

11. 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

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

13. 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 ();

14. Example: CPU Reservation & Time Constraints Activities:Estimate: Time with reservations and constraints Start Time:Deadline:

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

16. 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

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

18. 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

19. Scheduling Plan Example

20. 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

21. 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

22. EDF Constraint Execution Constraints executed in EDF order During the intervals assigned to constraints Improves cache locality Eliminates timeslicing among constraints

23. 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

24. 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

25. 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

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

27. 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

28. 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

29. 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

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

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

32. Achieving Bounded Response: Time Constraints against Time Sharing Time to complete 50ms of work, no reservations Desired responsiveness achieved under load

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

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

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

36. 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

37. Acknowledgments OS Research Group at Microsoft Research Microsoft Interactive TV Team Kevin Jeffay, Karsten Schwan, Patricia Jones, Susan Owicki, George Candea, Jason Nieh

38. 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/