Lec 3-Scheduling(3)

Fair Share Scheduling

New goal: Fairness

• From now on, schedulers are designed to optimize performance
  • Minimize response time, turnaround time

MLFQ achieves these goals, but complicated

• Non-trivial to implement
• Difficult to tune parameters (e.g. distribution of CPU time)

---

Lottery Scheduling

Key idea

• Give each process tickets
  • Each time slice, scheduler holds a lottery
  • Process holding the winning ticket runs

Probabilistic scheduling

• Over time, run time for each process converges to the correct value

---

Implementation Advantages

1. Fast scheduler execution
   • All the scheduler needs to do is run random()
   • (Actually, real random generator in OS is difficult)
   • No need to manage $O(log N)$ priority queues

2. No need to store state
   • Scheduler needs to know the total number of tickets
   • But, No need to track process behavior(total CPU time)

3. Automatically balances CPU time across processes

   • New processes get some tickets, adjust the overall size of the ticket pool

4. Easy to prioritize processes

   • High priority processes $\rightarrow$ many tickets
   • Low priority processes $\rightarrow$ a few tickets
   • Priorities can change via ticket inflation

---

So is Lottery scheduling fair?

• Assume two processes with equal tickets
• Unfairness ratio = ${completion(A)}\over{completion(B)}$
  • If unfairness ratio = 1, then both processes finish at the same time
    = Fair scheduler

• Unfair to short job due to randomness
• Over time, randomness is amortized

---

Stride Scheduling

Motivation

• Randomness makes us build a simple and approximately fair scheduler
  But, Fairness is not guaranteed
  $\rightarrow$ Build a deterministic, fair scheduler

Key idea

• Each process is given some tickets
• Each process has a stride = ${\text{a big \#}}\over{\text{\# of tickets}}$
• Each time a process runs, its pass += stride
• Scheduler chooses process with the lowest pass to run next

• When the passes reach to the least common multiple of Stride(=200),
  fairness is guaranteed

---

Issues

Why choose lottery over stride scheduling?

1. Stride schedulers need to store a lot more state
2. What about new processes?
   • If Pass = 0, then it will dominate CPU

Both schedulers require tickets assignment

• How many tickets to assign?