Online Scheduling for Realtime. Rate Monotonic Analysis: Assumptions. Schedulability Test. EECS 262a Advanced Topics in Computer Systems Lecture 13

Transcription

1 EECS 262a Advanced Topcs n Computer Systems Lecture 13 Onlne Schedulng for Realtme M-CBS(Con t) and DRF October 10 th, 2012 John Kubatowcz and Anthony D. Joseph Electrcal Engneerng and Computer Scences Unversty of Calforna, Berkeley 2 Schedulablty Test Test to determne whether a feasble schedule exsts Suffcent Test If test s passed, then tasks are defntely schedulable If test s not passed, tasks may be schedulable, but not necessarly Necessary Test If test s passed, tasks may be schedulable, but not necessarly If test s not passed, tasks are defntely not schedulable Exact Test (= Necessary + Suffcent) The task set s schedulable f and only f t passes the test. Rate Monotonc Analyss: Assumptons A1: Tasks are perodc (actvated at a constant rate). Perod P = Intervall between two consequtve actvatons of task T A2: All nstances of a perodc task T have the same computaton tme C A3: All nstances of a perodc task T have the same relatve deadlne, whch s equal to the perod( D P ) A4: All tasks are ndependent (.e., no precedence constrants and no resource constrants) Implct assumptons: A5: Tasks are preemptable A6: No task can suspend tself A7: All tasks are released as soon as they arrve A8: All overhead n the kernel s assumed to be zero (or part of C ) 3 4

2 Rate Monotonc Schedulng: Prncple Prncple: Each process s assgned a (unque) prorty based on ts perod (rate); always execute actve job wth hghest prorty The shorter the perod the hgher the prorty P P j j ( 1 = low prorty) W.l.o.g. number the tasks n reverse order of prorty Process Perod Prorty Name A 25 5 T1 B 60 3 T3 C 42 4 T2 D T5 E 75 2 T4 5 Example: Rate Monotonc Schedulng Example nstance RMA - Gant chart 6 Example: Rate Monotonc Schedulng Deadlne Mss T ( P, C ) P perod C processng tme T (4,1) 1 T 2 (5,2) T (7,2) response tme of job J 3,1 Utlzaton C U Utlzaton of task P T (4,1) 1 T 2 (5,2) T (7,2) T 2 Example: U

3 RMS: Schedulablty Test Theorem (Utlzaton-based Schedulablty Test): A perodc task set T, T, 1 2, T n wth D P, 1 n, s schedulable by the rate monotonc schedulng algorthm f n 1 Ths schedulablty test s suffcent! For harmonc perods ( evenly dvdes ), the utlzaton bound s n (2 C P 1/ n n(2 1/ n 1) ln 2 for 1), n 1,2, T j n T RMS Example T1 ( 4,1), T2 (5,2), T3 (7,2) C1 C2 C , , P P P 1 The schedulablty test requres n 1 C n(2 P Hence, we get 3 C (2 1 P 2 1/ n 1), n 1,2, 1/3 3 does not satsfy schedulablty condton 1) EDF: Assumptons A1: Tasks are perodc or aperodc. Perod P = Interval between two consequtve actvatons of task T A2: All nstances of a perodc task T have the same computaton tme C A3: All nstances of a perodc task T have the same relatve deadlne, whch s equal to the perod( D P ) A4: All tasks are ndependent (.e., no precedence constrants and no resource constrants) Implct assumptons: A5: Tasks are preemptable A6: No task can suspend tself A7: All tasks are released as soon as they arrve A8: All overhead n the kernel s assumed to be zero (or part of C ) EDF Schedulng: Prncple Preemptve prorty-based dynamc schedulng Each task s assgned a (current) prorty based on how close the absolute deadlne s. The scheduler always schedules the actve task wth the closest absolute deadlne. T 1 (4,1) T 2 (5,2) T 3 (7,2)

4 EDF: Schedulablty Test Theorem (Utlzaton-based Schedulablty Test): A task set T 1, T2,, T n wth D P s schedulable by the earlest deadlne frst (EDF) schedulng algorthm f n 1 C D 1 EDF Optmalty EDF Propertes EDF s optmal wth respect to feasblty (.e., schedulablty) EDF s optmal wth respect to mnmzng the maxmum lateness Exact schedulablty test (necessary + suffcent) Proof: [Lu and Layland, 1973] EDF Example: Domno Effect Constant Bandwdth Server Intuton: gve fxed share of to certan of jobs Good for tasks wth probablstc resource requrements Basc approach: Slots (called servers ) scheduled wth EDF, rather than jobs CBS Server defned by two parameters: Q s and T s Mechansm for trackng processor usage so that no more than Q s seconds used every T s seconds (or whatever measurement you lke) when there s demand. Otherwse get to use processor as you lke Snce usng EDF, can mx hard-realtme and soft realtme: EDF mnmzes lateness of the most tardy task [Dertouzos, 1974] Frank Drews Real-Tme Systems 15 16

5 Today s Papers Implementng Constant-Bandwdth Servers upon Multprocessor Platforms Sanjoy Baruah, Jo el Goossens, and Guseppe Lpar. Appears n Proceedngs of Real-Tme and Embedded Technology and Applcatons Symposum, (RTAS), (From Last Tme!) Domnant Resource Farness: Far Allocaton of Multple Resources Types, A. Ghods, M. Zahara, B. Hndman, A. Konwnsk, S. Shenker, and I. Stoca, Usenx NSDI 2011, Boston, MA, March 2011 Thoughts? CBS on multprocessors Basc problem: EDF not all that effcent on multprocessors. Schedulablty constrant consderably less good than for unprocessors. Need: Key dea of paper: send hghest-utlzaton jobs to specfc processors, use EDF for rest Mnmzes number of processors requred New acceptance test: Is ths a good paper? What were the authors goals? What about the evaluaton/metrcs? Dd they convnce you that ths was a good system/approach? Were there any red-flags? What mstakes dd they make? Does the system/approach meet the Test of Tme challenge? How would you revew ths paper today? What s Far Sharng? n users want to share a resource (e.g., ) Soluton: Allocate each 1/n of the shared resource Generalzed by max-mn farness Handles f a user wants less than ts far share E.g. user 1 wants no more than 2 Generalzed by weghted max-mn farness Gve weghts to users accordng to mportance User 1 gets weght 1, user 2 weght

6 Why s Far Sharng Useful? Propertes of Max-Mn Farness Weghted Far Sharng / Proportonal Shares User 1 gets weght 2, user 2 weght 1 Share guarantee Each user can get at least 1/n of the resource But wll get less f her demand s less Prortes Gve user 1 weght 1000, user 2 weght 1 Revervatons Ensure user 1 gets 1 of a resource Gve user 1 weght 10, sum weghts 100 Isolaton Polcy Users cannot affect others beyond ther far share Strategy-proof Users are not better off by askng for more than they need Users have no reason to le Max-mn farness s the only reasonable mechansm wth these two propertes Why Care about Farness? Desrable propertes of max-mn farness Isolaton polcy: A user gets her far share rrespectve of the demands of other users Flexblty separates mechansm from polcy: Proportonal sharng, prorty, reservaton,... When s Max-Mn Farness not Enough? Need to schedule multple, heterogeneous resources Example: Task schedulng n datacenters» Tasks consume more than just, memory, dsk, and I/O What are today s datacenter task demands? Many schedulers use max-mn farness Datacenters: Hadoop s far sched, capacty, Quncy OS: rr, prop sharng, lottery, lnux cfs,... Networkng: wfq, wf2q, sfq, drr, csfq,

7 Heterogeneous Resource Demands Some tasks are -ntensve Most task need ~ <2, 2 GB RAM> Some tasks are memory-ntensve 2000-node Hadoop Cluster at Facebook (Oct 2010) 25 Problem Sngle resource example 1 resource: User 1 wants <1 > per task User 2 wants <3 > per task Mult-resource example 2 resources: s & memory User 1 wants <1, 4 GB> per task User 2 wants <3, 1 GB> per task What s a far allocaton? mem 26?? Demands at Facebook Problem defnton How to farly share multple resources when users have heterogeneous demands on them? 27 28

8 Model A Natural Polcy: Asset Farness Users have tasks accordng to a demand vector e.g. <2, 3, 1> user s tasks need 2 R 1, 3 R 2, 1 R 3 Not needed n practce, can smply measure actual consumpton Resources gven n multples of demand vectors Assume dvsble resources Asset Farness Equalze each user s sum of resource shares Problem Cluster wth 70 s, 70 GB RAM User 1 has < of both s and RAM U 1 needs <2, 2 GB RAM> per task Better off U 2 n needs a separate <1, cluster 2 GB wth RAM> per of task the resources Asset farness yelds U 1 : 15 tasks: 30 s, 30 GB ( =60) U 2 : 20 tasks: 20 s, 40 GB ( =60) User 1 User RAM Share Guarantee Desrable Far Sharng Propertes Every user should get 1/n of at least one resource Intuton: You shouldn t be worse off than f you ran your own cluster wth 1/n of the resources Many desrable propertes Share Guarantee Strategy proofness Envy-freeness Pareto effcency Sngle-resource farness Bottleneck farness Populaton monotoncty Resource monotoncty DRF focuses on these propertes 31 32

9 Cheatng the Scheduler Some users wll game the system to get more resources Real-lfe examples A cloud provder had quotas on map and reduce slots Some users found out that the map-quota was low» Users mplemented maps n the reduce slots! A search company provded dedcated machnes to users that could ensure certan level of utlzaton (e.g. 8)» Users used busy-loops to nflate utlzaton Two Important Propertes Strategy-proofness A user should not be able to ncrease her allocaton by lyng about her demand vector Intuton:» Users are ncentvzed to make truthful resource requrements Envy-freeness No user would ever strctly prefer another user s lot n an allocaton Intuton:» Don t want to trade places wth any other user Challenge A far sharng polcy that provdes Strategy-proofness Share guarantee Max-mn farness for a sngle resource had these propertes Generalze max-mn farness to multple resources Domnant Resource Farness A user s domnant resource s the resource she has the bggest share of Example: Total resources: <10, 4 GB> User 1 s allocaton: <2, 1 GB> Domnant resource s memory as 1/4 > 2/10 (1/5) A user s domnant share s the fracton of the domnant resource she s allocated User 1 s domnant share s 25 (1/4) 35 36

10 Domnant Resource Farness (2) Apply max-mn farness to domnant shares Equalze the domnant share of the users Example: Total resources: User 1 demand: User 2 demand: <9, 18 GB> <1, 4 GB> domnant res: mem <3, 1 GB> domnant res: 3 s 12 GB User 1 DRF s Far DRF s strategy-proof DRF satsfes the share guarantee DRF allocatons are envy-free See DRF paper for proofs 66 User s 2 GB mem (9 total) (18 total) Onlne DRF Scheduler Whenever there are avalable resources and tasks to run: Schedule a task to the user wth smallest domnant share O(log n) tme per decson usng bnary heaps Need to determne demand vectors Alternatve: Use an Economc Model Approach Set prces for each good Let users buy what they want How do we determne the rght prces for dfferent goods? Let the market determne the prces Compettve Equlbrum from Equal Incomes (CEEI) Gve each user 1/n of every resource Let users trade n a perfectly compettve market Not strategy-proof! 39 40

11 Determnng Demand Vectors They can be measured Look at actual resource consumpton of a user DRF vs CEEI User 1: <1, 4 GB> User 2: <3, 1 GB> DRF more far, CEEI better utlzaton They can be provded the by user What s done today Domnant Resource Farness Compettve Equlbrum from Equal Incomes Domnant Resource Farness Compettve Equlbrum from Equal Incomes In both cases, strategy-proofness ncentvzes user to consume resources wsely user 1 user mem mem mem User 1: <1, 4 GB> User 2: <3, 2 GB> User 2 ncreased her share of both and memory mem 42 Gamng Utlzaton-Optmal Schedulers Example of DRF vs Asset vs CEEI Cluster wth <100, 100 GB> 2 users, each demandng <1, 2 GB> per task Resources <1000 s, 1000 GB> 2 users A: <2, 3 GB> and B: <5, 1 GB> User 1 User 2 95 User A User B mem mem User 1 les and demands <2, 2 GB> Utlzaton-Optmal scheduler prefers user 1 Mem Mem Mem 43 a) DRF b) Asset Farness c) CEEI 44

12 Max/mn Theorem for DRF A user U has a bottleneck resource R j n an allocaton A ff R j s saturated and all users usng R j have a smaller (or equal) domnant share than U Max/mn Theorem for DRF An allocaton A s max/mn far ff every user has a bottleneck resource Desrable Farness Propertes (1) Recall max/mn farness from networkng Maxmze the bandwdth of the mnmum flow [Bert92] Progressve fllng (PF) algorthm 1. Allocate ε to every flow untl some lnk saturated 2. Freeze allocaton of all flows on saturated lnk and goto Desrable Farness Propertes (2) P1. Pareto Effcency» It should not be possble to allocate more resources to any user wthout hurtng others P2. Sngle-resource farness» If there s only one resource, t should be allocated accordng to max/mn farness Desrable Farness Propertes (3) Assume postve demands (D j > 0 for all and j) DRF wll allocate same domnant share to all users As soon as PF saturates a resource, allocaton frozen P3. Bottleneck farness» If all users want most of one resource(s), that resource should be shared accordng to max/mn farness 47 48

13 Desrable Farness Propertes (4) Propertes of Polces P4. Populaton Monotoncty If a user leaves and relnqushes her resources, no other user s allocaton should get hurt Can happen each tme a job fnshes CEEI volates populaton monotoncty DRF satsfes populaton monotoncty Assumng postve demands Intutvely DRF gves the same domnant share to all users, so all users would be hurt contradctng Pareto effcency Property Asset CEEI DRF Share guarantee Strategy-proofness Pareto effcency Envy-freeness Sngle resource farness Bottleneck res. farness Populaton monotoncty Resource monotoncty Evaluaton Methodology DRF Insde Mesos on EC2 Mcro-experments on EC2 Evaluate DRF s dynamc behavor when demands change Compare DRF wth current Hadoop scheduler Macro-benchmark through smulatons Smulate Facebook trace wth DRF and current Hadoop scheduler Domnant resource s memory Domnant resource s Domnant shares are equalzed Share guarantee: User 1 s Shares User 2 s Shares Domnant Shares 51 ~7 domnant share 52

14 Farness n Today s Datacenters Experment: DRF vs Slots Number of Type 1 Jobs Fnshed Hadoop Far Scheduler/capacty/Quncy Each machne conssts of k slots (e.g. k=14) Run at most one task per slot Gve jobs equal number of slots,.e., apply max-mn farness to slot-count Ths s what DRF paper compares aganst Jobs fnshed Jobs fnshed Thrashng Number of Type 2 Jobs Fnshed Low utlzaton Thrashng 53 Type 1 jobs <2, 2 GB> Type 2 jobs <1, 0.5GB> 54 Experment: DRF vs Slots Completon Tme of Type 1 Jobs Job completon tme Thrashng Reducton n Job Completon Tme DRF vs Slots Smulaton of 1-week Facebook traces Job completon tme Completon Tme of Type 2 Jobs Low utlzaton hurts performance Thrashng 10/10/2012 Type 1 job <2, cs262a-s12 2 GB> Lecture-13 Type 2 job <1, 0.5GB> 55 56

15 Utlzaton of DRF vs Slots Smulaton of Facebook workload Summary DRF provdes multple-resource farness n the presence of heterogeneous demand Frst generalzaton of max-mn farness to multple-resources DRF s propertes Share guarantee, at least 1/n of one resource Strategy-proofness, lyng can only hurt you Performs better than current approaches alg@cs.berkeley.edu Is ths a good paper? What were the authors goals? What about the evaluaton/metrcs? Dd they convnce you that ths was a good system/approach? Were there any red-flags? What mstakes dd they make? Does the system/approach meet the Test of Tme challenge? How would you revew ths paper today? 59