Preemptive Minithreads Tom Roeder CS 415 2005 sp

Preemptive Minithreads Tom Roeder CS 415 2005 sp

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

Multi-level Queues n Just like a regular queue, except q q q 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 n n n 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

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

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

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

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

Clock Handler and Alarms n When you receive a clock tick: q q n Need a structure to keep track of alarms q q q n Don’t use system functions (too slow) Just count the ticks in a variable 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 q alarm functions must be short and not block!

Low-level synchronization n Cannot block at interrupt time: q q 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); n Don’t do this too much: hurts performance q will be penalized in grading

Warnings n n 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 q n n make any disabled period as short as possible Beware of nested disable/enable blocks Synchronize all global data!

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

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

Questions?