1. Application Transformations for Energy and Performance-Aware Device Management Taliver Heath, Eduardo Pinheiro, Jerry Hom, Ulrich Kremer, and Ricardo Bianchini Rutgers University

2. www.darklab.rutgers.edu 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

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

4. www.darklab.rutgers.edu 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

5. www.darklab.rutgers.edu 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

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

7. www.darklab.rutgers.edu 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; }

8. www.darklab.rutgers.edu 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

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

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

11. www.darklab.rutgers.edu 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

12. www.darklab.rutgers.edu 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

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

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

15. www.darklab.rutgers.edu Average Hand-Modified Results PolicyEnergyPerformance EO40%0% FT60%5% DD73%7% PA60%1% CO70%4%

16. www.darklab.rutgers.edu Average Compiler Results PolicyEnergyPerformance EO46%1% FT68%4% DD79%7% CO75%3%

17. www.darklab.rutgers.edu 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]

18. www.darklab.rutgers.edu 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

19. www.darklab.rutgers.edu For more information 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

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

22. www.darklab.rutgers.edu Summary

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

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

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

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

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

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

29. www.darklab.rutgers.edu Parameter Description ParameterExplanation Energy consumed by policy pol CPU time consumed by policy pol Run-length Average power consumed in s Inactivity threshold for s Average reactivation energy Average deactivation energy Average reactivation time

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

31. www.darklab.rutgers.edu Experiments Applications1s2s3 MP3 player001 MPEG player001 Image smoother001 Gzip0.36.64 Sftp001 MPEG encoder00.5 Modified App Runlengths

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

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

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

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

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

37. www.darklab.rutgers.edu 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

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

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

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

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

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