i Outl ne for Today
Real time scheduling Advanced topics in scheduling
Real Ti me Schedul er s
Real-time schedulers must support regular, periodic execution of tasks (e.g., continuous media).
CPU Reservations
"I need to execute for X out of every Y units." Scheduler exercises admission control at reservation time: application must handle failure of a reservation request.
Proportional Share
"I need 1/n of resources"
Time Constraints
"Run this before my deadline at time T."
Assumpti ons
Tasks are periodic with constant interval between requests, Ti (request rate 1/Ti) Each task must be completed before the next request for it occurs Tasks are independent Run-time for each task is constant (max), Ci Any non-periodic tasks are special
Task M odel
C1 = 1 t t
1
Ti
2
Ti T2 C2 = 1
time
Defi ni ti ons
Deadline is time of next request Overflow at time t if t is deadline of unfulfilled request Feasible schedule - for a given set of tasks, a scheduling algorithm produces a schedule so no overflow ever occurs. Critical instant for a task - time at which a request will have largest response time.
Occurs when task is requested simultaneously with all tasks of higher priority
Rate M onotoni c
Assign priorities to tasks according to their request rates, independent of run times Optimal in the sense that no other fixed priority assignment rule can schedule a task set which can not be scheduled by rate monotonic. If feasible (fixed) priority assignment exists for some task set, rate monotonic is feasible for that task set.
Ear l i est Deadl i ne Fi r st
Dynamic algorithm Priorities are assigned to tasks according to the deadlines of their current request With EDF there is no idle time prior to an overflow For a given set of m tasks, EDF is feasible iff C1/T1 + C2/T2 + ... + Cm/Tm 1 If a set of tasks can be scheduled by any algorithm, it can be scheduled by EDF
Pr opor ti onal Shar e
Goals: to integrate real-time and non-real-time tasks, to police ill-behaved tasks, to give every process a well-defined share of the processor. Each client, i, gets a weight wi Instantaneous share fi (t) = wi /(P wj )
j A(t)
Service time (fi constant in interval) Si(t0, t1) = fi (t) Pt > Set of active clients varies - fi varies over time t
1
Si(t0 , t1) =
t0
fi (P) dP
A Ri al to Schedul e
Rialto schedules constrained tasks according to a static task graph. For each base period, pick a path from root to a leaf.
At each visited node, execute associated task for specified time t.
Visit subsequent leaves in subsequent base periods. Modify the schedule only at request time.
4 2
free slots
start
3
1 2 1 5 3
Time
Common Pr opor ti onal Shar e Competi tor s
Weighted Round Robin RR with quantum times equal to share RR: WRR: Fair Share adjustments to priorities to reflect share allocation (compatible with multilevel feedback algorithms) 20 30
Linux
20
10
Common Pr opor ti onal Shar e Competi tor s
Weighted Round Robin RR with quantum times equal to share RR: WRR: Fair Share adjustments to priorities to reflect share allocation (compatible with multilevel feedback algorithms) 20 10
Linux
10
10
Common Pr opor ti onal Shar e Competi tor s
Weighted Round Robin RR with quantum times equal to share RR: WRR: Fair Share adjustments to priorities to reflect share allocation (compatible with multilevel feedback algorithms) 10
Linux
10
0
Common Pr opor ti onal Shar e Competi tor s
Fair Queuing
Weighted Fair Queuing Stride scheduling
VT Virtual Time advances at a rate proportional to share 2/3 2/2 1/1 VTA(t) = WA(t) / SA t VFT Virtual Finishing Time: VT a client would have after executing its next time quantum VFT = 3/3 WFQ schedules by smallest VFT VFT = 3/2 EA never below -1 VFT = 2/1
L otter y Schedul i ng
Lottery scheduling technique.
[Waldspurger96]
is another scheduling
Elegant approach to periodic execution, priority, and proportional resource allocation.
Give Wp "lottery tickets" to each process p. GetNextToRun selects "winning ticket" randomly. If Wp = N, then each process gets CPU share
Wp/N ... ...probabilistically, and over a sufficiently long
time interval.
Flexible: tickets are transferable to allow application-level adjustment of CPU shares. Simple, clean, fast.
Random choices are often a simple and efficient way to produce the desired overall behavior (probabilistically).
L otter y Schedul i ng
Wal dspur ger and Wei hl (OSDI 94) Goal: responsive control over the relative rates of computation Claims: Support for modular resource management Generalizable to diverse resources Efficient implementation of proportionalshare resource management: consumption rates of resources by active computations are proportional to relative shares allocated
Basi c I dea
Resource rights are represented by lottery tickets
Give Wp "lottery tickets" to each process p. 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.
GetNextToRun selects "winning ticket" randomly..
Fai r ness
Expected allocation is proportional to # tickets held - actual allocation becomes closer over time. Number of lotteries won by client E[w] = n p where p = t/T Response time (# lotteries w # wins t # tickets to wait for first win) T total # tickets E[n] = 1/p
n # lotteries
Exampl e L i st-based L otter y
T = 20 10 Summing: 10 2 12 5 17 1 2
Random(0, 19) = 15
Bel l s and Whi stl es
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 f of quantum, ticket inflated by 1/f in next
Ker nel Objects
1000 base ticket amount currency C_name 300
Backing tickets Currency name Active amount
Issued tickets
base
1000 base
3000 2000 base
Exchange rate: 1 bob = 20 base
100 bob
alice
200 100 alice 200 alice
bob
100
task1
0 100 task1
task3 task2
200 task2 500 300 task2 100 task3
100
thread1 thread2
thread3
thread4
Exampl e L i st-based L otter y
T = 3000 base 10 task2 2bob 5 task3 1 base 2bob
Random(0, 2999) = 1500
Compensati on
A holds 400 base, B holds 400 base A runs full 100msec quantum, B yields at 20msec B uses 1/5 allotted time Gets compensation ticket valued at 400/(1/5) = 2000 base at next lottery
Ti cket Tr ansfer
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
Contr ol Scenar i os
Dynamic Control Conditionally and dynamically grant tickets Adaptability Resource abstraction barriers supported by currencies. Insulate tasks.
Other Ki nds of Resour ces
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.
Schedul i ng: Beyond "Or di nar y" Uni pr ocessor s
Multiprocessors
Co-scheduling and gang scheduling Hungry puppy task scheduling Load balancing
Networks of Workstations
Harvesting Idle Resources - remote execution and process migration
Laptops and mobile computers
Power management to extend battery life, scaling processor speed/voltage to tasks at hand, sleep and idle modes.
RR and System Thr oughput
On a multiprocessor, RR may improve throughput under light load:
The scenario: three salmon steaks must cook for 5 minutes per side, but there's only room for two steaks on the hibachi.
30 minutes worth of grill time needed: steaks 1, 2, 3 with sides A and B.
FCFS: steaks 1 and 2 for 10 minutes, steak 3 for 10 1 2 2 minutes. 1
Completes in 20 minutes with grill utilization a measly 75%.
1
2
RR and System Thr oughput
RR: 1A and 2A...flip...1B and 3A...flip...2B 3B.
Completes and in three quanta (15 minutes) with 100% utilization.
RR may speed up parallel programs if their inherent parallelism is poorly matched to the real parallelism.
E.g., 17 threads execute for N time units on 16 processors.
1 1
2 1
2 2
M ul ti pr ocessor Schedul i ng
What makes the problem different? Workload consists of parallel programs
Multiple processes or threads, synchronized and communicating Latency defined as last piece to finish.
Time-sharing and/or Space-sharing
(partitioning up the Mp nodes) Both when and where a process should run
Ar chi tectur es
Symmetric mp
P $ P $ P $ P $ P $
NUMA Node 0
Mem CA Interconnect $ $ CA Mem
Node 1
Mem CA CA Mem P $
Memory
P
P
Node 2
Node 3
cluster
Effect of Wor kl oad
Impact of load-balancing on latency Consider set of processes: 5, 5, 4, 4, 3, 3 3 processors If unrelated: (SJF)
avg response time = (3 + 3 + 4 + 7 + 8 + 9)/6 = 5.66 avg response time (SPF) = (8 + 9)/2 = 8.5 avg response time (LPF) = (8 + 8)/2 = Red done 8
If 2 tasks, each 5, 4, 3 (no dependencies)
Blue done
Affi ni ty Schedul i ng
Where (on which node) to run a particular thread during the next time slice? Processor's POV: favor processes which have some residual state locally (e.g. cache) What is a useful measure of affinity for deciding this?
Least intervening time or intervening activity (number of processes here since "my" last time) * Same place as last time "I" ran. Possible negative effect on load-balance.
Pr ocessor Par ti ti oni ng
Static or Dynamic Process Control (Gupta)
Vary number of processors available Match number of processes to processors Adjusts # at runtime. Works with task-queue or threads programming model Impact on "working set"
Pr ocess Contr ol Cl ai ms
Typi cal speed-up pr ofi l e
||ism and working set in memory Lock contention, memory contention, context switching, cache corruption
speedup
Magic point
Number of processes per application
Co-Schedul i ng
John Ousterhout (Medusa OS) Time-sharing model Schedule related threads simultaneously Why? How?
Local scheduling decisions after some global initialization (Medusa) Centralized (SGI IRIX)
Effect of Wor kl oad
Impact of communication and cooperation
Issues:
-context switch +common state -lock contention +coordination
CM * 's Ver si on
Matrix S (slices) x P (processors) Allocate a new set of processes (task force) to a row with enough empty slots Schedule: Round robin through rows of matrix
If during a time slice, this processor's element is empty or not ready, run some other task force's entry in this column - backward in time (for affinity reasons and purely local "fall-back" decision)
Desi gn
Determining how many processors an application should have
Centralized server, with system calls for process status info (user-level) (kernel implementation would be desirable, but...)
Controlling the number of processes in an application
suspend and resume are responsibility of runtime package of application
Networ ks of Wor kstati ons
What makes the problem different?
Exploiting otherwise "idle" cycles. Notion of ownership associated with workstation. Global truth is harder to come by in wide area context
H ar vesti ng I dl e Cycl es
Remote execution on an idle processor in a NOW (network of workstations)
Finding the idle machine and starting execution there. Related to load-balancing work.
Vacating the remote workstation when its user returns and it is no longer idle
Process migration
41
I ssues
Why? Which tasks are candidates for remote execution? Where to find processing cycles? What does "idle" mean? When should a task be moved? How?
M oti vati on for Cycl e Shar i ng
Load imbalances. Parallel program completion time determined by slowest thread. Speedup limited. Utilization. In trend from shared mainframe to networks of workstations - scheduled cycles > to statically allocated cycles
"Ownership" model Heterogeneity
Whi ch Tasks?
Explicit submission to a "batch" scheduler (e.g., Condor) or Transparent to user. Should be demanding enough to justify overhead of moving elsewhere. Properties? Proximity of resources.
Example: move query processing to site of database records. Cache affinity
Start here
Fi ndi ng Desti nati on
Defining "idle" workstations
Keyboard/mouse events? CPU load?
How timely and complete is the load information (given message transit times)?
Global view maintained by some central manager with local daemons reporting status. Limited negotiation with a few peers How binding is any offer of free cycles?
Task requirements must match machine capabilities
When to M ove
At task invocation. Process is created and run at chosen destination. Process migration, once task is already running at some node. State must move.
For adjusting load balance (gen...