EECS 262a Advanced Topics in Computer Systems

slide1. EECS 262a Advanced Topics in Computer SystemsLecture 11Scheduling #1October 2nd, 2025 John Kubiatowicz Electrical Engineering and Computer Sciences
University of California, Berkeley

http://www.eecs.berkeley.edu/~kubitron/cs262<br>
slide2. Today’s Papers Lottery Scheduling: Flexible Proportional-Share Resource ManagementCarl A. Waldspurger and William E. Weihl. Appears in Proceedings of the First USENIX Symposium on Operating Systems Design and Implementation (OSDI), 1994
Integrating Multimedia Applications in Hard Real-Time SystemsLuca Abeni and Giorgio Buttazzo. Appears in Proceedings of the Real-Time Systems Symposium (RTSS), 1998

Thoughts?<br>
slide3. Scheduling Review Scheduling: selecting a waiting process and allocating a resource (e.g., CPU time) to it

First Come First Serve (FCFS/FIFO) Scheduling:
Run threads to completion in order of submission
Pros: Simple (+)
Cons: Short jobs get stuck behind long ones (-)

Round-Robin Scheduling:
Give each thread a small amount of CPU time (quantum) when it executes; cycle between all ready threads
Pros: Better for short jobs (+)
Cons: Poor when jobs are same length (-)<br>
slide4. Multi-Level Feedback Scheduling A scheduling method for exploiting past behavior
First used in Cambridge Time Sharing System (CTSS)
Multiple queues, each with different priority
Higher priority queues often considered “foreground” tasks
Each queue has its own scheduling algorithm
e.g., foreground – Round Robin, background – First Come First Serve
Sometimes multiple RR priorities with quantum increasing exponentially (highest:1ms, next:2ms, next: 4ms, etc.)
Adjust each job’s priority as follows (details vary)
Job starts in highest priority queue
If timeout expires, drop one level
If timeout doesn’t expire, push up one level (or to top)<br>
slide5. Lottery Scheduling Very general, proportional-share scheduling algorithm
Problems with traditional schedulers:
Priority systems are ad hoc at best: highest priority always wins, starvation risk
“Fair share” implemented by adjusting priorities with a feedback loop to achieve fairness over the (very) long term (highest priority still wins all the time, but now the Unix priorities are always changing)
Priority inversion: high-priority jobs can be blocked behind low-priority jobs
Schedulers are complex and difficult to control with hard to understand behaviors<br>
slide6. Lottery Scheduling Give each job some number of lottery tickets
On each time slice, randomly pick a winning ticket and give owner the resource
On average, resource fraction (CPU time) is proportional to number of tickets given to each job
Tickets can be used for a wide variety of different resources (uniform) and are machine independent (abstract)<br>
slide7. How to Assign Tickets? Priority determined by the number of tickets each process has:
Priority is the relative percentage of all of the tickets competing for this resource
To avoid starvation, every job gets at least one ticket (everyone makes progress)<br>
slide8. Lottery Scheduling Example Assume short jobs get 10 tickets, long jobs get 1 ticket<br>
slide9. How Fair is Lottery Scheduling? If client has probability p = (t/T) of winning, then the expected number of wins (from the binomial distribution) is np
Probabilistically fair
Variance of binomial distribution: σ2 = np(1 – p)
Accuracy improves with √n
Geometric distribution yields number of tries until first win
Advantage over strict priority scheduling: behaves gracefully as load changes
Adding or deleting a job affects all jobs proportionally, independent of how many tickets each job possesses
Big picture answer: mostly accurate, but short-term inaccuracies are possible
Stride Scheduling provides follow-on solution<br>
slide10. Ticket Transfer How to deal with dependencies
Basic idea: if you are blocked on someone else, give them your tickets
Example: client-server
Server has no tickets of its own
Clients give server all of their tickets during RPC
Server’s priority is the sum of the priorities of all of its active clients
Server can use lottery scheduling to give preferential service to high-priority clients
Very elegant solution to long-standing problem (not the first solution however)<br>
slide11. Ticket Inflation Make up your own tickets (print your own money)
Only works among mutually trusting clients
Presumably works best if inflation is temporary
Allows clients to adjust their priority dynamically with zero communication<br>
slide12. Currencies Set up an exchange rate with the base currency
Enables inflation just within a group
Also isolates from other groups
Simplifies mini-lotteries, such as for a mutex<br>
slide13. Compensation Tickets What happens if a thread is I/O bound and regular blocks before its quantum expires?
Without adjustment, this implies that thread gets less than its share of the processor
Basic idea:
If you complete fraction f of the quantum, your tickets are inflated by 1/f until the next time you win
Example:
If B on average uses 1/5 of a quantum, its tickets will be inflated 5x and it will win 5 times as often and get its correct share overall<br>
slide14. Lottery Scheduling Problems Not as fair as we’d like:
mutex comes out 1.8:1 instead of 2:1, while multimedia apps come out 1.92:1.50:1 instead of 3:2:1
Practice midterm question:
Are these differences statistically significant?
Probably are, which would imply that the lottery is biased or that there is a secondary force affecting the relative priority (e.g., X server)<br>
slide15. Lottery Scheduling Problems Multimedia app:
Biased due to X server assuming uniform priority instead of using tickets
Conclusion: to really work, tickets must be used everywhere – every queue is an implicit scheduling decision... every spinlock ignores priority...
Can we force it to be unfair?
Is there a way to use compensation tickets to get more time, e.g., quit early to get compensation tickets and then run for the full time next time?
What about kernel cycles?
If a process uses a lot of cycles indirectly, such as through the Ethernet driver, does it get higher priority implicitly? (probably)<br>
slide16. Stride Scheduling Follow on to lottery scheduling (not in paper)
Basic idea:
Make a deterministic version to reduce short-term variability
Mark time virtually using “passes” as the unit
A process has a stride, which is the number of passes between executions
Strides are inversely proportional to the number of tickets, so high priority jobs have low strides and thus run often
Very regular: a job with priority p will run every 1/p passes<br>
slide17. Stride Scheduling Algorithm Algorithm (roughly):
Always pick the job with the lowest pass number
Updates its pass number by adding its stride
Similar mechanism to compensation tickets
If a job uses only fraction f, update its pass number by f × stride instead of just using the stride
Overall result:
It is far more accurate than lottery scheduling and error can be bounded absolutely instead of probabilistically<br>
slide18. Linux Completely Fair Scheduler (CFS) First appeared in 2.6.23, modified in 2.6.24
“CFS doesn't track sleeping time and doesn't use heuristics to identify interactive tasks—it just makes sure every process gets a fair share of CPU within a set amount of time given the number of runnable processes on the CPU.”
Inspired by Networking “Fair Queueing”
Each process given their fair share of resources
Models an “ideal multitasking processor” in which N processes execute simultaneously as if they truly got 1/N of the processor
Tries to give each process an equal fraction of the processor
Priorities reflected by weights such that increasing a task’s priority by 1 always gives the same fractional increase in CPU time – regardless of current priority<br>
slide19. CFS (Continued)<br>
slide20. Is this a good paper? What were the authors’ goals?
What about the evaluation/metrics?
Did they convince you that this was a good system/approach?
Were there any red-flags?
What mistakes did they make?
Does the system/approach meet the “Test of Time” challenge?
How would you review this paper today?<br>
slide21. Realtime Sceduling Motivation: Consolidation/Energy Efficiency Consider current approach with ECUs in cars:
Today: 50-100 individual “Engine Control Units”
Trend: Consolidate into smaller number of processors
How to provide guarantees?
Better coordination for hard realtime/streaming media
Save energy rather than “throwing hardware at it”<br>
slide22. Recall: Non-Real-Time Scheduling Primary Goal: maximize performance
Secondary Goal: ensure fairness
Typical metrics:
Minimize response time
Maximize throughput
E.g., FCFS (First-Come-First-Served), RR (Round-Robin)<br>
slide23. Characteristics of a RTSSlides adapted from Frank Drew Extreme reliability and safety
Embedded systems typically control the environment in which they operate
Failure to control can result in loss of life, damage to environment or economic loss
Guaranteed response times
We need to be able to predict with confidence the worst case response times for systems
Efficiency is important but predictability is essential
In RTS, performance guarantees are:
Task- and/or class centric
Often ensured a priori
In conventional systems, performance is:
System oriented and often throughput oriented
Post-processing (… wait and see …)
Soft Real-Time
Attempt to meet deadlines with high probability
Important for multimedia applications<br>
slide24. Typical Realtime Workload Characteristics Tasks are preemptable, independent with arbitrary arrival (=release) times
Times have deadlines (D) and known computation times (C)
Tasks execute on a uniprocessor system
Example Setup:<br>
slide25. Example: Non-preemptive FCFS Scheduling<br>
slide26. Example:Round-Robin Scheduling<br>
slide27. Real-Time Scheduling Primary goal: ensure predictability
Secondary goal: ensure predictability
Typical metrics:
Guarantee miss ratio = 0 (hard real-time)
Guarantee Probability(missed deadline) < X% (firm real-time)
Minimize miss ratio / maximize completion ration (firm real-time)
Minimize overall tardiness; maximize overall usefulness (soft real-time)
E.g., EDF (Earliest Deadline First), LLF (Least Laxity First), RMS (Rate-Monotonic Scheduling), DM (Deadline Monotonic Scheduling)
Real-time is about enforcing predictability, and does not equal to fast computing!!!<br>
slide28. Task Assignment and Scheduling Cyclic executive scheduling ( later)
Cooperative scheduling
scheduler relies on the current process to give up the CPU before it can start the execution of another process
A static priority-driven scheduler can preempt the current process to start a new process. Priorities are set pre-execution
E.g., Rate-monotonic scheduling (RMS), Deadline Monotonic scheduling (DM)
A dynamic priority-driven scheduler can assign, and possibly also redefine, process priorities at run-time.
Earliest Deadline First (EDF), Least Laxity First (LLF)<br>
slide29. Simple Process Model Fixed set of processes (tasks)
Processes are periodic, with known periods
Processes are independent of each other
System overheads, context switches etc, are ignored (zero cost)
Processes have a deadline equal to their period
i.e., each process must complete before its next release
Processes have fixed worst-case execution time (WCET)<br>
slide30. Performance Metrics Completion ratio / miss ratio
Maximize total usefulness value (weighted sum)
Maximize value of a task
Minimize lateness
Minimize error (imprecise tasks)
Feasibility (all tasks meet their deadlines)<br>
slide31. Scheduling Approaches (Hard RTS) Off-line scheduling / analysis (static analysis + static scheduling)
All tasks, times and priorities given a priori (before system startup)
Time-driven; schedule computed and hardcoded (before system startup)
E.g., Cyclic Executives
Inflexible
May be combined with static or dynamic scheduling approaches
Fixed priority scheduling (static analysis + dynamic scheduling)
All tasks, times and priorities given a priori (before system startup)
Priority-driven, dynamic(!) scheduling
The schedule is constructed by the OS scheduler at run time
For hard / safety critical systems
E.g., RMA/RMS (Rate Monotonic Analysis / Rate Monotonic Scheduling)
Dynamic priority scheduling
Tasks times may or may not be known
Assigns priorities based on the current state of the system
For hard / best effort systems
E.g., Least Completion Time (LCT), Earliest Deadline First (EDF), Least Slack Time (LST)<br>
slide32. Cyclic Executive Approach Clock-driven (time-driven) scheduling algorithm
Off-line algorithm
Minor Cycle (e.g. 25ms) - gcd of all periods
Major Cycle (e.g. 100ms) - lcm of all periods
Construction of a cyclic executive is equivalent to bin packing<br>
slide33. Frank Drews Real-Time Systems Cyclic Executive (cont.)<br>
slide34. Cyclic Executive: Observations No actual processes exist at run-time
Each minor cycle is just a sequence of procedure calls
The procedures share a common address space and can thus pass data between themselves.
This data does not need to be protected (via semaphores, mutexes, for example) because concurrent access is not possible
All ‘task’ periods must be a multiple of the minor cycle time<br>
slide35. Cyclic Executive: Disadvantages With the approach it is difficult to:
incorporate sporadic processes;
incorporate processes with long periods;
Major cycle time is the maximum period that can be accommodated without secondary schedules (=procedure in major cycle that will call a secondary procedure every N major cycles)
construct the cyclic executive, and
handle processes with sizeable computation times.
Any ‘task’ with a sizeable computation time will need to be split into a fixed number of fixed sized procedures.<br>
slide36. Online Scheduling for Realtime<br>
slide37. Schedulability Test Test to determine whether a feasible schedule exists
Sufficient Test
If test is passed, then tasks are definitely schedulable
If test is not passed, tasks may be schedulable, but not necessarily
Necessary Test
If test is passed, tasks may be schedulable, but not necessarily
If test is not passed, tasks are definitely not schedulable
Exact Test (= Necessary + Sufficient)
The task set is schedulable if and only if it passes the test.<br>
slide38. Rate Monotonic Scheduling: Principle Principle: Each process is assigned a (unique) priority based on its period (rate); always execute active job with highest priority
The shorter the period the higher the priority
( 1 = low priority)
W.l.o.g. number the tasks in reverse order of priority<br>
slide39. Rate Monotonic Analysis: Assumptions A1: Tasks are periodic (activated at a constant rate). Period = Interval between two consecutive activations of task
A2: All instances of a periodic task have  the same computation time
A3: All instances of a periodic task have the same relative deadline,  which is equal to the period
A4: All tasks are independent (i.e., no precedence constraints and no resource constraints)

Implicit assumptions:
A5: Tasks are preemptable
A6: No task can suspend itself
A7: All tasks are released as soon as they arrive
A8: All overhead in the kernel is assumed to be zero (or part of )<br>
slide40. Example: Rate Monotonic Scheduling Example instance

RMA - Gant chart<br>
slide41. Example: Rate Monotonic Scheduling<br>
slide42. Utilization 0 5 10 15<br>
slide43. RMS: Schedulability Test Theorem (Utilization-based Schedulability Test):
A periodic task set with is schedulable by the rate monotonic scheduling algorithm if:

This schedulability test is “sufficient”!
For harmonic periods ( evenly divides ), the utilization bound is 100%<br>
slide44. RMS Schedulability Example For our failed example earlier:

The schedulability test requires:

Hence, we get Does not satisfy schedulability condition!<br>
slide45. EDF Scheduling: Principle Preemptive priority-based dynamic scheduling
Each task is assigned a (current) priority based on how close the absolute deadline is.
The scheduler always schedules the active task with the closest absolute deadline.<br>
slide46. EDF: Assumptions A1: Tasks are periodic or aperiodic. Period = Interval between two consequtive activations of task
A2: All instances of a periodic task have  the same computation time
A3: All instances of a periodic task have the same relative deadline,  which is equal to the period
A4: All tasks are independent (i.e., no precedence constraints and no resource constraints)

Implicit assumptions:
A5: Tasks are preemptable
A6: No task can suspend itself
A7: All tasks are released as soon as they arrive
A8: All overhead in the kernel is assumed to be zero (or part of )<br>
slide47. EDF: Schedulability Test Theorem (Utilization-based Schedulability Test):
A task set with is schedulable by the earliest deadline first (EDF) scheduling algorithm if:

Exact schedulability test (necessary + sufficient)
Proof: [Liu and Layland, 1973]<br>
slide48. EDF Optimality EDF Properties
EDF is optimal with respect to feasibility (i.e., schedulability)
EDF is optimal with respect to minimizing the maximum lateness<br>
slide49. EDF Example: Domino Effect EDF minimizes lateness of the “most tardy task” [Dertouzos, 1974]<br>
slide50. Constant Bandwidth Server Intuition: give fixed share of CPU to certain of jobs
Good for tasks with probabilistic resource requirements
Basic approach: Slots (called “servers”) scheduled with EDF, rather than jobs
CBS Server defined by two parameters: Qs and Ts
Mechanism for tracking processor usage so that no more than Qs CPU seconds used every Ts seconds (or whatever measurement you like) when there is demand. Otherwise get to use processor as you like
Since using EDF, can mix hard-realtime and soft realtime:<br>
slide51. Comparison of CBS with EDF in Overload If scheduled items do not meet EDF schedulability:
EDF yields unpredictable results when overload starts and stops
CBS servers provide better isolation
Isolation particularly important when deadlines crucial
I.e. hard realtime tasks<br>
slide52. Is this a good paper? What were the authors’ goals?
What about the evaluation/metrics?
Did they convince you that this was a good system/approach?
Were there any red-flags?
What mistakes did they make?
Does the system/approach meet the “Test of Time” challenge?
How would you review this paper today?<br>