1 / 32

Outline for Today

Outline for Today. Objectives: Linux scheduler Lottery scheduling. Linux Scheduling Policy. Runnable process with highest priority and timeslice remaining runs (SCHED_OTHER policy) Dynamically calculated priority Starts with nice value

dchase
Download Presentation

Outline for Today

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. Outline for Today • Objectives: • Linux scheduler • Lottery scheduling

  2. Linux Scheduling Policy • Runnable process with highest priority and timeslice remaining runs (SCHED_OTHER policy) • Dynamically calculated priority • Starts with nice value • Bonus or penalty reflecting whether I/O or compute bound by tracking sleep time vs. runnable time: • sleep_avg – accumulated during sleep up to MAX_SLEEP_AVG (10 ms default) • decremented by timer tick while running

  3. Linux Scheduling Policy • Dynamically calculated timeslice • The higher the dynamic priority, the longer the timeslice: • Recalculated every round when “expired” and “active” swap • Exceptions for expired interactive • Go back on active unless there are starving expired tasks High prioritymore interactive Low priorityless interactive 10ms 150ms 300ms

  4. . . . . . . . . . . . . Runqueue for O(1) Scheduler Higher prioritymore I/O 300ms priority array priority queue active lower prioritymore CPU 10ms priority queue expired priority array priority queue priority queue

  5. . . . . . . . . . . . . Runqueue for O(1) Scheduler priority array 0 priority queue 1 active priority queue expired priority array priority queue priority queue

  6. X . . . . . . . . . . . . X Runqueue for O(1) Scheduler priority array 0 priority queue active priority queue expired priority array priority queue 1 priority queue

  7. Linux Real-time • No guarantees • SCHED_FIFO • Static priority, effectively higher than SCHED_OTHER processes* • No timeslice – it runs until it blocks or yields voluntarily • RR within same priority level • SCHED_RR • As above but with a timeslice. * Although their priority number ranges overlap

  8. Diversion: Synchronization • Disable Interrupts • Busywaiting solutions - spinlocks • execute a tight loop if critical section is busy • benefits from specialized atomic (read-mod-write) instructions • Blocking synchronization • sleep (enqueued on wait queue) while critical section is busy.

  9. Every processor has its own private runqueue Locking – spinlock protects runqueue Load balancing – pulls tasks from busiest runqueue into mine. Affinity – cpus_allowed bitmask constrains a process to particular set of processors load_balance runs from schedule( ) when runqueue is empty or periodically esp. during idle. Prefers to pull processes from expired, not cache-hot, high priority, allowed by affinity Support for SMP Symmetric mp P P P P $ $ $ $ Memory

  10. Lottery SchedulingWaldspurger and Weihl (OSDI 94)

  11. Claims • Goal: responsivecontrol over the relative rates of computation • Claims: • Support for modular resource management • Generalizable to diverse resources • Efficient implementation of proportional-share resource management: consumption rates of resources by active computations are proportional to relative shares allocated

  12. Basic Idea • Resource rights are represented by lottery tickets • abstract, relative (vary dynamically wrt contention), uniform (handle heterogeneity) • responsiveness: adjusting relative # tickets gets immediately reflected in next lottery • At allocation time: hold a lottery;Resource goes to the computation holding the winning ticket.

  13. Fairness • Expected allocation is proportional to # tickets held - actual allocation becomes closer over time. • Number of lotteries won by clientE[w] = n p where p = t/T • Response time (# lotteriesto wait for first win)E[n] = 1/p w # wins t # tickets T total # tickets n # lotteries

  14. Example List-based Lottery T = 20 5 2 1 10 2 12 Summing: 10 17 Random(0, 19) = 15

  15. Bells and Whistles • Ticket transfers - objects that can be explicitly passed in messages • Can be used to solve priority inversions • Ticket inflation • Create more - used among mutually trusting clients to dynamically adjust ticket allocations • Currencies - “local” control, exchange rates • Compensation tickets - to maintain share • use only fof quantum, ticket inflated by 1/f in next

  16. Kernel Objects Backing tickets Currency name amount 1000 base C_name currency Active amount 300 ticket Issued tickets

  17. base 3000 1000 base 2000 base 1 bob = 20 base 1 alice = 5 base alice bob 200 100 100 bob 200 alice 100 alice task1 1 task2= .4 alice = 2 base task3 0 100 task2 500 100 task1 300 task2 100 task3 200 task2 thread1 thread3 thread4 thread2

  18. base 3000 1000 base 2000 base 1 bob = 20 base 1 alice = 3.33 base alice bob 300 100 100 bob 200 alice 100 alice task1 1 task2= .4 alice = 1.33 base task3 100 100 task2 500 100 task1 300 task2 100 task3 200 task2 thread1 thread3 thread4 thread2

  19. Example List-based Lottery T = 3000 base 1 base 2bob 5 task3 2bob 10 task2 Random(0, 2999) = 1500

  20. Compensation • A holds 400 base, B holds 400 base • A runs full 100msec quantum,B yields at 20msec • B uses 1/5 allotted timeGets 400/(1/5) = 2000 base at each subsequent lottery for the rest of this quantum • a compensation ticket valued at 2000 - 400

  21. Ticket Transfer • Synchronous RPC between client and server • create ticket in client’s currency and send to server to fund it’s currency • on reply, the transfer ticket is destroyed

  22. Control Scenarios • Dynamic ControlConditionally and dynamically grant ticketsAdaptability • Resource abstraction barriers supported by currencies. Insulate tasks.

  23. UI • mktkt, rmtkt, mkcur, rmcur • fund, unfund • lstkt, lscur, fundx (shell)

  24. Relative Rate Accuracy

  25. Fairness Over Time

  26. Client-ServerQuery Processing Rates

  27. Controlling Video Rates

  28. Insulation

  29. Other Kinds of Resources • Claim: can be used for any resource where queuing is used • Control relative waiting times for mutex locks. • Mutex currency funded out of currencies of waiting threads • Holder gets inheritance ticket in addition to its own funding, passed on to next holder (resulting from lottery) on release. • Space sharing - inverse lottery, loser is victim(e.g. in page replacement decision, processor node preemption in MP partitioning)

  30. Waiting thread Waiting thread 1 1 Lock Funding t t lock 1 bt holding thread 1

  31. Waiting thread New holding thread 1 1 Lock Funding t lock 1 bt Old holding thread 1

  32. Mutex Waiting Times

More Related