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
J1
J2
0
2
4
5
10
7
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 constraints
  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
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