NOTES ON PROJECT: related work report due Thursday – a page of related work. Make sure you explain your work in relation to it – how are you different: better, new implementation, more useful.
Problems with schedulers:
- granularity: processes / threads
- guarantees: priority & real time
- WHAT IF YOU WANT SOMETHING ELSE?
i. Priority lowered if exhausts quantum
ii. Priority raised if sleeps early / when woken up from sleep
iii. Quantum shorter for higher-priority queues
iv. Quantum longer for lower-priority queues
v. Priority raised if have been pre-empted before full quantum
i. System knows nothing about users
ii. Scheduling done based on processes
iii. Only mechanism for limiting consumption are quotas / charging
i. N users want something
ii. Each gets 1/N
iii. Easy (relatively) for evenly weighted
iv. What if want more flexible distribution of weights?
i. Randomly pick a process at each time
i. Each client gets some number of tickets
ii. Chance of winning = # of tickets / # of tickets contending
i. Resource rights are abstract
1. Independent of machine details
2. Not tied to cpu cyles, memory pages
ii. Uniform rights
1. Can apply to heterogeneous pool of resources (but may need a conversion factor)
iii. Converges with sqrt(# lotteries)
iv. Expected time to win is 1/p (p = proportion)
i. Hold lotteries in base units (== sum of base tickets for ready processes)
ii. Scan ready list accumulating partial sum until hit process
iii. Move large ticket holders to front to minimize average scan length
iv. Optimizations: tree with partial sums
i. let thread run, compute next run time as 1/fraction tickets. Always run earliest thread
i. QUESTION: Who should be able to do this?
1. If have N processes, should all of them?
i. Move tickets from one client to another
ii. E.g. rpc client gives to rpc server
iii. Lock waiter give to lock holder
i. QUESTION: What problem does it solve?
ii. System provides base tickets
iii. Clients can issue tickets denominated in their own currency
iv. Allows dividing resources.
v. Easy to have all children have equal shares
1. QUESTION: How?
2. Just give each one same # of tickets
3. No need to adjust tickets for other clients
i. QUESTION: What problem do they solve?
ii. If use only fraction F of allocated resource, tickets inflated by 1/F until next starts to use resource
iii. Makes client more likely to win lottery
iv. Keep proportional share property
v. Makes system more responsive for interactive processes, because expected waiting time is lower
i. Prioritize computations with large error over those refining errors
i. Encourages server to run faster and complete more quickly and be scheduled sooner
i. Degrading service when handling multiple clients; donŐt want to freeze some out
ii. Use proportional share based on weights
i. Choose victim with a lottery
i. Donate tickets to lock holder
ii. Lock holder holds lottery when releasing to find next holder
i. E.g. client/server model – client gives server tickets
i. Classic LS solution: contending users donate resources to holder
ii. Problem: Too expensive to hold lottery
iii. Solution: Maintain priority queues for threads that woke up from being blocked on kernel resource; schedule these before holding lottery
iv. Charge them tickets according to how long they ran from this method.
i. What does NICE do: ensure a process only runs if there are no higher-priority processes in the system
ii. QUESTION: How do you do this with lottery scheduling?
iii. Problem: lowering user-denominated tickets doesnŐt help:
1. QUESTION: Why?
a. What if niceŐd process is only one of a user – it will get entire userŐs share
iv. Issue: need to adjust priority relative to other users, not just to one user
1. At scheduling time, adjust base tickets to be at most or at least a value proportional to NICE priority
i. Force context switch when sleeping process wakes up
ii. Pre-empted process gets appropriate compensation tickets
iii. Issue: pre-empted cpu bound process with compensation tickets competes with i/o bound process
1. Solution: see who has received less CPU than their # of tickets should indicate
2. These are interactive, because they often block waiting for input
3. Give them a boost – e.g. multiplicative factor to tickets.