1 / 66

Luwa Matthews

Energy Security with Scalably Verifiable Dynamic Power Management. Daniel J. Sorin. Luwa Matthews. Meng Zhang. Duke University ECE. Case for Dynamic Power Management. Chips have hit power density ceiling. Source: Hennessy and Patterson Computer Architecture.

eric-hensley
Download Presentation

Luwa Matthews

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. Energy Security with ScalablyVerifiable Dynamic Power Management Daniel J. Sorin Luwa Matthews Meng Zhang Duke University ECE

  2. Case for Dynamic Power Management • Chips have hit power density ceiling Source: Hennessy and Patterson Computer Architecture

  3. Case for Dynamic Power Management • Datacenters consume increasing amounts of power Reducing cloud electricity consumption by half saves as much as UK consumes map of Europe Cloud Source: hp.com • DPM goal: maximize performance at fixed power budget

  4. Dynamic Power Management • DPM involves: • -dynamically adjusting power states – clock gating, DVFS, etc • -ensuring safety of power allocations to resources • DPM can be performed at several granularities • -cores, chips, racks, datacenters, etc. n cores in CMP DPM Request Power grant deny Request Power …

  5. Dynamic Power Management • DPM involves: • -dynamically adjusting power states – clock gating, DVFS, etc • -ensuring safety of power allocations to resources • DPM can be performed at several granularities • -cores, chips, racks, datacenters, etc. DPM grant deny Request Power Request Power nmachines in datacenter … …

  6. Case for Verifiable DPM • DPM can greatly improve energy efficiency • Unverified DPM could • -overshoot power budget – system damage • -underutilize resources • -deadlock • -not energy secure! • Want formal verification • - prove correctness for all possible DPM situations • - DPM correct in all situations  system is energy secure

  7. Why Scalably Verifiable DPM is Hard • CMPs and datacenters have many computing resources n computing resources (CR) S power states per CR Sn possible DPM states + • Checking Snstates is intractable for typical values of S and n

  8. 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 algorithm(not DVFS or power gating)

  9. Outline • Background and Motivation • Fractal DPM • Experimental Evaluation • Conclusions

  10. 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

  11. 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 DPM-C Request Power Grant/Deny CR CR

  12. Attaining Scalable Verification -inductive proof • Base Case • -Refine our base case a little • -Need all types of structures – CR, DPM-C, Root DPM-C Root DPM-C DPM-C CR CR CR

  13. Attaining Scalable Verification-inductive step • behavior must be fractal DPM-C Grant/Deny Request Power CR CR

  14. Attaining Scalable Verification-inductive step • can scale system by replacing CR with larger system DPM-C DPM-C Grant/Deny Request Power Request Power Grant/Deny • {DPM-C + 2 CRs} behaves just like 1 CR CR CR CR

  15. DPM Controller DPM Controller Grant/Deny Request Power Request Power Grant/Deny CR Observed externally, node behaves like a single CR CR CR

  16. Block State: P Request: R CR Requests R Parent GRANTS R CR sends ACK to Parent Parent DENIES R Ready State: P State: R State: P CR sends ACK to Parent START

  17. Child REQUESTSR State: P:X Request: R:X if Avg(P:X)=Avg(R:X) & R:X!=H:H if parent GRANTS Avg(R:X) if parent DENIES Avg(R:X) RequestAvg(R:X) from Parent Child sendsACK GRANTChild R Block Block State: P:X DENYChild R Block START GRANTChild R DENYChild R if R:X=H:H if Avg(P:X)!=Avg(R:X)

  18. Child REQUESTSR State: P:X Request: R:X if R:X!=H:H Child sendsACK GRANTChild R Block State: P:X DENYChild R Block START if R:X=H:H

  19. Attaining Scalable Verification-inductive proof • Inductive Step – Two Observational Equivalences “Looking-down” equivalence check P2 P1 Small System Large System A’ A Observed externally (from P1, P2), A and A’ behave same

  20. Attaining Scalable Verification-inductive proof • Inductive Step – Two Observational Equivalences “Looking-up” equivalence check Small System P1 P2 B’ B Large System Observed externally (from P1,P2), B and B’ behave same • By induction, protocol correct for all scales (Zhang, MICRO 2010)

  21. Fractal DPM Design • CR can be in 1 of 5 power states: L(ow), LM, M(ed), MH and H(igh) • DPM controller state is <Left Child State>:<Right Child State> • Parent DPM controller “sees” child DPM controller in averaged state Avg(H:L) = M M:L M L H:L L H

  22. Fractal DPM Design • CR can be in 1 of 5 power states: L(ow), LM, M(ed), MH and H(igh) • DPM controller state is <Left Child State>:<Right Child State> • Parent DPM controller “sees” child DPM controller in averaged state Avg(MH:H) = H H:L H L MH:H H MH

  23. 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 Hstate • Our fractal invariant: children of DPM controller not both in H H:L H:H H L H H:H H:MH H H H MH ILLEGAL ILLEGAL

  24. 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

  25. Fractal DPM Design -illustration • CR requests MH M:L L Req. MH H:L L H

  26. 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 M:L block • Controller blocks waiting for ack L MH:L Grant MH L H

  27. Fractal DPM Design -illustration • CR sets its state • CR sends ack to Controller M:L block L ack MH:L L MH

  28. Fractal DPM Design -illustration • Controller unblocks M:L L H:L L H

  29. Fractal DPM Design -illustration • Computing Resource requests H L:L L L:L Req. H L L

  30. Fractal DPM Design -illustration • CR requests H from its Controller • Controller defers request to its parent • -new request is M (not H) because Avg(H:L)=M L:L Req. M L L:L Req. H L L

  31. M:L L Final Controller LM:M Req. M GrntM Intermediary Controller M L:M Req. H Grnt H M L

  32. Fractal DPM Design -illustration • Root grants request to Controller, blocks block Grant M M:L L L:L L L

  33. Fractal DPM Design -illustration • Controller grants request to CR, blocks block Grant M M:L block L H:L Grant H L L

  34. Fractal DPM Design -illustration • ackspercolate up tree from CR block M:L block L H:L ack L H

  35. Fractal DPM Design -illustration • ackspercolate up tree from CR • Controllers unblock upon receiving ack block ack M:L L H:L ack L H

  36. Fractal DPM Design -illustration • ackspercolate up tree from CR • Controllers unblock upon receiving ack M:L L H:L L H

  37. Verification Procedure • Use model checker to verify base case • - we use well-known, automated Murphimodel checker • Use same model checker to verify observational equivalences • - use prior aggregation method for equivalence check • (Park, TCAD 2000)

  38. Outline • Background and Motivation • Fractal DPM • Experimental Evaluation • Conclusions

  39. Experimental Evaluation -characterizing performance • Goal of DPM is optimize performance • Per allocation perf = f(requested power, allocated power) ? • Might vary with implementation, we want abstraction

  40. Experimental Evaluation -characterizing performance • CR requests power needed for max perf performance as a function of requested power and allocated power max perf for Req H max perf for Req M max perf for Req L Performance  H L M allocated power 

  41. Experimental Evaluation -performance optimality • DPM cannot grant all requests • Some allocations are more optimal than others DPM Req. H Req. M Req. MH Req. L CR4 CR1 CR2 CR3

  42. Experimental Evaluation -performance optimality • DPM cannot grant all allocations • Some allocations are more optimal than others DPM Req. L Req. H Req. M Req. MH H M optimal allocation L MH L M H MH suboptimal allocation CR4 CR1 CR2 CR3

  43. Experimental Evaluation -performance optimality • DPM cannot grant all allocations • Some allocations are more optimal than others • Oracle DPM always picks best performing legal allocation • ie. allocation with -Oracle DPM unimplementable • Oracle DPM constrained by system-wide invariant, not fractal

  44. Fractal Inefficiency –cost of fractal behavior overshooting system-wide power cap • Violating fractal invariant • Our fractal invariant implies system-wide cap > n*MH M:H MH:MH violates fractal invariant M:M MH:MH H:H MH:MH MH M MH MH M MH H H Legal: total power = 4MH Illegal: total power = 4MH • Some safe power requests are denied – fractal inefficiency

  45. Simulating Fractal DPM vs Oracle DPM • Simulate Fractal and Oracle DPMs managing 8 resources (4 shown) • Every CR makes random power request to 2 DPMs at time steps Fractal DPM Req. H Req. LM Req. MH Req. M Req. M Req. H Req. LM Req. MH Oracle DPM

  46. Simulating Fractal DPM vs Oracle DPM • Simulate Fractal and Oracle DPMs managing 8 resources (4 shown) • Every CR makes random power request to 2 DPMs at time steps Fractal DPM Req. H Req. LM Req. MH Req. M LM MH H M MH H LM M Req. M Req. H Req. LM Req. MH Oracle DPM

  47. Simulating Fractal DPM vs Oracle DPM • Simulate Fractal and Oracle DPMs managing 8 resources (4 shown) • Every CR makes random power request to 2 DPMs at time steps Fractal DPM Req. H Req. M Req. H Req. M Req. M Req. H Req. M Req. H Oracle DPM

  48. Simulating Fractal DPM vs Oracle DPM • Simulate Fractal and Oracle DPMs managing 8 resources (4 shown) • Every CR makes random power request to 2 DPMs at time steps Fractal DPM Req. H Req. H Req. M Req. M M LM H M H H M M Req. M Req. H Req. M Req. H Oracle DPM

  49. Simulating Fractal DPM vs Oracle DPM • Simulate Fractal and Oracle DPMs managing 8 resources (4 shown) • Every CR makes random power request to 2 DPMs at time steps Fractal DPM Perf = f(request,allocation) Req. H Req. H Req. M Req. M M LM H M H H M M Perf = f(request,allocation) Req. M Req. H Req. M Req. H Oracle DPM • Can compare total system perf. of Fractal DPM vs Oracle DPM

  50. Results • Millions of time steps simulated • For each time step, system perf = % CDF % system perf loss = () * 100% % system performance loss

More Related