AutoDVS: An Automatic, General-Purpose, Dynamic Clock Scheduling System for Hand-Held Devices

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. 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, . . . 1450 mAh 45 Grams 2600 mAh 23 Grams

3. Dynamic Voltage Scaling • 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

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. Typical Handheld Platform: iPAQ H3800 CPU PERIPHERAL DEVICES

6. Frequency Scheduling Timeline Old speed New speed Time PRECLK Phase POSTCLK milliseconds 0 35 40 Clock Scheduling Request Update Clock Speed iPAQ H3800, Linux Kernel v2.4

7. 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 AutoDVS: A hybrid DVS system Interactive Task Scheduler CPU Load Monitor Idle Task Monitor DVS Policy Arbiter CPU Clock Voltage Scaling Driver

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. Interactive Sessions Interactive Session • A period of user interaction: Each application has a specific pattern Interactivity Sessions - Tetrix Think Time Event Interarrival Time (msecs)

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

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

12. DVS Scheduling: Batch & Multimedia Tasks • 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

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

14. Arbiter Interactive CPU Load & Period Length 1 Idle task entry count & period 2 CPU load average 3 ARBITER RULES POLICY STACK Parameters 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) Interactive Task Scheduler Excessive load: Increase speed Excessive idleness: Reduce speed CPU Load Sensor Load Avg > HiThr: Increase speed Load Avg < LoThr: Decrease speed

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. 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. Results

18. Results Periodic tasks

19. Checkers: Periodic Tasks Computationally intensive task C Prediction • Checkers generates periodic tasks • CPU load alternates between idle and full load Idle I GUI task G I G C G I G I G C Waiting for user input Searching next move using Min-Max

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. THANK YOU! QUESTIONS?