1 / 21

An Overview of the Rialto Real-Time Architecture

An Overview of the Rialto Real-Time Architecture. M. Jones et al. Seventh ACM SIGOPS European Workshop, September 1996. Presenter: William Conner March 9, 2005. Outline. Overview Time Constraints Design Scheduling algorithm Results Comments. Rialto. Microsoft Research project

Download Presentation

An Overview of the Rialto Real-Time Architecture

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. An Overview of the Rialto Real-Time Architecture M. Jones et al. Seventh ACM SIGOPS European Workshop, September 1996 Presenter: William Conner March 9, 2005

  2. Outline • Overview • Time Constraints • Design • Scheduling algorithm • Results • Comments

  3. Rialto • Microsoft Research project • Consumer real-time computing • e.g., Playing music while writing e-mail • Real-time architecture • Supports coexisting independent real-time and non-real-time programs • Suitable for dynamic environments

  4. Time Constraints Earliest time to begin running code Estimated time needed to execute code • Specify timeliness requirements for an execution of a block of code to system • BeginConstraint( start, estimate, deadline, criticality ) • Returns whether or not system believes deadline can be met • Allows applications to adjust • EndConstraint( ) • Returns amount of time spent running code • Provides feedback to applications Latest time code may finish running Importance of meeting deadline CRITICAL or NONCRITICAL

  5. Time Constraints // calculate constraint parameters schedulable = BeginConstraint( start, estimate, deadline, criticality ); if ( schedulable ){ // Do normal work under constraint } else { // Transient overload - shed load if // possible } time_taken = EndConstraint();

  6. Time Constraints • Properties • All input parameters to BeginConstraint()and output of EndConstraint() are local • No need to assign global priority numbers across all threads in the system • Output of BeginConstraint() is only globally-derived parameter • Scheduler must be aware of other threads to provide schedulable result

  7. Design • Resource planner • Arbitrates between programs requesting resource reservations • Resource • Limited quantity of hardware or software • e.g., CPU, memory, network bandwidth • Resource set • Collection of resources and associated amounts • Activity • Abstraction to which resources are allocated • Thread • Has an associated activity

  8. Design • Paper mostly considers CPU resource • Reserved CPU time • Percentage of CPU time can be allocated according to reservation • Some activities may not have reservations • Unreserved CPU time • Shared equally among all activities including those with and without reservations

  9. Design • Rialto scheduling goals • Meet as many timing constraints as possible • Respect ongoing CPU reservations • Provide fair-share scheduling of threads within activities • Prevent starvation

  10. Minimum-Laxity-First • Rialto uses modified version of minimum-laxity-first (MLF) algorithm with preemption • Also known as least-slack-time-first (LST) algorithm • Optimal for scheduling preemptive jobs on one processor

  11. Minimum-Laxity-First Laxity (or slack) of a job: d = job deadline t = current time r = time required to complete remaining portion of the job laxity = d - t - r (how much longer job can wait and still have chance of meeting deadline)

  12. Minimum-Laxity-First Job J1: execution time = 4, deadline = 8 Job J2: execution time = 2, deadline = 9 J1 J2 0 2 6 8 10 t = 6 J1 has completed laxity for J2 = d2 - t - r2 = 9 - 6 - 2 = 1 t = 2 laxity for J1 = d1 - t - r1 = 8 - 2 - 4 = 2 laxity for J2 = d2 - t - r2 = 9 - 2 - 2 = 5

  13. Minimum-Laxity-First Job J1: execution time = 4, deadline = 8 Job J2: execution time = 1, deadline = 6 J1 J2 J1 0 2 4 5 7 10 t = 2 laxity for J1 = d1 - t - r1 = 8 - 2 - 4 = 2 laxity for J2 = d2 - t - r2 = 6 - 2 - 1 = 3 t = 4 laxity for J1 = d1 - t - r1 = 8 - 4 - 2 = 2 laxity for J2 = d2 - t - r2 = 6 - 4 - 1 = 1

  14. Modified MLF • Threads are scheduled by earliest run-by time (defined on next slide) • Run-by is latest time at which a constraint’s code could be initially scheduled and still make deadline • Takes CPU reservation into account with scale factor • Scale factor is reciprocal of fraction of CPU reserved during execution

  15. Replaces r in pure MLF equation Modified MLF For threads with constraints: initial laxity = deadline - current_time - (estimate * scale_factor) initial run_by = current_time + laxity = deadline - (estimate * scale_factor) run_by = run_by + (time_run * scale_factor) For threads without constraints: initial run_by = current_time run_by = run_by + (time_run * scale factor * num_runnable_thrds)

  16. Modified MLF • Examples • Thread T1 (with constraint) • deadline = 10, estimate = 3,CPU reservation = 50% • initial run_by = 10 - (3 * 2) = 4 • Thread T2 (without constraint) • time run = 2, number of runnable threads = 1,last ran at t = 0, CPU reservation = 10% • run_by = 0 + (2 * 10 * 1) = 20

  17. Modified MLF • Schedulability test • Checks sanity of the parameters • Verify resulting run-by time is after the present time • Starvation prevention • Minimum amount of CPU must remain unreserved for sharing

  18. Results 20% Remaining 40% of unreserved CPU time is divided equally among 5 activities 16% 12% 8% 4% Execution times for 20 threads belonging to 5 activities with different CPU reservations

  19. Results 2 activities with 3 threads each and equal reservations, with threads 1 & 4 using constraints

  20. Results Influence of CPU reservations over video rendering fidelity

  21. Comments • Pros • Time constraint parameters are local • No need for global assignment of priorities • Laxities can be transmitted in distributed systems • Cons • More background information on MLF would help • Pseudo-code for modified MLF would help • Too many equations described in English • Authors admit schedulability test is too simplistic

More Related