Presentation is loading. Please wait.

Presentation is loading. Please wait.

Scalably Verifiable Dynamic Power Management Opeoluwa (Luwa) Matthews, Meng Zhang, and Daniel J. Sorin Duke University HPCA-20 Orlando, FL, February 19,

Similar presentations


Presentation on theme: "Scalably Verifiable Dynamic Power Management Opeoluwa (Luwa) Matthews, Meng Zhang, and Daniel J. Sorin Duke University HPCA-20 Orlando, FL, February 19,"— Presentation transcript:

1 Scalably Verifiable Dynamic Power Management Opeoluwa (Luwa) Matthews, Meng Zhang, and Daniel J. Sorin Duke University HPCA-20 Orlando, FL, February 19, 2014

2 Dynamic Power Management (DPM) used to improve power- efficiency at several levels of computing stack -within multicore chip, across servers in datacenter, etc. Deploying DPM scheme risky if not fully verified -difficult to verify scheme for large-scale systems Our contribution: Fractal DPM -framework for designing scalably verifiable DPM -implement Fractal DPM on 2-chip (16-core) system -experimental evaluation on real system Executive Summary HPCA-20 Orlando, FL, February 19, 2014

3 DPM aims to: -dynamically allocate power to computing resources (e.g. cores, chips, servers, etc.) -attain best performance at given power budget -achieve lowest power consumption for desired performance n cores in CMP … DPM Request Power grant deny Dynamic Power Management HPCA-20 Orlando, FL, February 19, 2014

4 … … DPM Request Power grant deny n machines in datacenter Dynamic Power Management DPM aims to: -dynamically allocate power to computing resources (e.g. cores, chips, servers, etc.) -attain best performance at given power budget -achieve lowest power consumption for desired performance HPCA-20 Orlando, FL, February 19, 2014

5 [Hennessy and Patterson Computer Architecture] Chips have hit power density ceiling Case for Dynamic Power Management HPCA-20 Orlando, FL, February 19, 2014

6 [hp.com] Reducing cloud electricity consumption by half saves as much as UK consumes Datacenters consume increasing amounts of power Case for Dynamic Power Management Cloud map of UK HPCA-20 Orlando, FL, February 19, 2014

7 Case for Verifiable DPM Want formal verification - prove correctness for all possible DPM allocations - guarantee safety of DPM scheme DPM can greatly improve energy efficiency Unverified DPM could -overshoot power budget  system damage -underutilize resources -deadlock HPCA-20 Orlando, FL, February 19, 2014

8 CMPs and datacenters have many computing resources S power states per CR + S n possible DPM states Why Scalably Verifiable DPM is Hard n computing resources (CR) Checking S n states is intractable for typical values of S and n HPCA-20 Orlando, FL, February 19, 2014

9 Hypothesis and Assumptions Problem: verification of existing DPM protocols is unscalable Hypothesis: We can design DPM such that it is scalably verifiable -key idea: design DPM amenable to inductive verification -change architecture to match verification methodologies Approach: -abstract away details of computing resources -abstract power states – e.g. Medium power -focus on decision policy (not mechanism e.g. DVFS) HPCA-20 Orlando, FL, February 19, 2014

10 Outline Background and Motivation Fractal DPM Experimental Evaluation Conclusions HPCA-20 Orlando, FL, February 19, 2014

11 Our Inductive Approach Induction key to scalable verification  can prove DPM correct for arbitrary number of computing resources Base case: small scale system with few CRs is correct - small enough that it’s easy to verify with existing tools Inductive step: system behaves the same at every scale  fractal behavior Prove base case + prove inductive step  DPM scheme is correct for any number of CRs Approach more general than DPM, borrowed from prior work on coherence protocols [Zhang 2010] HPCA-20 Orlando, FL, February 19, 2014

12 Attaining Scalable Verification -base case of induction CRs request power from DPM controller DPM controller grants or denies each request Few states  easy to verify that DPM is correct note: over-simplified base case for now Request Power Grant/Deny DPM-C CR HPCA-20 Orlando, FL, February 19, 2014

13 CR DPM-C CR Root DPM-C Base Case -Refine our base case a little -Need all types of structures: CR, DPM-C, Root DPM-C Attaining Scalable Verification -base case of induction HPCA-20 Orlando, FL, February 19, 2014

14 behavior must be fractal Request Power Grant/Deny DPM-C CR Attaining Scalable Verification -inductive step HPCA-20 Orlando, FL, February 19, 2014

15 Request Power Grant/Deny DPM-C CR Request Power Grant/Deny DPM-C CR can scale system by replacing CR with larger system {DPM-C + 2 CRs} “behaves just like” 1 CR  observational equivalence Attaining Scalable Verification -inductive step HPCA-20 Orlando, FL, February 19, 2014

16 1) “Looking-down” equivalence check Attaining Scalable Verification -observational equivalence Inductive Step – Two Observational Equivalences Observed externally from P1, A and A’ behave same Small System Large System A A’ P1 HPCA-20 Orlando, FL, February 19, 2014

17 By induction, protocol correct for all scales 2) “Looking-up” equivalence check Attaining Scalable Verification -observational equivalence Inductive Step – Two Observational Equivalences Observed externally from P2, B and B’ behave same Large System Small System B’ B P2 HPCA-20 Orlando, FL, February 19, 2014

18 CR can be in 1 of 5 power states: L(ow), LM, M(ed), MH and H(igh) Parent DPM controller “sees” child DPM controller in averaged state DPM controller state is : H L H:L L M:L M Fractal DPM Design Avg(H:L) = M HPCA-20 Orlando, FL, February 19, 2014

19 CR can be in 1 of 5 power states: L(ow), LM, M(ed), MH and H(igh) Parent DPM controller “sees” child DPM controller in averaged state DPM controller state is : Fractal DPM Design MH H MH:H L H:L H Avg(MH:H) = H HPCA-20 Orlando, FL, February 19, 2014

20 Fractal DPM Design -fractal invariant Fractal design + inductive proof  invariant must also be fractal - Invariant must apply at every scale of system - Not OK to specify, e.g., <75% of all CRs are in H state Our fractal invariant: children of DPM controller not both in H H H H:H L H:L H MH H:MH H H:H ILLEGAL H HPCA-20 Orlando, FL, February 19, 2014

21 Translating Fractal Invariant to System-Wide Cap We must have fractal invariant for fractal design But most people interested in system-wide invariants We prove (not shown) that our fractal invariant implies system- wide power cap Max power for n CRs is: (n-1)MH + H i.e., (n-1) CRs in state MH and one CR in state H HPCA-20 Orlando, FL, February 19, 2014

22 Fractal DPM Design -illustration CR requests MH H L L M:L H:L Req. MH HPCA-20 Orlando, FL, February 19, 2014

23 H L L M:L MH:L block Grant MH Fractal DPM Design -illustration CR requests MH Granting request doesn’t change controller’s Avg state Avg(H:L)=Avg(MH:L)=M Request Granted, doesn’t violate invariant Controller blocks waiting for ack HPCA-20 Orlando, FL, February 19, 2014

24 Fractal DPM Design -illustration CR sends ack to Controller MH L L M:L MH:L block ack CR sets its state HPCA-20 Orlando, FL, February 19, 2014

25 Fractal DPM Design -illustration Controller unblocks H L L M:L H:L HPCA-20 Orlando, FL, February 19, 2014

26 Computing Resource requests H Fractal DPM Design -illustration L L L L:L Req. H HPCA-20 Orlando, FL, February 19, 2014

27 Controller defers request to its parent -new request is M (not H) because Avg(H:L)=M CR requests H from its Controller Fractal DPM Design -illustration L L L L:L Req. M Req. H HPCA-20 Orlando, FL, February 19, 2014

28 Fractal DPM Design -illustration Root grants request to Controller, blocks L L L M:L L:L Grant M block HPCA-20 Orlando, FL, February 19, 2014

29 Controller grants request to CR, blocks Fractal DPM Design -illustration L L L M:L H:L Grant H block Grant M block HPCA-20 Orlando, FL, February 19, 2014

30 Fractal DPM Design -illustration acks percolate up tree from CR H L L M:L H:L ack block HPCA-20 Orlando, FL, February 19, 2014

31 Fractal DPM Design -illustration acks percolate up tree from CR H L L M:L H:L ack block Controllers unblock upon receiving ack ack HPCA-20 Orlando, FL, February 19, 2014

32 Fractal DPM Design -illustration acks percolate up tree from CR H L L M:L H:L Controllers unblock upon receiving ack HPCA-20 Orlando, FL, February 19, 2014

33 Use same model checker to verify observational equivalences - use prior aggregation method for equivalence check (Park, TCAD 2000) Use model checker to verify base case - we use well-known, automated Murphi model checker Verification Procedure HPCA-20 Orlando, FL, February 19, 2014

34 Outline Background and Motivation Fractal DPM Experimental Evaluation Conclusions HPCA-20 Orlando, FL, February 19, 2014

35 overshooting system-wide power cap Illegal: total power = 4MH Legal: total power = 4MH violates fractal invariant Our fractal invariant implies system-wide cap > n*MH MH MH:MH MH MH:MH M M M:H H H H:H M:M Violating fractal invariant Situations are few and don’t significantly degrade performance Experimental Evaluation -fractal inefficiency: cost of fractal behavior HPCA-20 Orlando, FL, February 19, 2014

36 Implemented Fractal DPM on 16-core linux system, 2 sockets -2 cores act as a CR -controllers communicate through UDP across sockets Experimental Evaluation -system model HPCA-20 Orlando, FL, February 19, 2014

37 Experimental Evaluation -experimental setup Power ModesLMLMMHH Freq. (GHz)1.42.12.73.33.6 Power Mode DVFS Mappings Entire system plugged into power meter (Wattsup?) HPCA-20 Orlando, FL, February 19, 2014

38 Experimental Evaluation -comparison schemes Static Scheme: - no DPM, set all CRs to the same power state (e.g. MH) - trivially correct, poor energy efficiency Oracle DPM: - allocates for optimal energy efficiency (ED 2 ) under budget - oracle doesn’t scale, unimplementable Optimized Fractal DPM (OptFractal): - CRs re-request lower power state when denied - no change to Fractal DPM decision algorithm HPCA-20 Orlando, FL, February 19, 2014

39 Experimental Evaluation Benchmarks: Details in the paper. HPCA-20 Orlando, FL, February 19, 2014

40 Results - compared to static scheme OptFractalDPM within 2% of Oracle DPM ED 2 savings FractalDPM within 8% of Oracle DPM ED 2 savings HPCA-20 Orlando, FL, February 19, 2014

41 Most power requests serviced within 1ms. - UDP packet round trip ~0.6ms Results - response latency HPCA-20 Orlando, FL, February 19, 2014

42 We show how a scalably verifiable DPM can be built Fractal behavior enables one-time verification for all scales Entire verification is done completely automated in model checker Fractal DPM achieves energy-efficiency close to optimal allocator Conclusions HPCA-20 Orlando, FL, February 19, 2014

43 Scalably Verifiable Dynamic Power Management Opeoluwa (Luwa) Matthews, Meng Zhang, and Daniel J. Sorin Duke University HPCA-20 Orlando, FL, February 19, 2014

44 Important: experiments must stress all Fractal DPM power modes Each CR repeatedly launches bodytrack (from PARSEC benchmark suite), under a range of predetermined duty cycles Under given duty cycle, CRs request power state that minimizes ED 2 Why rely on duty cycle, not just different benchmarks or phases? Stressing all Fractal DPM power modes  stressing DVFS states Without varying duty cycle, optimal ED 2 always under highest frequency for all benchmarks tried [Dhiman 2008] Predetermined set of duty cycles for launching bodytrack that directly maps to set of power modes (or DVFS state) Experiment constitutes running sequence of bodytrack jobs, randomly selecting duty cycles from predetermined set Benchmarks HPCA-20 Orlando, FL, February 19, 2014

45 Results % CDF Millions of time steps simulated % system performance loss For each time step, system perf = % system perf loss = * 100% HPCA-20 Orlando, FL, February 19, 2014

46 Results % CDF Millions of time steps simulated % system performance loss For each time step, system perf = % system perf loss = * 100% On 72.6% of time steps Fractal DPM ≡ Oracle DPM HPCA-20 Orlando, FL, February 19, 2014

47 Results % CDF Millions of time steps simulated % system performance loss For each time step, system perf = % system perf loss = * 100% On 99.9% of time steps Fractal DPM < 20% off from Oracle HPCA-20 Orlando, FL, February 19, 2014

48 Results % CDF Millions of time steps simulated % system performance loss For each time step, system perf = % system perf loss = * 100% Worst case, Fractal DPM < 36.4% off from Oracle HPCA-20 Orlando, FL, February 19, 2014


Download ppt "Scalably Verifiable Dynamic Power Management Opeoluwa (Luwa) Matthews, Meng Zhang, and Daniel J. Sorin Duke University HPCA-20 Orlando, FL, February 19,"

Similar presentations


Ads by Google