I/O Systems V (Power Management)

1. I/O Systems V(Power Management) CS423, Fall 2007 Klara Nahrstedt/Sam King

2. Content • Power management • Hardware issues • OS issues • GRACE-OS • Summary

3. Approaches to reduce energy consumption • OS turns off parts of the computer when are not in use (mostly IO devices such as display) • Application program uses less energy, possibly degrading quality of the user experience • Which hardware/software component takes most energy?

4. Hardware Issues • Battery • Handheld devices: disposable batteries, • Laptops: rechargeable batteries • Multiple power states for CPU, memory and I/O devices • Sleeping • Hibernating • Off • Transition between power states: • Idle for a certain period of time, transition into lower power state • Activated when it is accessed

5. OS Issues • Keep track of the states of different devices • Which device to transition into low-power state? • Window's ACPI - Advanced Configuration and Power Interface • OS sends commands asking the device driver to report on device's states (power information)

6. Display Energy Management • The biggest energy consumption • Reason • Require backlit to get a bright sharp image • What solutions would reduce display energy?

7. Hard Disk • Disk takes substantial energy • spinning at high speed, even if there are no accesses. • What would be the solution to decrease energy?

8. Memory • Two options to save energy with memory: • cache is flushed and then switched off (hibernation) • write content of memory to disk and switch off the memory • When memory is shut off • CPU has to shut off or has to execute out of ROM; • If CPU is off and interrupt wakes it up, it has to read from ROM to load the memory. • What are the tradeoff? • Multiple power-mode • Active • Nap • Standby • Power-down

9. Wireless Communication • If radio receivers always listen for messages, this can be expensive. • Solution • turn off the receiver if it is being idle for some time. • Challenge: how to avoid lost incoming messages? • Who decides to turn off the radio and Why?

10. CPU - Energy-Efficient Mobile Multimedia Devices (Research, SOSP 2003) Mobile devices • Running multimedia apps (e.g., MP3 players, DVD players) • Running on general purpose systems • Demanding quality requirements • System resources: high performance • OS: predictable resource management • Limited battery energy • System resources: low power consumption • OS: energy as first-class resource

11. New Opportunities Adaptability of software and hardware • Multimedia applications • Multiple Quality levels: quality vs. resource usage • Statistical performance requirements (e.g., meeting 96% of guarantees) • Soft guarantees from OS • Hardware components • Multiple operating states: performance vs. power (e.g., mobile processors Intel’s XSacle, AMD’s Athlon, Transmeta’s Crusoe) • Dynamic Voltage Scaling (DVS) • Reducing CPU voltage can reduce CPU energy consumption substantially

12. Triggers: frequent, fine-grain • Small usage change • Triggers: rare, coarse-grain • Application joins or leaves • Large usage change • Large availability change • Adaptation: Each layer adapts locally • Respect the global • configuration • Adaptation: Via coordinator • Determine a system-wide • optimal configuration • Cost: expensive • Cost: cheap Global and Internal Adaptation Global Internal

13. System Models • Adaptive periodic multimedia application • Multiple QoS levels, {q1, …, qm} • Utility u(q) • CPU demand: period P(q) and cycle C(q) • Statistical performance requirement: probability to meet deadlines °ρ Battery • Desired lifetime Tlife and residual energy Eres • Adaptive processor • Multiple speeds, {f1, …, fmax} • Frequency f • Power p(f)

14. (5.2) adapt QoS parameters application App Adaptor (5.1) coordinated QoS level • utility demand (6.1) coord. allocation Coordinator SRT CPU Scheduler (2) residual energy (3) optimization (4.1) coordinated speed (4.2) adapt speed Battery Monitor CPU Speed Adaptor CPU Coordination Protocol

15. Multimedia tasks (processes or threads) performance requirements (via system calls) monitoring scheduling Stochastic SRT Scheduler demand distribution Profiler time allocation GRACE-OS CPU Speed Adaptor (Stochastic DVS) speed scaling CPU Soft-Real-Time Scheduling

16. SRT Scheduling Framework • Profiler • monitors cycle usage of individual tasks • derives probability distribution of their cycle demands from cycle usage • Stochastic SRT scheduler • allocates cycles to task • schedules them to deliver performance guarantees, • performs SRT scheduling based on the statistical performance requirements and demand distribution • Speed adaptor • adjusts CPU speed dynamically to save energy W. Yuan, K. Nahrstedt, “Energy-Efficient Soft Real-Time CPU Scheduling for Mobile Multimedia Systems”, ACM Symposium on Operating Systems Principles (SOSP), 2003

17. in out in finish/out c1 c2 c3 c4 cycles c2 – c1 c4 – c3 cycles for the job = (c2 – c1) + (c4 – c3) Demand Estimation (1) 1. Kernel-based online profiling • Measure cycles between switch-in (in) and switch-out (out) • Accurate with small overhead Measured cycles are kept in cycle counter of the process control block of each task.

18. distribution function P[X<=x] b1 b2 bi Cmin=b0 br=Cmax br-1 cycle demand Demand Estimation (2) 2. Histogram for probability distribution • Group profiled cycles • Use profiling window of n jobs with cycles [Cmin, Cmax] • Partition profiling window into r equal-sized groups (Cmin = b0 < b1 <…<br=Cmax) • Let nibe number of cycle usage that falls into ithgroup (ni/n– probability that task’s cycle demands are in between bi-1 and bi) • Count occurrence in each group 1 P[X<=bi] = cumulative probability

19. Demand Estimation (3) statistical performance requirement ρ cumulative probability b1 b2 Cmin=b0 br=Cmax br-1 cycle demand C 3. Determine amount of cycles C allocated to each task • Statistical performance requirement ρ of a task • Meetρpercent of deadlines so that • Search task’s histogram to find smallest bm with P[X ≤bm] ≥ ρ

20. Demand Estimation Probability distribution is more stable, but changes slowly and smoothly

21. Stochastic SRT Scheduling (Speed-Aware EDF Scheduling) Variable speed constant bandwidth server(VS-CBS) • Maximum budget C -- Period P • Budget c -- Deadline d • Hierarchical scheduling • SRT scheduler selects earliest-deadline VS-CBS • VS-CBS executes the application • Decrease budget c by # of consumed cycles • If c=0, then c = C and d = d + P

22. Stochastic DVS Scheduling • Dynamic speed scaling policy: • GRACE-OS starts a job at a lower speed and accelerate as it progresses • Speed Schedule for each task

23. cycle: speed: 0 100 MHz 1 x 106 120 MHz 2 x 106 180 MHz 3 x 106 300 MHz (a) Speed schedule with four scaling points 120 speed (MHz) 100 job1's cycles=1.6x10 6 time (ms) 10 15 180 120 speed (MHz) 100 job2's cycles = 2.5 x 10 6 time (ms) 10 18.3 21.1 300 speed (MHz) 180 120 100 job3's cycles = 3.9 x 10 6 time (ms) 10 18.3 23.8 26.8 (b) Speed scaling for three jobs using speed schedule in (a) Stochastic DVS (Example)

24. Implementation: Software • Adaptive applications • w/ application adaptor application message queue coordinator middleware system call GRACE-OS • SRT -DVS modules • SRT scheduling PowerNow module Standard Linux scheduler hook Linux kernel

25. Global Coordination Overhead

26. SRT Scheduling Overhead

27. Compare Lifetime