1 / 42

Application Transformations for Energy and Performance-Aware Device Management

Learn how to conserve energy in devices by exploiting transformations that increase idle time. Evaluate various energy-aware policies and compiler techniques for improved energy efficiency and performance.

kerib
Download Presentation

Application Transformations for Energy and Performance-Aware Device Management

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. Application Transformations for Energy and Performance-Aware Device Management Taliver Heath, Eduardo Pinheiro, Jerry Hom, Ulrich Kremer, and Ricardo Bianchini Rutgers University

  2. The Problem • Conserve energy in devices • Must take advantage of lower power states • State transitions have overhead • Cost in both energy and performance • Challenge: non-interactive applications and fast processors • Short device idle times • Devices cannot use lower power states www.darklab.rutgers.edu

  3. Our Solution An Unmodified Application (UM) CPU Disk CPU idle active idle active Disk active idle active idle Transformed Application www.darklab.rutgers.edu

  4. Our Goals • Conserve energy by exploiting transformations that increase idle time • Evaluate ideas using: • Hand-modified programs • Automated compiler transformations • Specific policies: Energy Oblivious, Fixed Threshold, Direct Deactivation, Pre-Activation, and Combined www.darklab.rutgers.edu

  5. Application Transformations • Increase idle times with help of compiler or programmer • Identify loops where accesses occur • Perform loop transformations • Estimate device idle times • Insert system calls • Idle time limited by memory or real-time constraints www.darklab.rutgers.edu

  6. Example: Original Application i = 1; while i <= N { read chunk[i] of file; compute on chunk[i]; i = i+1; } www.darklab.rutgers.edu

  7. Example: Transformed Application available = how_much_memory(); numchunks = available/sizeof(chunks); compute_time = appfunc(numchunks); i = 1; while i <= N { read chunk[i…i+numchunks] of file; next_R(compute_time); compute on chunk[i…i+numchunks]; i = i+numchunks; } www.darklab.rutgers.edu

  8. Compiler Framework • Annotations to file descriptors • Replace disk calls using interprocedural analysis • Profiling • Buffered I/O • Notify OS of idle times • Based on SUIF infrastructure www.darklab.rutgers.edu

  9. Device Management • Energy-Oblivious (EO) • Fixed-Threshold (FT) • Direct-Deactivation (DD) • Pre-Activation (PA) • Combined(CO) : DD+PA • Final state based on model [Heath02] www.darklab.rutgers.edu

  10. Sample Disk Power Graphs (mp3 player) UM FT CO www.darklab.rutgers.edu

  11. Experimental Setup • Fujitsu Disk • 6-GB, 4200-rpm laptop disk • 3 states • Idle – 0.9 W • Standby – 0.22 W • Sleep - 0.09W • Buffer memory available: 19MB • Time allowed for reading: .3 seconds www.darklab.rutgers.edu

  12. Experiment • 6 applications • Mp3 player, mpeg-player • Gzip, sftp, mpeg-encode, image smoother • Variables investigated • Disk management policies • Compiler vs. hand-optimized • OS prefetching on/off www.darklab.rutgers.edu

  13. Non-streaming: SFTP www.darklab.rutgers.edu

  14. Streaming: MP3 player www.darklab.rutgers.edu

  15. Average Hand-Modified Results www.darklab.rutgers.edu

  16. Average Compiler Results www.darklab.rutgers.edu

  17. Related Work (partial list) • Application-controlled power states • Concept, but no implementation [Ellis99,Lu99] • Compiler infrastructure [Delaluz01] • Direct deactivation and preactivation [Hom01,Heath02] • Conserving disk energy [Douglis94] • Modifying disk access API [Weissel02] www.darklab.rutgers.edu

  18. Conclusions • Application transformations • 55-89% savings in energy • Minimal effect on performance • Idle time predictions are difficult • Prefetching has little impact • Compiler transformations work well • As good as hand modifications • Generic framework: other disks and devices www.darklab.rutgers.edu

  19. For more information www.darklab.rutgers.edu www.darklab.rutgers.edu

  20. Technique • Create model of disk energy • Transform applications • Realize model on real disk • Predict disk energy usage • Measure disk on 4 applications www.darklab.rutgers.edu

  21. Future Work • More disks • Other devices • Multiple active processes • Asynchronous I/O www.darklab.rutgers.edu

  22. Summary www.darklab.rutgers.edu

  23. Historical Use of States • Change to Lower State during Period of Idleness • Fixed-threshold • Adaptive/Heuristic • OS Hints • Based on general knowledge of system www.darklab.rutgers.edu

  24. Runlength vs. Energy www.darklab.rutgers.edu

  25. Projected Application Gain www.darklab.rutgers.edu

  26. Projected Application Gain www.darklab.rutgers.edu

  27. Overhead for DD www.darklab.rutgers.edu

  28. Combined (CO) CPU idle active idle active Disk idle active active idle www.darklab.rutgers.edu

  29. Parameter Description www.darklab.rutgers.edu

  30. Reality Departs from Model • Hidden states in several transitions • Transition from active to idle • Behavior on activation For CO: www.darklab.rutgers.edu

  31. Experiments Modified App Runlengths www.darklab.rutgers.edu

  32. Energy, mpg123 www.darklab.rutgers.edu

  33. Energy, sftp www.darklab.rutgers.edu

  34. Performance, mpg123 www.darklab.rutgers.edu

  35. Performace, sftp www.darklab.rutgers.edu

  36. Experimental Results MP3 player www.darklab.rutgers.edu

  37. Summary • direct-deactivation and preactivation (CO) • Can save up to 89% of disk energy • No performance penalty, except for MPEG player (<10%) • Just increasing runlengths, we can save up to 50% energy • Error in model can be significant – up to 50% for the entire application www.darklab.rutgers.edu

  38. Energy Oblivious(EO) CPU idle active idle active Disk idle www.darklab.rutgers.edu

  39. Direct Deactivation(DD) CPU idle active idle active Disk www.darklab.rutgers.edu

  40. Pre-Activation(PA) CPU idle active idle active Disk idle www.darklab.rutgers.edu

  41. Fixed-Threshold(FT) CPU idle active idle active Disk www.darklab.rutgers.edu

  42. Terminology Runlength (R) Time between device accesses by the processor R R Device Time CPU Time Blocking device accesses (reads) Single ready-to-run application www.darklab.rutgers.edu

More Related