Application Transformations for Energy and Performance-Aware Device Management

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