An Overview of the Rialto Real-Time Architecture

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