1 / 34

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

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

matsu
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  8. Programming Model • Activities • CPU Reservations • Time Constraints

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

  10. Abstraction: CPU Reservation • Guaranteed execution rate and granularity for an activity • X units of time out of everyY units, e.g. • 800µs every 5ms • 7.5ms every 33.3ms • one second every minute • Continuously guaranteed

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

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

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

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

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

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

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

  18. Scheduling Plan Example

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related