1 / 13

Preemptive Minithreads

Preemptive Minithreads. Tom Roeder CS415 2005sp. Multi-level Feedback Queues. Highest priority. Quantum = 2. Quantum = 4. Quantum = 8. Quantum = 16. Lowest priority. Borrowed from 414 notes. Multi-level Queues. Just like a regular queue, except 4 levels: can insert into any one

tomar
Download Presentation

Preemptive Minithreads

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related