1. AutoDVS: An Automatic, General- Purpose, Dynamic Clock Scheduling System for Hand-Held Devices Selim Gurun Chandra Krintz Lab for Research on Adaptive Compilation Environments (RACELab) University of California, Santa Barbara

2. 2 The Mobile Computing Energy Crisis Battery power The only currently feasible energy source Heavy: Capacity is a linear function of weight Low capacity Alternative technologies are not attractive yet  Fuel cells, ambient energy,... 2600 mAh 23 Grams 1450 mAh 45 Grams

3. 3 Example systems Weiser’94, Govil’95, Pering’95, Grunwald’00, Flautner’02, Lorch’03, … Reduce CPU energy consumption Faster processing requires more energy Lower speed (and voltage) whenever possible Predict future workload for optimum CPU speed Interval schedulers, application-assisted DVS techniques Dynamic Voltage Scaling

4. 4 Our Work: AutoDVS Goal: To provide a DVS system for handheld computers Real device/real applications Transparent to application Unobtrusive to user General-purpose  Multimedia  Interactive applications  Games  Batch tasks Efficient even when the voltage switching latency is high

5. 5 Typical Handheld Platform: iPAQ H3800 CPU PERIPHERAL DEVICES

6. 6 Frequency Scheduling Timeline Time milliseconds Old speedNew speed PRECLK Phase POSTCLK Clock Scheduling RequestUpdate Clock Speed 03540 iPAQ H3800, Linux Kernel v2.4

7. 7 AutoDVS: A hybrid DVS system AutoDVS contains multiple, concurrent DVS schedulers for effective scheduling of various applications Monitoring CPU load and application demand Voltage/Clock frequency change requests Evaluating clock speed change requests Mapping requests to hardware specific voltage/frequency steps CPU Load Monitor Idle Task Monitor DVS Policy Arbiter CPU Clock Voltage Scaling Driver Interactive Task Scheduler

8. 8 DVS Scheduling: Interactive Tasks User input triggers multiple GUI events Keyboard, joy-pad, touch-screen, etc… User interaction: DVS should be invisible Response latency is important  Human perception threshold: 50 milliseconds Extant approaches reschedule each GUI event Multiple voltage/frequency switching in an event’s lifetime We reschedule once per interactive session Because real life latencies are long

9. 9 Interactive Sessions A period of user interaction: Each application has a specific pattern Interactivity Sessions - Tetrix Event Interarrival Time (msecs) Interactive Session Think Time

10. 10 Interactive Sessions A period of user interaction: Each application has a specific pattern Interactivity Sessions - Solitaire Event Interarrival Time (msecs)

11. 11 NWSLite for Interactive Session Prediction Light-weight: 55 floating point instructions/prediction Multiple predictors Ranking based on past error rate No parameters to configure 2 NWSLite predictors per application Load, session length LoadLength 0.22.34s 0.41.20s ……

12. 12 CPU Load Monitor: Interval scheduling with large periods + better use of slack time through distributing demand in a larger period + resilient against fluctuations in demand - slow response if demand changes suddenly Idle Task Monitor: Monitors idle task statistics Multimedia tasks  Sudden increase in CPU demand => lost frames, noise, etc…  Extant approaches => programmer is responsible  Application notifies OS Idle task is scheduled whenever no runnable task exists However, cannot use NWSLite for load prediction DVS Scheduling: Batch & Multimedia Tasks

13. 13 Architecture Application 1Application 2Application 3 GUI KERNEL Linux Scheduler CPU Clock Driver I/O Drivers Event Filter Interactive Task Scheduler (NWSLite) CPU Load Sensors Arbiter (frqstep,len) event

14. 14 Arbiter CPU load average Idle task entry count & period Interactive CPU Load & Period Length 1 2 3 CPU Load Sensor Interactive Task Scheduler Parameters POLICY STACK ARBITER RULES Set CPU speed as requested, however, if predicted load < CPU load in the last 500 milliseconds, do not lower speed Map estimated load to clock speed (round up to next level) Excessive idleness: Reduce speed Load Avg > HiThr: Increase speed Load Avg < LoThr: Decrease speed Excessive load: Increase speed

15. 15 Evaluation Methodology Real-life applications Record and replay user input Games, Contact, Notepad, Drawpad, Multimedia… Compare AutoDVS to other policies MAX and IDEAL_FLAT Different perspectives (metrics) Interactivity Energy consumption Soft real time quality

16. 16 Metrics Energy Factor Ratio of energy used by scaled workload to energy used when workload is processed at full speed Stall Rate (for interactive tasks) Ratio of over-threshold execution time to total execution time Stall Magnitude (for interactive tasks) Over-threshold execution time divided by total event number Buffer Under-runs (for multimedia tasks) Gaps in playback sound due to processor starvation

17. 17 Results

18. 18 Results Periodic tasks

19. 19 Checkers: Periodic Tasks Checkers generates periodic tasks CPU load alternates between idle and full load GCGI GC G G GUI task C Computationally intensive task II I Idle Waiting for user input Searching next move using Min-Max CPU util Predicted CPU util 0- 10 01 …… Prediction

20. 20 Summary General purpose DVS algorithm Multiple policies co-operate to provide seamless voltage scaling Significant energy savings: 49% over MAX Slight performance degradation Concurrent workloads Interactive task and MP3 playback 31% energy savings over MAX Easily integrated with other techniques PPACE: Further energy savings for GUI events

21. 21 THANK YOU! QUESTIONS?

22. 22 Future Work Enhance for platforms with low voltage scaling latency PPACE Provide application interface Grace-OS User level power manager Improvements to evaluation platform Better techniques to estimate event completion Voltage scaling

23. 23 Results 5.55 4.36

24. 24 Interactive Tasks Response time is “critical” for interactive tasks Human perception threshold: 50 ms Lorch Rescheduling GUI events using PACE (a gradual CPU acceleration technique) Flautner Extend GUI events to perception threshold Applying to a real PDA Batch tasks: interval scheduling Interactive tasks: other scheduling, I.e. flat max, PACE based, etc. Challenge: Slow voltage/frequency scaling response

25. 25 Interval Scheduling Monitor CPU load in fixed intervals Future load is modeled as a function of past Many techniques exist Time-series Heuristics based on observations  Weiser, Chan Considers immediate history only Intervals are short: 1-50 ms. Not very effective

26. 26 Application-assisted Grace-OS Targeting periodic multimedia applications EDF scheduling for soft-real time, round-robin for others Soft-RT Applications use system calls to mark start and end of tasks, Grace-OS maintains task deadline information Chameleon OS level interface Application implements power manager Application delegates power management to other processes

27. 27 Results

28. 28 Results

29. 29 Results

30. 30 Results – PPACE Parameters Added PPACE An algorithm to reschedule voltage scaling for pre- deadline cycles Developed by Xu et al How much extra energy can be saved when voltage switch latency is low (i.e. ignorable) Rescheduling only interactive events 6 voltage transition points during the first 50 milliseconds of execution

31. 31 Results - PPACE -Reduction for pre-deadline cycles of GUI events only-

32. 32 Energy Measurement iPAQ does not support voltage scaling Approximate voltage levels using XSA data Formula given in paper Frequency scaling data collected using microsecond resolution timer