Lottery Scheduling: Flexible Proportional-Share Resource Management Sim YounSeok C. A. Waldspurger and W. E. Weihl

Contents ▪How works Lottery Scheduler? ▪Differences with Priority based scheduler ▪Details of Lottery Scheduling ▪Experiments ▪Conclusion ▪Q&A

How works Lottery Scheduler?

Here’s a Lottery ▪You’ll get A+ if you won ▪Every students get one lottery ticket ▪Students get 1 more ticket per 1 Question ▪Student who retaken this Class get double tickets than others

Here’s a Lottery ▪You’ll get A+ if you won ▪Every students get one lottery ticket ▪Students get 1 more ticket per 1 Question ▪Student who retaken this Class get double tickets than others

Lottery Scheduler 1.Each processes have at least 1 ticket 2.Random number generate (0 ~ total ticket-1) 3.Find winner and run it

Lottery Scheduler # of A / # of BCPU % each SCPU % each L 1 / 191%9% 0 / 2N/A50% 2 / 050%N/A 10 / 19.9%0.99% 1 / 1050%5% ▪Throughput proportional to ticket allocation ▪Assume thread A has 10 ticket and thread B has 1 ticket

Differences with Priority based Scheduler

Priority based Scheduling ▪Starvation occur ▪Low priority process blocked permanently by higher priority process ▪Complex to implement ▪Need another modules to solve starvation problem ▪Aging, Multi-level queue ▪Guarantee high priority process run first

Lottery Scheduling ▪No starvation ▪Probabilistically fair ▪Easy to implement ▪Not guarantee high priority process run first

Functions in Lottery Scheduling

Ticket Transfer ▪Explicit transfers of tickets ▪Used this when a client blocks due to dependency ▪Prevent priority inversion (I/O bandwidth, lock …)

Ticket Inflation ▪Alternative way to escalate resource right ▪Users create new tickets ▪No explicit communication ▪Only use for trusting client’s adjusting resource allocation rate

Ticket Currency

Compensation Tickets CPU Bound Process ▪Use whole time slice ▪Amount of ticket 10  10 I/O Bound Process ▪Use a part of time slice ▪f = 1/5 ▪Amount of ticket 10  50 (= 10 * 1/f) T T T/5

Implementation & Experiments

Implementation ▪Integrated into Mach 3.0 ▪Co-exist with fixed priority policies ▪Support ticket transfers, currencies, inflation, compensation ▪List based thread list ▪Winning thread selected in O(n) ▪Possibly optimized to tree-based list

Experiment (Fairness) Observed ratio over 60s8 sec window, 2:1 allocate ratio

Experiment (Flexible control)

Experiment (Client-Server Computation) ▪Three clients querying text-search ▪8:3:1 allocation for clients

Experiment (Multimedia Applications) ▪Three video viewers ▪3:2:1 initial allocation ▪Change to 3:1:2 ▪Real ratios 1.92:1.50:1 and 1.92:1:1.53

Experiment (Load Insulation) ▪5 times Dhrystone ▪Currencies A, B ▪Funded equally ▪Task group A  1:2 ▪Task group B  1:2 then 1:2:3

Experiment (Lock Scheduling) ▪8 threads competing for one mutex ▪Hold mutex 50ms (h) ▪Computes for 50ms (t) ▪Threads divided into 2 groups ▪2:1 allocation ▪1:2.11 waiting times ▪1.80:1 mutex acquisition rate

Conclusion ▪Effective to Interactive system but ineffective to Real-Time system ▪How about mixed interactive and CPU-bound workload? ▪Most of experiments use only one type of workload