Computer Power Management Rules Ø Jim Kardach, re-red chief power architect, Intel hp://www.youtube.com/watch?v=cZ6akewB0ps 1 HW1 Ø Has been posted on the online schedule. Ø Due on March 3rd, 1pm. Ø Submit in class. Ø Hard deadline: no homework accepted aer deadline. Ø No collaboraon is allowed. Chenyang Lu CSE 467S The Power Problem Ø Processors improve performance at the cost of power. q Performance/wa remains low. Ø Soluon q Hardware offer mechanisms for saving power. q SoRware executes power management policies. 3 Power vs. Energy Ø Power: Energy consumed per unit -me q 1 wa = 1 joule/second Ø Power à heat Ø Energy à baery life 4 Why worry about energy? Intel vs. Duracell 16x 14x Processor (MIPS) 12x Hard Disk (capacity) 10x Improvement (compared to year 0) 8x 6x Memory (capacity) 4x 2x Battery (energy stored) 1x 0 1 2 3 4 5 6 Time (years) Ø No Moore’s Law in baeries: 2-3%/year growth. Trend in Power Density Sun’s Surface 1000 Rocket Nozzle Nuclear Reactor 2 100 Pentium® 4 Pentium® III Watts/cm Pentium® II 10 Hot plate Pentium® Pro i386 Pentium® New Microarchitecture Challenges in the Coming i486 Generaons of CMOS Process Technologies, Fred Pollack, 1 Intel Corp. Micro, 1999. 1.5µ 1µ 0.7µ 0.5µ 0.35µ 0.25µ 0.18µ 0.13µ 0.1µ 0.07µ Process 6 Trend in Cooling Soluon 7 Power Ø Hardware support Ø Power management policy Ø Power manager Ø Holis-c approach 8 CMOS Power ConsumpDon Ø Voltage drops: power consump-on ∝ V2. Ø Toggling: more ac-vity à higher power. Ø Leakage when inac-ve. 9 Power-Saving Features Voltage drops " Reduce power supply voltage. Toggling " Run at lower clock frequency. " Reduce ac-vity. " Disable func-on units when not in use. Leakage " Disconnect parts from power supply when not in use. 10 Dynamic Voltage Scaling Ø! Why voltage scaling? q! Power ∝ V2 à reduce power supply voltage saves energy. q! Lower voltage à lower clock frequency. •! Tradeoff between performance vs. energy. Ø! Why dynamic? q! Peak compu-ng demand is much higher than average. Ø! Changing voltage takes -me q! to stabilize power supply and clock 11 Examples Ø! StrongARM SA-1100 takes two supplies q! VDD is main 3.3V supply. q! VDDX is 1.5V. Ø! AMD K6-2+ q! 8 frequencies: 200-600 MHz. q! Voltage: 1.4, 2.0 V. q! Transi-on -me: 0.4 ms for voltage change. Ø! PowerPC 603 q! Can shut down unused execu-on units. q! Cache organized into subarrays to reduce ac-ve circuitry. 12 Intel SpeedStep Intel Core 2 Duo E6600 Intel Pen-um M P states 13 Linux DVFS Governors Ø! Performance q! Always set at the max frequency Ø! Powersave q! Always set at the lowest frequency Ø! Ondemand q! Automacally adjust the frequency according to CPU usage Ø! Conservave q! Like ondemand, but in a more conservave way. Ø! Userspace q! Set at a fixed frequency by the user 14 Ondemand Ø! Ini-al implementaon in 2.6.9 Ø! For all CPUs q! if (> 80% busy) then P0 (max frequency) q! if (< 20% busy) then down by 20% Ø! Mul-ple improvements since 2.6.9 15 Get & Set CPU Frequency Ø! Get the current frequency: q! /sys/devices/system/cpu/cpu[X]/cpufreq/scaling_cur_freq q! Example: 2400000 (2.4GHz) Ø! Frequency & governors available: q! /sys/devices/system/cpu/cpu[X]/cpufreq/scaling_available_frequencies q! Example: 2400000 2133000 1867000 1600000 q! /sys/devices/system/cpu/cpu[X]/cpufreq/scaling_available_governor q! Example: ondemand userspace performance powersave conservave Ø! Set the frequency: q! Root privilege q! echo userspace > /sys/devices/system/cpu/cpu[X]/cpufreq/ scaling_governor q! echo 2133000 > /sys/devices/system/cpu/cpu[X]/cpufreq/scaling_setspeed 16 Clock GaDng Ø! Applicable to clocked digital components q! Processors, controllers, memories Ø! Stop clock à stop signal propagaon in circuits ✔! Short transi-on -me q! Clock generaon is not stopped q! Only clock distribu-on is stopped ✘! Relavely high power consump-on q! Clock itself s-ll consumes energy q! Cannot prevent power leaking 17 Supply Shutdown Ø! Disconnect parts from power supply when not in use. ✔! General ✔! Save most power ✘! Long transi-on -me 18 Example: SA-1100 Three power modes: Ø! Run: normal operaon. Ø! Idle: stops CPU clock, w. I/O logic s-ll powered. Ø! Sleep: shuts off most of chip ac-vity 19 SA-1100 SLEEP Ø! RUN à SLEEP q! (30 µs) Flush to memory CPU states (registers) q! (30 µs) Reset processor state and wakeup event q! (30 µs) Shut down clock Ø! SLEEP à RUN q! (10 ms) Ramp up power supply q! (150 ms) Stabilize clock q! (negligible) CPU boot 20 Intel Core Duo Processor SV IntelIntel CoreCore DuoDuo ProcessorProcessor SVSV Name Vcc Watt C0 High Frequencey Mode (P0) 1.3 31 C0 Low Frequency Mode (Pn) 1.0 C1 Auto Halt Stop Grant (HFM) 15.8 C1E Enhanced Halt (LFM) 4.8 C2 Stop Clock (HFM) 15.5 C2E Enhanced Stop Clock (LFM) 4.7 C3 Deep Sleep (HFM) 10.5 C3E Enhanced Deep Sleep (LFM) 3.4 C4 Intel Deeper Sleep 0.85 2.2 DC4 Intel Enhanced Deeper Sleep 0.80 1.8 3 Ottawa Linux*Intel® SymposiumCore™ Duo Processor 65nmJuly 19, Process2006 – Datasheet 7 21 The Mote Revolution: Low Power Wireless Sensor Network Devices, Joseph Polastre, Robert Szewczyk, Cory Sharp, David Culler, Hot Chips 16. 22 Power Consumpon Computer with Wireless NIC Power Ø! Hardware support Ø! Power management policy Ø! Power manager Ø! Holis-c approach 24 Approaches Ø! Stac Power Management q! Does not depend on ac-vity. q! Example: user-ac-vated power-down. Ø! Dynamic Power Management q! Adapt to ac-vity at run -me. q! Example: automacally disabling func-on units. 25 Dynamic Power Management Ø! Inherent tradeoff: energy vs. performance Ø! Fundamental premises q! Non-uniform workload during operaon q! Possible to predict workload with some degree of accuracy 26 PowerPC 603 AcDvity Percentage of -me idle for SPEC integer/floang-point: unit Specint92 Specfp92 D cache 29% 28% I cache 29% 17% load/store 35% 17% fixed-point 38% 76% floang-point 99% 30% system register 89% 97% 27 Problem FormulaDons Ø! Minimize energy under performance constraints q! Real--me applicaons Ø! Op-mize performance under energy/power constraints q! Baery life-me (energy) q! Temperature (power) 28 Power Down/Up Cost Ø! Going into/out of an inac-ve mode costs q! me q! energy Ø! Must determine if going into an inac-ve mode is worthwhile. Ø! Model power states with a Power State Machine (PSM) 29 SA-1100 Power State Machine PON = 400 mW run 10 µs 160 ms 90 µs 10 µs 90 µs idle sleep P = 50 mW OFF POFF = 0.16 mW PTR = PON 30 Greedy Policy Ø Immediately goes to sleep when system becomes idle Ø Works when transi-on -me is negligible q Ex. between IDLE and RUN in SA-1100 Ø Doesn’t work when transi-on -me is long! q Ex. between SLEEP and RUN/IDLE in SA-1100 q Need beer solu-ons! 31 Break-Even Time TBE Ø Minimum idle -me required to compensate for the cost of entering an inac-ve state. Ø Enter an inac-ve state is beneficial only if idle -me > TBE. 32 Break-Even Time PTR ≤ PON Ø PTR: Power consump-on during transi-on Ø PON: Power consump-on when ac-ve Ø TBE of an inac-ve state is the total -me it takes to enter and leave the state Ø TBE = TTR = TON,OFF + TOFF,ON q TBE = 160 ms + 90 µs for SLEEP in SA-1100 33 SA-1100 Power State Machine PON = 400 mW run 10 µs 160 ms 90 µs 10 µs 90 µs idle sleep P = 50 mW OFF POFF = 0.16 mW PTR = PON 34 Break-Even Time PTR > PON Ø TBE must include addi-onal inac-ve -me to compensate for extra power consump-on during transi-on. TBE = TTR + TTR(PTR - PON)/(PON - POFF) Ø Reduce TBE à save more energy q Shorter TTR q Higher power difference between PON – POFF q Lower PTR 35 Inherent Exploitability Ø Achievable energy saving depends on workload! q Distribu-on of idle periods Ø Given an idle period Tidle > TBE q ES(Tidle) = (Tidle - TTR)(PON - POFF) + TTR(PON – PTR) Ø Assump-ons q No performance penalty. q Ideal manager with knowledge of workload in advance. 36 Inherent Exploitability based on real workload 37 Time-Power Product Workload-independent Metric CS = TBEPOFF Ø An inac-ve state with lower CS may save more energy Ø Only a crude es-mate q May not be representave of real power savings 38 Predicve Techniques Ø Interested event: p = {Tidle > TBE} q Predict based on history Ø Observed event: o q Triggers state transi-on Ø Objec-ve: predict p based on o 39 Metrics Ø Safety: condi-onal probability Prob(p|o) q If an observed event happens à the probability of Tidle>TBE q Ideally, safety = 1. Ø Efficiency: Prob(o|p) q If Tidle > TBE à the probability of correctly predic-ng. Ø Overpredicon à high performance penalty à poor safety Ø Underpredicon à wastes energy à poor efficiency 40 Fixed Timeout Policy Ø Enter inac-ve state when system has been idle for TTO q o: Tidle > TTO Ø Wake up in response to ac-vity Ø Hypothesis: If system has been idle for TTO à it will con-nue to be idle for Tidle-TTO > TBE 41 TTO??? Ø Increasing TTO improves safety, but reduces efficiency.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages69 Page
-
File Size-