Create Presentation
Download Presentation

Download Presentation
## Fair Share Scheduling

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Fair Share Scheduling**Yiping Ding BMC Software Ethan Bolker UMass-Boston BMC Software CMG2000 Orlando, Florida December 13, 2000**Coming Attractions**• Scheduling for performance • Fair share semantics • Priority scheduling; conservation laws • Predicting transaction response time • Experimental evidence • Hierarchical share allocation • What you can take away with you Fair Share Scheduling**Strategy**• Tell the story with pictures when I can • Question/interrupt at any time, please • If you want to preserve the drama, don’t read ahead Fair Share Scheduling**Acknowledgements**• Jeff Buzen • Dan Keefe • Oliver Chen • Chris Thornley • Aaron Ball • Tom Larard • Anatoliy Rikun References • Conference proceedings (talk != paper) • www.bmc.com/patrol/fairshare www/cs.umb.edu/~eb/goalmode Fair Share Scheduling**Scheduling for Performance**• Administrator specifies performance goals • Response times: IBM OS/390 (not today) • Resource allocations (shares): Unix offerings from HP (PRM) IBM (WLM) Sun (SRM) • Operating system dispatches jobs in an attempt to meet goals Fair Share Scheduling**OS**Performance Goals response time report measure frequently update query workload Model complex scheduling software analytic algorithms fast computation Scheduling for Performance Fair Share Scheduling**Modeling**• Real system • Complex, dynamic, frequent state changes • Hard to tease out cause and effect • Model • Static snapshot, deals in averages and probabilities • Fast enlightening answers to “what if ” questions • Abstraction helps you understand real system Fair Share Scheduling**Shares**• Administrator specifies fractions of various system resources allocated to workloads: e.g. “Dataminer owns 30% of the CPU” • Resource: CPU cycles, disk access, memory, network bandwidth, number of processes,... • Workload: group of users, processes, applications, … • Precise meanings depend on vendor’s implementation Fair Share Scheduling**Workloads**• Batch • Jobs always ready to run (latent demand) • Known: job service time • Performance metric: throughput • Transaction • Jobs arrive at random, queue for service • Known: job service time and throughput • Performance metric: response time Fair Share Scheduling**CPU Shares**• Administrator gives workload w CPU share fw • Normalize shares so that w fw = 1 • w gets fraction fw of CPU time slices when at least one of its jobs is ready for service • Can it use more if competing workloads idle? No : think share = cap Yes : think share = guarantee Fair Share Scheduling**share f**dedicated system batch wkl throughput f Shares As Caps • Good for accounting (sell fraction of web server) • Available now from IBM, HP, soon from Sun • Straightforward: transaction wkl utilization u need f > u ! response time r r(1 u)/(f u) Fair Share Scheduling**Shares As Guarantees**• Good for performance + economy (production and development share CPU) • When all workloads are batch, guarantees are caps • IBM and Sun report tests of this case • confirm predictions • validate OS implementation • No one seems to have studied transaction workloads Fair Share Scheduling**Guarantees for Transaction Workloads**• May have share < utilization (!) • Large share is like high priority • Each workload’s response time depends on utilizations and shares of all other workloads • Our model predicts response times given shares Fair Share Scheduling**There’s No Such Thing As a Free Lunch**• High priority workload response time can be low only because someone else’s is high • Response time conservation law: Weighted average response time is constant, independent of priority scheduling scheme: workloads w wrw = C • For a uniprocessor, C = U/(1-U) • For queueing theory wizards: C is queue length Fair Share Scheduling**Two Workloads (Uniprocessor Formulas)**conservation law: (r1, r2 ) lies on the line r2 : workload 2 response time 1r1 + 2r2 = U/(1-U) r1 : workload 1 response time**Two Workloads(Uniprocessor Formulas)**r2 : workload 2 response time constraint resulting from workload 1 1r1 u1 /(1- u1 ) r1 : workload 1 response time**Two Workloads(Uniprocessor Formulas)**Workload 1 runs at high priority: V(1,2) = (s1 /(1- u1 ), s2 /(1- u1 )(1-U) ) r2 : workload 2 response time constraint resulting from workload 1 1r1 u1 /(1- u1 ) r1 : workload 1 response time**Two Workloads(Uniprocessor Formulas)** r2 : workload 2 response time 1r1 + 2r2 = U/(1-U) 2r2 u2 /(1- u2 ) V(2,1) r1 : workload 1 response time**Two Workloads(Uniprocessor Formulas)**V(1,2) = (s1 /(1- u1 ), s2 /(1- u1 )(1-U) ) r2 : workload 2 response time achievable region R 1r1 + 2r2 = U/(1-U) 2r2 u2 /(1- u2 ) V(2,1) 1r1 u1 /(1- u1 ) r1 : workload 1 response time**Three Workloads**• Response time vector (r1, r2, r3) lies on plane 1 r1 + 2 r2 + 3 r3 = C • We know a constraint for each workload w: w rw Cw • Conservation applies to each pair of wkls as well: 1 r1 + 2 r2 C12 • Achievable region has one vertex for each priority ordering of workloads: 3! = 6 in all • Hence its name: the permutahedron Fair Share Scheduling**Three Workload Permutahedron**3! = 6 vertices (priority orders) 23 - 2 = 6 edges (conservation constraints) 1r1 + 2r2 + 3r3 = C r3 V(1,2,3) V(2,1,3) r2 r1 Fair Share Scheduling**r3 : wkl 3 response time**r2 : wkl 2 response time r1 : wkl 1 response time Three Workload Benchmark IBM WLM u1= 0.15, u2 = 0.2, u3 = 0.4 vary f1, f2, f3 subject to f1 + f2 + f3 = 1, measure r1, r2, r3**Four Workload Permutahedron**4! = 24 vertices (priority orders) 24 - 2 = 14 facets (conservation constraints) Simplicial geometry and transportation polytopes, Trans. Amer. Math. Soc. 217 (1976) 138.**Response Time Conservation**• Provable in model assuming • Random arrivals, varying service times • Queue discipline independent of job attributes (fifo, class based priority scheduling, …) • Observable in our benchmarks • Can fail: shortest job first minimizes average response time • printer queues • supermarket express checkout lines Fair Share Scheduling**Predict Response Times From Shares**• Given shares f1 , f2 , f3 ,… we want to know vector V = r1 , r2 , r3 ,... of workload response times • Assume response time conservation: V will be a point in the permutahedron • What point? Fair Share Scheduling**Predict Response Times From Shares(Two Workloads)**• Reasonable modeling assumption: f1 = 1, f2 = 0 means workload 1 runs at high priority • For arbitrary shares: workload priority order is (1,2) with probability f1 (2,1) with probability f2 (probability = fraction of time) • Compute average workload response time: r1 = f1 (wkl 1 response at high priority) + f2 (wkl 1 response at low priority ) Fair Share Scheduling**in this picture**f1 2/3, f2 1/3 V(1,2) : f1 =1, f2 =0 V = f1 V(1,2) + f2 V(2,1) f2 r2 : workload 2 response time V(2,1) : f1 =0, f2 =1 f1 r1 : workload 1 response time Predict Response Times From Shares**Model Validation**IBM WLM u1= 0.24, u2 = 0.47 vary f1, f2 subject to f1 + f2 = 1, measure r1, r2**Conservation Confirmed**conservation law**shallow**steep Heavy vs. Light Workloads u1= 0.24, u2 = 0.47; u2 2 u1**Glitch?**strange WLM anomaly near f1 = f2 = 1/2 (reproducible)**Shares vs. Utilizations**• Remember: when shares are just guarantees f < u is possible for transaction workloads • Think: large share is like high priority • Share allocations affect light workloads more than heavy ones (like priority) • It makes sense to give an important light workload a large share Fair Share Scheduling**1**2 3 Three Transaction Workloads ??? • Three workloads, each with utilization 0.32 jobs/second 1.0 seconds/job = 0.32 = 32% • CPU 96% busy, so average (conserved) response time is 1.0/(10.96) = 25 seconds • Individual workload average response times depend on shares ??? ??? Fair Share Scheduling**1**sum 80.0 32.0 2 48.0 3 20.0 Three Transaction Workloads • Normalized f3 = 0.20 means 20% of the time workload 3 (development) would be dispatched at highest priority • During that time, workload priority order is (3,1,2) for 32/80 of the time, (3,2,1) for 48/80 • Probability( priority order is 312 ) = 0.20(32/80) = 0.08 Fair Share Scheduling**Three Transaction Workloads**• Formulas in paper in proceedings • Average predicted response time weighted by throughput 25 seconds (as expected) • Hard to understand intuitively • Software helps Fair Share Scheduling**The Fair Share Applet**• Screen captures on last and next slides from www.bmc.com/patrol/fairshare • Experiment with “what if” fair share modeling • Watch a simulation • Random virtual job generator for the simulation is the same one used to generate random real jobs for our benchmark studies Fair Share Scheduling**note change from 32%**Three Transaction Workloads**jobs currently on run queue**Simulation**When the Model Fails**• Real CPU uses round robin scheduling to deliver time slices • Short jobs never wait for long jobs to complete • That resembles shortest job first, so response time conservation law fails • At high utilization, simulation shows smaller response times than predicted by model • Response time conservation law yields conservative predictions Fair Share Scheduling**development**share 0.2 production share 0.8 x customer 2 share 0.6 x customer 1 share 0.4 x x Share Allocation Hierarchy • Workloads at leaves of tree • Shares are relative fractions of parent • Production gets 80% of resources Customer 1 gets 40% of that 80% • Users in development share 20% • Available for Sun/Solaris. IBM/Aix offers tiers. Fair Share Scheduling**development**share 0.2 production share 0.8 customer 2 share 0.6 customer 1 share 0.4 development share 0.2 customer 1 share 0.40.8 customer 2 share 0.6 0.8 Don’t Flatten the Tree! For transaction workloads, shares as guarantees: is not the same as: Fair Share Scheduling**customer1 customer2 development**share 32 48 20 /80 /80 response times tree11.1 8.1 55.8 Response Time Predictions flat23.2 14.2 37.6 Response times computed using formulas in the paper, implemented in the fairshare applet. Why does customer1 do so much better with hierarchical allocation? Fair Share Scheduling**customer1 customer2 development**share 32 48 20 /80 /80 response times tree11.1 8.1 55.8 Response Time Predictions flat23.2 14.2 37.6 Often customer1 competes just with development. When that happens he gets 80% of the CPU in tree mode, 32/(32+20) 60% in flat mode Customers do well when they pool shares to buy in bulk. Fair Share Scheduling**Fair Share Scheduling**• Batch and transaction workloads behave quite differently (and often unintuitively) when shares are guarantees • A model helps you understand share semantics • Shares are not utilizations • Shares resemble priorities • Response time is conserved • Don’t flatten trees • Enjoy the applet Fair Share Scheduling**Fair Share Scheduling**Yiping Ding BMC Software Ethan Bolker UMass-Boston BMC Software CMG2000 Orlando, Florida December 13, 2000