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?

 

 

Lottery Scheduling

1. Questions
2. Reminder on project
3. Reviews:
1. What is relationship wi
4. Review of normal schedulers – multi-level feedback queue (Unix, Windows)
1. N priorities, each with a ready queue
2. Execute at level N if level N+1 and higher empty
3. Threads can be assigned an initial priority
4. Threads can move between queues

                                              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

5. Issues:

                                              i.     System knows nothing about users

                                             ii.     Scheduling done based on processes

                                           iii.     Only mechanism for limiting consumption are quotas / charging

5. Goal: proportional share scheduling
1. Share according to users / higher-level groups, not processes

                                              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?

2. Want to handle case where not all are active; if n/2 are active, each process gets 1/n/2
5. QUESTIONS:
1. When do you want proportional share?
2. How many clients?
3. What properties do you want?

                                              i.     Timeliness

7. Lottery scheduling ideas
1. Randomness for making decision

                                              i.     Randomly pick a process at each time

2. Lotteries for making choice

                                              i.     Each client gets some number of tickets

                                             ii.     Chance of winning = # of tickets / # of tickets contending

3. Tickets

                                              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)

4. Implementation

                                              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

5. NOTE: lottery implementation is not used; randomness hard to reason about. instead, strides:

                                              i.     let thread run, compute next run time as 1/fraction tickets. Always run earliest thread

6. QUESTION: Tickets don’t get consumed. Why?
7. General ideas:
1. Randomness
2. Lotteries
3. Currencies – conversion between resources (e.g. i/o bandwidth, memory, cpu) or users
8. Extensions
1. Ticket inflation: mint more tickets in a currency

                                              i.     QUESTION: Who should be able to do this?

1.   If have N processes, should all of them?

2. Ticket transfers

                                              i.     Move tickets from one client to another

                                             ii.     E.g. rpc client gives to rpc server

                                           iii.     Lock waiter give to lock holder

3. Currency

                                              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

4.   (INFLATION)

4. Compensation tickets

                                              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

1.  

10. Uses
1. Variable scheduling for simulation

                                              i.     Prioritize computations with large error over those refining errors

2. Donate tickets from client to server

                                              i.     Encourages server to run faster and complete more quickly and be scheduled sooner

3. Multimedia

                                              i.     Degrading service when handling multiple clients; don’t want to freeze some out

                                             ii.     Use proportional share based on weights

4. Space-shared resources

                                              i.     Choose victim with a lottery

11. Nice properties
1. Handles priority inversion

                                              i.     Donate tickets to lock holder

                                             ii.     Lock holder holds lottery when releasing to find next holder

2. Easy to donate resources – give them your tickets

                                              i.     E.g. client/server model – client gives server tickets

3. When don’t use full resource quanta, are given tickets inversely proportional to used fraction (e.g. if use 1/5, get 4x tickets for next lottery), assuming next usage will be similar
11. Issues
1. Schedulers give higher priority to threads holding kernel resources (so they release them more quickly)

                                              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.

2. Implementing NICE

                                              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

                                             v.     Solution:

1.   At scheduling time, adjust base tickets to be at most or at least a value proportional to NICE priority

3. Supporting interactive users: issue

                                              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.

4. CPU is not the only resource; unclear how well you can balance between resources (despite the goal)
12. My sense:
1.