Preemptive Minithreads

1. Preemptive Minithreads Tom Roeder CS415 2005sp

2. Multi-level Feedback Queues Highest priority Quantum = 2 Quantum = 4 Quantum = 8 Quantum = 16 Lowest priority Borrowed from 414 notes

3. Multi-level Queues • Just like a regular queue, except • 4 levels: can insert into any one • If a dequeue is requested and there’s no element on this level, try the next. Return which level. • returns NULL and -1 if the are no elements • Note: errors inside the queues should cause an exit • We will use this data structure for scheduling • You will want to reuse your queue impl

4. Our Scheduling Algorithm • Feedback Queues: • 4 levels with quantum doubling at each • demotion: if thread overruns its quantum • ie. thread has not yielded before preemption • will happen frequently for CPU-bound procs • promotion: by age • assign points upon queue entry • points accumulate over time • we add a promotion threshold

5. Algorithm Comparisons • Our alg: starvation elimination • Tries to get SRTF scheduling • current level: function of age and past CPU bursts • thus we are averaging CPU bursts over age • other options • no promotions • many jobs float to the bottom • very predictable • poor waiting time and latency

6. Algorithm Comparisons • other options (cont’d) • weighted levels • always work with all levels, but visit lower ones rarely • assign weights to each level: 50%, 25%, 15%, 10% • still no promotion, so all past history matters! • burst measurements for promotions • little real history • need to add a weighted averaging to be realistic • otherwise very unpredictable, jittery

7. Interrupts • On minithread_clock_init, you will start receiving interrupts • Right now just clock interrupts, but a general interrupt mechanism is present in the code • Network packets will later cause interrupts • Happen on the current stack • Control is wrenched from the current thread • Given to clock handler • Don’t waste time in the clock handler!

8. Clock Handler and Alarms • When you receive a clock tick: • Don’t use system functions (too slow) • Just count the ticks in a variable • Need a structure to keep track of alarms • Hint: you probably have already implemented one • A queue normally doesn’t provide fast search • This is OK, if you assume cancel infrequent • Your clock handler will need to run the alarms • alarm functions must be short and not block!

9. Low-level synchronization • Cannot block at interrupt time: • interrupts may interrupt our synch code • for short synchronization: disable interrupts interrupt_level_t intlevel = set_interrupt_level(DISABLED); /* your code here */ set_interrupt_level(intlevel); • Don’t do this too much: hurts performance • will be penalized in grading

10. Warnings • Do not block while interrupts are disabled • Do not call system functions in a handler • Interrupts may be called in any context • Avoid disabling interrupts wherever possible • make any disabled period as short as possible • Beware of nested disable/enable blocks • Synchronize all global data!

11. How to get started • First implement and test the multi-level Q • dequeue should always return a value if possible • Then experiment with clock interrupts • slow them down (modify “interrupts.h”) • make sure a simple handler works • Add alarms • Change the scheduler • make sure round-robin works on a simple queue • add points and a multi-level queue • do demotion and promotion

12. Grading • Correctness • avoid race conditions (eg. in alarm code) • nested interrupt level changes • Efficiency • handlers must be fast • idle thread runs only when idle • don’t overdo interrupt disabling • Good software engineering • clean design, good comments

13. Questions?