1. RTOS Scheduling – II
EE202A (Fall 2001): Lecture #5

2. Reading List for This Lecture
Required
Waldspurger, C.A.; Weihl, W.E. Lottery scheduling: flexible proportional-share resource management. Proceedings of the First USENIX Symposium on Operating Systems Design and Implementation (OSDI), Monterey, CA, USA, Nov p pp.
Recommended
none
Others

3. Deadline Driven Scheduling
Priorities are assigned to tasks according to the deadlines of their current requests
highest priority to task whose current request has the closest deadline
lowest to the one whose deadline is the furthest
highest priority task with an unfulfilled request is run
Priorities of tasks change with time!

4. Preemptive Earliest Deadline First (EDF)
Processor executes the task whose absolute deadline is the earliest
Priorities change with the closeness of a task to its absolute deadline
Example:
Task
Arrival Time
Execution Time
Absolute Deadline T1 10 30 T2 4 3 T3 5 25

5. EDF Schedulability Optimal for single processor
If EDF cannot schedule a task set on a single processor, then no other scheduling algorithm can
Simple schedulability test if tasks are periodic, and have relative deadlines equal to their periods
if the total utilization U of the task set is no greater than 1, the task set can be feasibly scheduled by EDF on a single processor.
If relative deadlines are not equal to the periods, there is no simple schedulability test
one will have top develop a schedule using EDF to see whether all the deadlines are met over a given time interval

6. EDF Schedulability for Deadline==Period Case
Theorem: Suppose we have a set of n periodic tasks (Ti, Ci, Di) , each of whose relative deadline Di equals its period Ti. The tasks can be feasibly scheduled by EDF on a single processor iff: C1/T1 + C2/T2 + … + Cn/Tn  1

7. EDF Schedulability for Deadline!=Period Case
Theorem: A set t of n tasks (Ti, Ci, Di) is not schedulable by EDF iff
Utilization U > 1, or
there exists t < min { T + Dmax, U/(1-U) * max1 in{Ti – Di}} such that ht(t) > t, where Dmax = max1 in{Di} T = lcm(T1,…Tn) ht (t) = sum of the execution times of all tasks whose absolute deadlines are ≤ t.
With the above theorem, we only need to check for feasibility up to some finite time.
Proof
see Theorem related Lemmas at
Note the difference in notation (T, C, D) → (P, e, d)

8. Allowing for Precedence Constraints
So far: independent task, preemptible by others
Now we relax these condition

9. Heuristic for Uniprocessor Scheduling

10. Heuristic for Uniprocessor Scheduling (contd.)
Schedule after step 2
Schedule after step 3

11. Primary and Alternative Tasks
So far: there must be sufficient time for the critical tasks to execute
assumed worst case execution time (WCET)
quite often WCET >> mean execution time
One way: reclaim unused time for other tasks
Another approach: multiple versions of tasks
Precise version
Alternate version
shorter processing time but imprecise result
just acceptable “bare bones” result

12. Example
Can’t schedule if only primary version available

13. Imprecise or Approximate Computation
A time-critical task designed in such a way that an approximate result is produced when the entire precise computation cannot be completed
Motivation: tasks become easier to schedule when a tolerable amount of error can be introduced into the system
Examples:
Iterative division algorithm
On-line arithmetic
Bit-serial where the output is produced MSB first

14. Scheduling Model for Imprecise Computation
IRIS: Increased Reward for Increased Service
Each Task, Ti, is decomposed logically into two tasks Mi (mandatory) and Oi (optional)
i = mi + oi (12 = 7 + 5)
Classical model => oi = 0

15. Uniprocessor Scheduling of IRIS Tasks
Reward function
Schedule the tasks such that the reward is maximized, subject to the requirement that the mandatory portions of all the tasks are complete

16. QoS-based Resource Allocation Model (Q-RAM)
Different total system utility by resource allocations
(Rajkumar et al. 1997, 1998)

17. RM in Distributed/Networked Embedded Systems?
Task is essentially scheduled on multiple resources in series
Need to schedule communication messages over the interconnect
propagation delay & jitter
queuing delay & jitter
Divide end-to-end deadline into subsystem deadlines
Need buffering to mitigate jitter problem as task may arrive too early

18. Assignment of Tasks to Processors
NP complete in most cases
Typical heuristics:
Allocate tasks according to some simple criterion
E.g. processor utlization
Check feasibility
Communiction cost, task precedences
If not feasible, modify the allocation and retry

19. Utilization-Balancing Algorithm
Attempts to balance processor utilization
Allocate tasks one by one, and selecting the least utilized processor
Takes into account the possibility of running multiple copies of the same task for fault tolerance

20. Next-Fit Algorithm for RM
User defines M>3 classes as follows:
Task Ti is in class j<M if
In class M otherwise
Corresponding to each class is a set of processors that is only allocated tasks of that class
Tasks are allocated one by one to appropriate processor class until all the tasks have been scheduled, adding processors to classes if that is need for RM schedulability

21. Example
Uses no more than N times the minimum # of processors

22. Bin-packing Algorithm for EDF
Periodic independent preemptible tasks assigned to a multiprocessor with identical processors
Goal EDF schedulability
assign tasks such that U no greater than 1
First-fir decreasing algorithm

23. Example

24. Distributed Case with Data Precedence
Implicit start and stop nodes in each task
Rate constraint and deadline for each task
Period may not be constant: lower/upper bounds
Execution time of processes may not be constant
Lower/upper bounds

25. Performance Analysis
The problem of deciding whether the deadline of each task is met is NP hard
Given the schedule, allocation, and architecture
Unrolling the schedule doesn’t work
Cannot easily handle non-constant period and computation times
Can’t just use the worst case execution time!

26. Erroneous Results in Using WCET in Unrolled Schedules

27. Erroneous Results in Using WCET in Unrolled Schedules

28. Lottery Scheduling: Flexible Proportional-Share Resource Management
4/17/2017
Lottery Scheduling: Flexible Proportional-Share Resource Management
A randomized mechanism that provides responsive control over the relative execution rates of computations
Does away with “primitive” priority based schemes
Implements proportional-share resource management whereby the resource consumption rates are proportional to the relative shares that they are allocated
“Found to provide efficient, flexible control over relative execution rates”

29. Allocation of Resource Rights
4/17/2017
Allocation of Resource Rights
Resource allocation determined by holding a lottery
This effectively allocates resources to competing clients in proportion to the number of tickets that they hold

30. Lottery Scheduling by lottery is probabilistically fair
4/17/2017
Lottery
Scheduling by lottery is probabilistically fair
Number of lotteries won by a client has a binomial distribution
P = t/T
E[w] = np s2w = np(1-p)
Number of lotteries required for a client’s first win has a geometric distribution
E[n] = 1/p s2w = (1-p)/p2
Typical scheduling quantum is 10 ms (100 lotteries per second)

31. Lottery Tickets Properties
4/17/2017
Lottery Tickets
Properties
Abstract
Relative
Uniform
Analogous to that of money in computational economics
Abstractly encapsulate resource rights
Allow for modular resource management

32. Modular Resource Management
4/17/2017
Modular Resource Management
Ticket transfers
Explicit transfers of tickets from one client to another
Can be used in any situation where a client blocks due to some dependency
Solves conventional priority inversion problem in a manner similar to priority inheritance
Ticket inflation
Alternative to explicit ticket transfers
Escalate resource rights by creating more lottery tickets
Need for mutual trust among clients
Inflation and deflation can be used to adjust resource allocations w/o explicit communication

33. Modular Resource Management (cont’d)
4/17/2017
Modular Resource Management (cont’d)
Ticket currencies
Resources rights could be expressed in “local” units, with granularity tuned for that particular resource
Each currency is backed, or funded, by tickets that are denominated in more primitive currencies
Exchange rates could be established between local currency and base currency
Compensation Tickets
Compensation ticket granted for client only consuming only a fraction f of its allocated resource quantum, inflate its value by 1/f
Ex: Threads A and B each hold tickets valued at 400 base units (1:1 ratio)
Thread A always consumes its entire 100 ms of quantum
Thread B uses only 20 ms => f = 1/5

34. Implementation alice Ticket Currency
4/17/2017
Implementation
Modified Mach 3.0 microkernel running on a 25MHz MIPS-based DECStation 5000/125
Kernel representation of tickets and currencies
List of backing tickets
amount
1000
Base
currency
alice
Unique name
Active amount
300
List of issued tickets
Ticket
Currency

35. System Overhead Core lottery scheduling mechanism
4/17/2017
System Overhead
Core lottery scheduling mechanism
Ex: tree-based lottery need only generate a random number and perform log n additions and comparisons to select winner among n clients
Comparing unoptimized kernel to unmodified Mach kernel, it was found that application executed 1.7% faster

36. Experimental Results Multimedia Applications Load Insulation
4/17/2017
Multimedia Applications
3 MPEG viewers, 3:2:1 allocation ratio
Actual ratio, 1.92:1.50:1
No need for cooperation between media-based applications, nor feedback to adjust frame rates
Load Insulation
Two tasks A and B w/ equal funding
Subtasks A1 and A2 have allocations of 100 and 200, respectively
Subtasks B1 and B2 have identical allocations
Currency has an abstract barrier that locally contains intra-currency fluctuations
System was found to be fair, flexible, and robust

37. 4/17/2017
Inverse Lotteries
Basic idea: a “loser” is chosen to relinquish a unit of a resource that it holds
Instead of obtaining a resource, client tries to prevent having its resource allocation revoked
P = 1/(n-1)*(1-t/T)

38. 4/17/2017
Multiple Resources
Clients can make quantitative comparisons to make decisions involving tradeoffs between different resources
Questions
Funding policies?
Frequency of fund allocation evaluation?

39. 4/17/2017
“Financial Advisor”
Abstract the evaluation of resource management options
Financial manager would be allocated a fixed small percentage (e.g. 1%) of application’s overall funding (or computation time)
Default simple managers for most applications, complex management strategies for sophisticated applications

40. Lottery Scheduling Summary
4/17/2017
Lottery Scheduling Summary
Lottery scheduling is conceptually very simple and easily implemented
Used to manage any resource where management is necessary to resolve multiple requests
Current ongoing work involves exploring various applications of lottery scheduling in interactive systems, including GUI element