Benchmarking of Dynamic Power Management Solutions. Frank Dols CELF Embedded Linux Conference Santa Clara, California (USA) April 19, 2007

Transcription

1 Benchmarking of Dynamic Power Management Solutions Frank Dols CELF Embedded Linux Conference Santa Clara, California (USA) April 19, 2007

2 Why Benchmarking?! From Here to There, 2000whatever Vendor NXP What do we get? 2 / 43

3 Presentation Outline: The context; Power management concepts. Hardware and software. Benchmarks; The process. Metrics. Findings. Conclusions. Relation to other work. What s next. 3 / 43

4 Area Of Interest Mobile/portable devices mostly exist of: 1. Battery. 2. Storage (flash disk, hard disk, ). 3. Display (LCD, ). 4. Speaker. 5. Broadband I/O (Bluetooth, UMTS, ). 6. Processing (CPU) We are initially only focusing on the optimization of the Processing power consumption. As next, we are also taking 1-5 into account. 4 / 43

5 Power Measurements LabView A board under test Measurements equipment: high precision DMM (digital Multi-Meters) Mp3 playback LabView measurements 5 / 43

6 Energy Consumers Energy saving methods trade performance or functionality for energy: Scaling performance of processors, memories and buses; Using various stand-by modes of peripherals. Energy saving is about supplying the right amount of performance at the right time. However, the future is unknown! other CPU Memory LCD DC/DC Energy consuming components in a typical audio/video playing mobile device. 6 / 43

7 Power Dissipation Basics E t = 0 ( C 2 ( V DD ) f c + VDD I Q ) dt Total Total Power Dissipation t 0 C 2 Dynamic ( V DD ) f c Power Dissipation + Leakage Power Dissipation t 0 V DD I lkg Reduce capacitance switched. Reduce switching currents. Reduce operating voltage. Reduce leakage current in active and standby modes of operation. Reduce operating voltage. 7 / 43

8 Dynamic Voltage Frequency Scaling (DVFS) Scales performance according to demand (using an estimation of future workload). Based on the fact that energy per clock cycle rises with frequency: P = ˆ V 2 Implemented by switching between operating points (voltage and frequency pairs). f Applications, task scheduler, or other source of information Workload estimation Clock Generator Voltage Controller Processor or memory 8 / 43

9 DVFS: How Does it Save Power 100% CPU usage Performance Full speed 50% CPU usage, no DVFS Performance Power 50% speed Idle 50% CPU usage, with DVFS Performance Power Optimal! Power High f,v Stand-by power Low f,v Time Energy used Time Time 9 / 43

10 Performance Prediction Methods Interval-based: use CPU-usage of previous interval(s) to determine frequency for next interval. 100% 0% task / workload operating frequency Problem: late reaction on changing workloads missed deadlines 100% 0% 10 / 43

11 Performance Prediction Methods Application-directed: use information from the application to change frequencies. 100% 0% task / workload operating frequency Problems: requires changes in the application; not always possible (interactive applications). 11 / 43

12 Dynamic Power Management (DPM) Concept Apps. Policy Policy Evaluation Apps. Apps. OS DPM Software Policy PolicyPolicy Required Performance % of max. performance Volts MHz Apps. DPM software connects to OS kernel and collects data, with collected data, and usage of policies, try to predict future workload. Multiple policies categorize software workload. Single global prediction of future performance is made. 12 / 43

13 Application directed DVFS Two main groups of mobile applications: Interactive Internet browsing Gaming Streaming Audio decoding Video decoding Future workload unknown (depends on user input) Future workload known to application 13 / 43

14 Presentation Outline: The context; Power management concepts. Hardware and software. Benchmarks; The process. Metrics. Findings. Conclusions. Relation to other work. What s next. 14 / 43

15 Benchmark Process Plan: Define Key Performance Indicators (KPI). Define test to measure KPI. Do: Measurement on evaluation platform. Check: Analyze gained results and can they be explained. When necessary, cross verify with Vendor. Act: Take necessary actions on gained results. 15 / 43

16 Key Performance Indicators (KPI) Memory usage. Footprint of DPM framework and administration. CPU usage. Cycles consumed by DPM framework. System behavior, predictability & reproducibility. System idleness. Prediction of optimum frequency (minimization of idleness). Real time behavior. Application deadlines missed. Responsiveness (latency on events). DPM Policy prediction accuracy. 16 / 43

17 Test / Use Cases Synthetic (fine-grained) benchmark, Simulate different workload levels, Test corner cases. LMbench as available from Open Source; lat_proc, lat_syscall, memory, clock, idle, Application level (coarse-grained) benchmark: Whetstone & Dhrystone (artificial system load). Hartstone (real time behavior). Video decoding, ffplay mpeg video decoding use case. use ffplay, part of ffmpeg. Audio decoding, mp3 audio decoding use case. use ARM MP3 decoding library. 17 / 43

18 Metrics for SW based Benchmarking Missed deadlines; Overdue time; Idle time; Jitter; Responsiveness. 18 / 43

19 Missed Deadlines When operating frequency is too low, deadlines are missed: Power Power Time Time 19 / 43

20 Overdue Time Are missed deadlines caused by timing inaccuracy, or by performance deficiency? Overdue time Power Power Time Time 20 / 43

21 Idle Time When operating frequency is too high, extra slack time is introduced, and power is wasted: Optimal scenario Power Power Power Time Time Time 21 / 43

22 Jitter Execution times vary, so time of completion varies as well: completion Power arrival Arrival times are periodic, but completion times vary Jitter Time 22 / 43

23 In Summary, DPM Metrics Missed deadlines (OS schedule); Overdue Time Overdue time; Idle time; Power Power Jitter (fluctuation in Completion time); Responsiveness. Time Time Idle Time Missed Deadline Completion Time 23 / 43

24 NXP s DVFS Benchmark Platform Energizer I SoC; ARM1176JZF-s, DVFS-enabled (core also), CPU voltage can be set in 25 mv increments, CPU frequency can be set using 2 PLL s (300MHz and 400MHz by default) and a divider. Energizer I Software; Linux , CPUfreq and PowerOP. MV s DPM framework ported but not used. 24 / 43

25 CPU Usage Characteristics No DPM 25 / 43 45,9 48,6 51,3 0 2,7 5,4 8,1 10,8 13,5 16,2 18,9 21,6 24, ,7 32,4 35,1 37,8 40,5 43, ,7 59,4 62,1 time (s) DPM Load CPU usage Exponential Weighed Average Policy 0 1,9 3,8 5,7 47,5 49,4 51,3 7,6 9,5 11,4 13,3 performance (%) 15,2 17, ,9 22,8 24,7 26,6 28,5 30,4 32,3 34,2 36, ,9 41,8 43,7 45,6 53,2 55, ,9 60,8 62,7 CPU usage, applied policy reacts slow on required performance. Moving Average Policy time (s) DPM Load CPU usage performance (%) ,9 3,8 5,7 7,6 9,5 11,4 13,3 15,2 17, ,9 22,8 24,7 26,6 28,5 30,4 32,3 34,2 36, ,9 41,8 43,7 45,6 47,5 49,4 51,3 53,2 55, ,9 60,8 62,7 performance (%) time (s) DPM Load CPU usage

26 DPM; Synthetic Workload 120 Late Response 100 performance Headroom time (1 st ) Synthetic Workload (2 nd ) DPM, Predicted Performance Requirement (3 rd ) Actual CPU Usage (Exponential Weighed Average Policy) 26 / 43

27 Application Level Benchmark Video playback (DivX). Open-Source ffplay using frame-buffer device. Instrumented with time measurements. Evaluation: How many hard deadlines are missed with & without DPM. 27 / 43

28 ffplay Deadlines ffplay deadline: time interval in between displaying of successive (decoded) frames. - For 10 fps movie -> the deadline is 100 ms. - With DPM activated, fluctuation increases. - REMARK: video output (display) on CompactPresenter via Compact flash interface, results in high fluctuation oops!! (see next slide). ffplay@10fps us frames 0 28 / 43

29 Kernel & User Space Activity While running ffplay, sample the CPU activity in both kernel and user space (based on /proc/stat). Kernel activity dominates during the video playback CPU usage, % user kernel time, us 29 / 43

30 DPM; Video Decoding System Overload 100 deadlines missed / idle time (%) Power Savings Policy Overhead Performance Impact frames per second idle idle DPM deadlines deadlines DPM (Exponential Weighed Average Policy) 30 / 43

31 Video Decoding Jitter jitter (milliseconds) Clock scaling causes jitter increase Jitter metric gets polluted by high number of deadline misses frames per second jitter jitter DPM 31 / 43

32 Video Decoding and Hints CITY_5fps.avi frequency (MHz) time (s) No DPM DPM, No hints DPM, with Hints 32 / 43

33 Comparison When application-directed hints are enabled; idle time reduction increases, effective in a wider frame rate window. 80 frames per second 5 7, ,5 15 idle time (%) DPM without hints is only effective at low workloads ,3 3,55 4,8 6,05 7,3 Custom DPM disabled Custom DPM enabled, without hints Custom DPM enabled, with hints DPM disabled DPM enabled 33 / 43

34 Presentation Outline: The context; Power management concepts. Hardware and software. Relation to other work. Benchmarks; The process. Metrics. Findings. Conclusions. Relation to other work. What s next. 34 / 43

35 Technology Conclusions Dynamic Power Management (DPM). Added value is in policies. Performs best on low workloads. Adaptation to changing workload is heavily dependent on chosen policy. As application developer, you have to develop your own policies. Be aware, policy adds overhead. Applications cannot feed data directly into DPM. Performance prediction based on logging application history does not always work. The best performance prediction may come from the application itself (feed forward)! Hinting can give improvements over an interval based approach. 35 / 43

36 Conclusions Interval based DPM at CPU-level results in higher CPU utilisation, but seems only really effective at low workloads; Precise energy saving figures should be measured using HW measuring tools, but SW benchmarks give good insight in saving potentials and consequences on real-time behaviour. SoC is not the biggest power consumer. Backlight, DC/DC converters & power amplifiers are big consumers, by optimizing these, most can be gained. 36 / 43

37 What s Next 1. CELF (you guys), MIPI PM working group - Matt Locke and his team 2. Mode switching. 3. Correlation between hardware and software; - What to solve at which level? 4. Deadline based scheduling, from priority based to time based. 5. Start contributing to the Community on this. Regarding bullet 1, 2 & 3, see extra slides 37 / 43

38 Overview of Open Source Power Mgt. Software CPU power management Device power management Standby (low power mode) when idle Dynamic Voltage/ Frequency Scaling Suspend complete system (memory) bus frequency scaling Suspend/ Resume of devices Task scheduler CPUfreq APM/ ACPI Power OP Linux Device Model (also look at Mark Gross presentation) 38 / 43

39 Mode Transitions PM policy (performance monitoring, decision taking) Mode transition in sw domain (warm boot, state restore, sequencing) app Mode transition in sw domain (state save, sequencing, PM infra control) policy Mode transition in hw domain (sequencing, communication) Mode transition in hw domain (communication, Voltage/ Frequency settling, sequencing) app slp_sw wu_sw slp_hw wu_hw ACTIVE mode transition LP mode transition ACTIVE mode event 39 / 43

40 Improving power management through co-design of hardware and software Typical Hardware aided Other ideas for improving power management Performance counters for other peripherals: Cache miss rate is an indicator for memory bus usage of the CPU. Hardware aided workload prediction algorithms (in embedded FPGA): DVFS algorithm in FPGA, instead of software; Enables fast calculation of estimations and quick operating point changes; Algorithm can be changed for every use case because of the use of an FPGA. Software Applications Policy manager OS Workload prediction algorithm FPGA DVFS Hardware (clock generator, voltage controller) More hardware acceleration for specific applications: Needs discussion with SW developers in early stage about which parts can be accelerated; Enables running on a lower frequency, and as such saving energy. Hardware 40 / 43

41 To come to the End. 41 / 43

42 We Started With the Question: Why Benchmarking? From Here to There, 2000whatever Do your homework, don t bring in the Trojan Horse! 42 / 43

43 43 / 43

44 NXP Semiconductors Established in 2006 (formerly a division of Philips) Builds on a heritage of 50+ years of experience in semiconductors Provides engineers and designers with semiconductors and software that deliver better sensory experiences Top-10 supplier with Sales of Bln (2006) Sales: 35% Greater China, 31% Rest of Asia, 25% Europe, 9% North America Headquarters: Eindhoven, The Netherlands Key focus areas: Mobile & Personal, Home, Automotive & Identification, Multimarket Semiconductors Owner of NXP Software: a fully independent software solutions company 44 / 43

45 Where to Find Us Operating systems Knowledge Centre (OKC) phone: fax: Web: address: High Tech Campus 46 location AE Eindhoven (NL) 45 / 43

46 46 / 43