1 / 39

Power Management for Hard Disks and Main Memory

Power Management for Hard Disks and Main Memory. Presented by Matthias Eiblmaier. 11/06/2008. 11/06/2008. Motivation. Power-consumption is a key factor to achieve environmental and financial goals. There are several ways to save power in a computer. Throttling CPU speed.

ganya
Download Presentation

Power Management for Hard Disks and Main Memory

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. Power Management for Hard Disks and Main Memory Presented by Matthias Eiblmaier 11/06/2008

  2. 11/06/2008 Motivation • Power-consumption is a key factor to achieve environmental and financial goals • There are several ways to save power in a computer Throttling CPU speed Throttling disk speed Set idle RAM banks and ranks into low power mode Matthias Eiblmaier

  3. 11/06/2008 Outline Several approaches have been proposed to save energy by efficient peripheral power management.The two papers that will be discussed today: Performance Directed Energy Management for Main Memory and Disks (by Xiaodong Li, Zhenmin Li, Francis David, Pin Zhou, Yuanyuan Zhou, Sarita Adve and Sanjeev Kumar)‏ Department of Computer Science ,University of Illinois, The Proceedings of the Eleventh International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS'04), October, 2004 A comprehensive Approach to DRAM Power Management (by Ibrahim Hur and Calvin Lin)‏ Department of Computer Sciences, the University of Texas the 14th IEEE International Symposium on High-Performance Computer Architecture (HPCA 2008), Salt Lake City, Utah, February 2008 Matthias Eiblmaier

  4. 11/06/2008 Outline Performance Directed Energy Management for Main Memory and Disks Introduction and background Performance Guarantees Control Algorithms Disk energy management Experiment Conclusion Critiques Matthias Eiblmaier

  5. 11/06/2008 1. Introduction and background You can save power for a storage device by putting them into low power modes. Low power modes can degrade performance • Current (threshold based) algorithms: • monitor usage (response time) and move if this value exceeds, based on certain thresholds, the device into low power mode. • need painstaking, application-dependent manual tuning of thresholds • have no performance guarantee Matthias Eiblmaier

  6. 11/06/2008 1. Introduction and background This paper contributes: Technique to guarantee performance A self tuning threshold based control algorithm (called PD)‏ A simpler, optimization based, threshold free control algorithm (called PS)‏ • RDRAM Memory Power Modes: • Each chip can be activated independently • There are 4 power modes: active, standby, nap & power down • Chip needs to be in active mode to serve are read/write request. • Previous control algorithms: • Static: put device in a fixed power mode • Dynamic: change power mode when being idle for a specific amount of time (threshold)‏ Matthias Eiblmaier

  7. 11/06/2008 2. Performance Guarantee • Assume the best performance is without energy management • An acceptable slowdown is referred to the control algorithm • Slowdown is the percentage increase of the execution time • To estimate the slowdown, the following terms are used: • t = Execution time using the underlaying energy management until some point P in the program • = Execution time without any energy management until the same point in the program • Delay(t) = absolute increase in execution time due to energy mangement = t – Tbase (t)‏ • Actual percentage slowdown = Matthias Eiblmaier

  8. 11/06/2008 2. Performance Guarantee Performance Gurantee is subject to Slack(t) = amount of execution time not violating timing constraints Example : • Epoch based algorithm: • Application’s execution time can be predicted. • Estimates available slack for entire epoch at start of epoch. • Check slack after each access. • If slack is not enough, algorithm forced all devices in active mode. Matthias Eiblmaier

  9. 11/06/2008 2. Performance Guarantee Available slack for next period: where tepoch is the predicted execution time of the next epoch without power management t slack tepoch slack Delay(t+1)‏ Delay(t)‏ Slowdown/100 * t Slowdown/100 * tepoch Matthias Eiblmaier

  10. 11/06/2008 3. Control Algorithm • Two kind of algorithms are used for performance guarantee: • Performance-directed static algorithm (PS).Fixed power mode to a memory chip for the entire duration of an epoch. • Performance-directed dynamic algorithm (PD).Transfers to low power mode after some idle time and re-tunes of the thresholds based on available slack and workload characteristics Matthias Eiblmaier

  11. 11/06/2008 3. Control Algorithm (PS) Goal is to choose for every chip a configuration, that maximizes the total energy savings to the constraint of the total available slack: maximize: subject to: where PS Algorithm called at the beginning of every epoch 1. Predict AvailableSlack for the next epoch. 2. Predict E(Ci) and D(Ci) for each device i. 3. Solve the knapsack problem. 4. Set the power mode for each device for the next epoch. Matthias Eiblmaier

  12. 11/06/2008 3. Control Algorithm (PS) • Obtain available slack from performance-guarantee algorithm • Algorithm need to predict next epoch’s number and distribution of accesses. • Prediction: Number of accesses: The same as last epoch. Distribution of accesses: Uniform distribution in time. • Algorithm reclaim any unused slack from last epoch. Matthias Eiblmaier

  13. 11/06/2008 3. Control Algorithm (PD) PD automatically re-tunes its thresholds at the end of each epoch, based on available slack and workload characteristics: Predict AvailableSlack for the next epoch. Predict number of accesses for the next epoch. Adjust the functions for Thk(S) (1≤k≤M-1) access count measured from the last epoch. for k = 1,...,M-1 do. 5. Use the Thk(S) functions to determine the values for Thk, 6. end for.7. Set thresholds Th1,..., ThM for all chips. Manipulate thresholds Command threshold slackopt slack Per.Dyn. Controller Transfer function + - If slack to low set higher thresholds Matthias Eiblmaier

  14. 11/06/2008 3. Control Algorithm (PD) • When i>k To keep device active during the short idle time. • Using break-even time as threshold. • When 0≤i≤k(threshold: Ck-i*tk) Putting a device in mode k unless device id already idle for a large period. • The lower value of i the higher threshold. threshold: Ck-i*tk • Constant C use to dynamically adjust threshold: • Slack not used up: Cnext=0.95*Ccurrent Slack used up: Cnext=2*Ccurrent Matthias Eiblmaier

  15. 11/06/2008 4. Disk management • Model • DRPM disk model: • multi-speed disk. • Can service request at a low rotational speed. • No transition overhead. • Performance delay: • Period of speed change. • Service in low speed. • Performance Guarantee • Static algorithm: • The same as memory. • Dynamic algorithm: • Algorithm adjust UT and LT based on • Predicted access count. • Available slack. Matthias Eiblmaier

  16. 11/06/2008 5. Experiments The experimental verification are done on a simulator (Simplescalar) with an enhanced RDRAM memory model. Execution times with original algorithms: Matthias Eiblmaier

  17. 11/06/2008 5. Experiments Results for Memory: Matthias Eiblmaier

  18. 11/06/2008 5. Experiments • Experiments and results for Disk: • Simulator: DiskSim. • Disk:IBM Ultrastar 36Z15. • Rotational speed:3K,6K,9K,12K. • Access distribution: • Exponential,Pareto,Cello’96. Matthias Eiblmaier

  19. 11/06/2008 6. Conclusion • Improvement PM algorithm’s execution time degrade. • Proposing self-tuning energy-management algorithm. Matthias Eiblmaier

  20. 11/06/2008 7. Critiques • PD/PS cannot guarantee real time • Performance guarantee algorithm is not tested for stability • PD causes overhead • Loop variable Delay, hence slack, is just estimated • Experimental verification lacks of substantial benchmarks (e.g. real server workloads) • Not exactly stated where and how to implement algorithm (chip, OS) Matthias Eiblmaier

  21. 11/06/2008 Outline Performance Directed Energy Management for Main Memory and Disks Queue-Aware Power-Down Mechanism Power/Performance-Aware Scheduling Adaptive Memory Throttling Delay Estimator Model Simulation and Results Conclusions Critiques Matthias Eiblmaier

  22. 11/06/2008 1. Queue-Aware Power-Down Mechanism Processors/Caches Read/Write instructions are queued in a stack Scheduler (AHB) decides which instruction is preferred Subsequently instructions are transferred into FIFO Memory Queue MEMORY CONTROLLER Read Write Queues Scheduler Memory Queue DRAM Matthias Eiblmaier

  23. 11/06/2008 1. Queue-Aware Power-Down Mechanism Read/Write Queue Set rank1 counter to 8 Decrement counter for rank 2 Rank counter is zero -> rank is idle & The rank status bit is 0 -> rank is not yet in a low power mode & There is no command in the CAQ with the same rank number -> avoids powering down if a access of that rank is immanent C:1 - R:2 – B:1 – 0 - 1 C:1 - R:2 – B:1 – 0 - 2 Set rank2 status bit to 8 C:1 - R:2 – B:1 – 0 - 3 Decrement counter for rank 1 C:1 - R:2 – B:1 – 0 - 4 Set rank2 status bit to 8 C:1 - R:2 – B:1 – 0 - 5 Decrement counter for rank 1 C:1 - R:2 – B:1 – 0 - 6 … C:1 - R:2 – B:1 – 0 - 7 Set rank2 status bit to 8 C:1 - R:1 – B:1 – 0 - 1 Power down rank 1 Matthias Eiblmaier

  24. 11/06/2008 2. Power/Performance-Aware Scheduling An adaptive history scheduler uses the history of recently scheduled memory commands when selecting the next memory command A finite state machine (FSM) groups same-rank commands in the memory as close as possible -> total amount of power-down/up operations is reduced This FSM is combined with performance driven FSM and latency driven FSM Matthias Eiblmaier

  25. 11/06/2008 3. Adaptive Memory Throttling Processors/Caches Power Target Reads/Writes determines how much to throttle, at every 1 million cycles Throttle Delay Estimator Read Write Queues Model Builder (a software tool, active only during system design/install time) Scheduler Throttling Mechanism decides to throttle or not, at every cycle Memory Queue MEMORY CONTROLLER sets the parameters for the delay estimator DRAM Matthias Eiblmaier

  26. 11/06/2008 3. Adaptive Memory Throttling • Stall all traffic from the memory controller to DRAM for T cycles for every 10,000 cycle intervals . . . active active stall stall T cycles T cycles 10,000 cycles 10,000 cycles time • How to calculate T (throttling delay)? Matthias Eiblmaier

  27. 11/06/2008 3. Adaptive Memory Throttling Model Building • Inaccurate throttling • Power consumption is over the budget • Unnecessary performance loss • Throttling degrades performance Application 1 App. 2 A B T Matthias Eiblmaier

  28. 11/06/2008 4. Delay Estimation Model • Calculates the throttling delay, T, using a linear model • Input: Power threshold and information about memory access behavior of the application • Output: Throttling delay • Calculates the delay periodically (in epochs) • Assumes consecutive epochs have similar behavior • Epoch length is long (1 million cycles): overhead is small • What are the features and the coefficients of the linear model? • Step 1: Perform experiments with various memory access behavior • Step 2: Determine models and model features • Needs human interaction during system design time • Step 3: Compute model coefficients • Solution of a linear system of equations Matthias Eiblmaier

  29. 11/06/2008 4. Delay Estimation Model Model Building • An offline process performed during system design/installation • Step 1: Perform experiments with various memory access behavior • Step 2: Determine models and model features • Needs human interaction during system design time • Step 3: Compute model coefficients • Solution of a linear system of equations Matthias Eiblmaier

  30. 11/06/2008 4. Delay Estimation Model • Model features that we determine • Power threshold • Number of Reads • Number of Writes • Bank conflict information • Possible Models • T1: Uses only Power threshold • T2: Uses Power, Reads, Writes • T3: Uses all features Matthias Eiblmaier

  31. 11/06/2008 4. Delay Estimation Model • Step 1: Set up a system of equations • Known values are measurement data • Unknowns are model coefficients • Step 2: Solve the system R2=0.191 R2=0.122 R2=0.003 Matthias Eiblmaier

  32. 11/06/2008 5. Simulation and Results • Used a cycle accurate IBM Power5+ simulator that IBM design team uses • Simulated performance and DRAM power • 2.1 GHz, 533-DDR2 • Evaluated single thread and SMT configurations • Stream • NAS • SPEC CPU2006fp • Commercial benchmarks • 2 cores on a chip • SMT capability • ~300 million transistors Memory Controller (1.6% of chip area) Matthias Eiblmaier

  33. 11/06/2008 5. Simulation and Results • Energy efficiency improvements from Power-Down mechanism and Power-Aware Scheduler • Stream : 18.1% • SPECfp2006 : 46.1% Matthias Eiblmaier

  34. 11/06/2008 5. Simulation and Results Matthias Eiblmaier

  35. 11/06/2008 6. Conclusion • Introduced three techniques for DRAM power management • Queue-Aware Power-Down • Power-Aware Scheduler • Adaptive Memory Throttling • Evaluated on a highly tuned system, IBM Power5+ • Simple and accurate • Low cost • Results in the paper • Energy efficiency improvements from our Power-Down mechanism and Power-Aware Scheduler • Stream : 18.1% • SPECfp2006 : 46.1% Matthias Eiblmaier

  36. 11/06/2008 7. Critiques • Overhead is not computed or estimated • Needs a relative complicated architecture • Throttling and queuing result in delays -> no RT • Dependence on prediction model Matthias Eiblmaier

  37. 11/06/2008 Overall Conclusion and comparison Matthias Eiblmaier

  38. 11/06/2008 Thank You Matthias Eiblmaier

  39. 11/06/2008 3. Control Algorithm • To enforce performance guarantee , algorithm needs to: • Apportion a part of the available to each chip. • keep track of the actual delay each chip incurs. • Compare actual delay and predicted delay • for every epoch Matthias Eiblmaier

More Related