Enhancing CPU Efficiency for Energy Conservation in Single-User OS

1. Reducing Processor Power Consumption by Improving Processor Time Management in a Single-User Operating System Jacob R. Lorch and Alan Jay Smith University of California, Berkeley

2. Welfare reform initiatives • Overall problem: not enough money for welfare recipients • Three possible initiatives • stop overpaying people who have filed fraudulent claims overstating their worthiness • stop overpaying people who have filed honest claims but who, through bureaucratic error, are being paid more than regulations require • reduce all payments by a certain percentage Money : welfare recipient :: CPU time : process

3. Outline of presentation • Motivation • Background on MacOS • A different strategy for power management • Problems with this strategy and our solutions to these problems • Results of simulations • Conclusions

4. Motivation • Power reduction is important on the desktop • expense, heat, fan noise, contribution to pollution • government regulation: Energy Star, Blue Angel • Power reduction is critical in portable computers • battery capacity per unit weight advancing slowly • limited space and weight available in portables • drives importance of power management • Importance of processor energy reduction • Accounts for large percentage of total power (18-34%) • Watching the CPU turning on and off, we got the impression it was frequently on when it wasn’t needed

5. Background on MacOS • Current power management (strategy “C”): inactivity timer • after 2 seconds of no activity and 15 seconds of no disk activity, processor turns off until next interrupt • Process scheduling: cooperative multitasking • processes switch out voluntarily • when a process switches out, it indicates a sleep period, the maximum amount of time it wants to remain unscheduled • if the process is busy, it will give a sleep period of zero

6. The basic strategy Energy and time costs to turn on and off the CPU are low Window-based operating systems are event-driven We want the CPU off whenever it is idle A process handles an event, then blocks The basic strategy (strategy “B”): Turn off the CPU when all processes are blocked, waiting for their next events However, there are some problems with the basic strategy on MacOS...

7. The simple scheduling technique • Problem: MacOS sometimes schedules processes when they do not need to be scheduled • i.e. it wakes them up after too little time asleep • Why? Well, it is a single-user OS; who would care? • Technique “I”: never schedule a process whose sleep time has not yet expired

8. Sleep extension technique • Why use sleep periods: to perform periodic tasks • blinking the cursor, checking if time for backups • Not a real-time system, so deadlines not critical • in fact, current inactivity-based strategy freely violates these deadlines • Therefore, perhaps it is reasonable to let processes sleep for longer • Technique “S”: multiply all sleep periods by a multipliers, set by user or OS to maximize energy savings while maintaining desired performance

9. The greediness technique • How processes should behave • receive event, process event, block for next event • perhaps, while waiting, do periodic tasks • How a process should not behave: “greediness” • failing to block, i.e. using sleep period 0, when not busy • happens often in MacOS • Technique “G”: • call a process greedy if it yields control g times without activity and without blocking • block greedy processes, but only for a certain period f, in case our heuristic is wrong

10. Trace-driven simulation • Trace collection (6 users): IdleTracer • only collects data while running on battery power • shuts off power management while tracing • Simulators: ItmSim (current strategy) and AsmSim (basic strategy) • Evaluation criterion 1: CPU energy savings • Evaluation criterion 2: Performance impact • estimated percent increase in workload completion time • increase comes from skipping over useful work when processor is off: when processor comes back on, such work must take place • heuristic: quantum is useful if it has activity or an event

11. Results 11.5%more battery lifetime than C 20.0% more battery lifetime than C Performance impact for C was 1.84%, so that was the impact for BIS and BIG. Performance impact for B and OPT was 0%. Performance impact for BI was 1.08%.

13. Problems with sleep extension • Not as much energy savings per unit performance impact as greediness technique • does not even work well as a supplement to greediness • Does not eliminate an important problem with basic strategy: processes that fail to block • this is why even BIS did not beat C for user 2 • Extending real-time sleep factors violates the user interface, and may produce undesirable effects

14. Future work • Implementation of strategies • Collection of additional traces • Adaptation of techniques to other OS’s • Completely different energy-saving techniques for the CPU, to get closer to optimal (or even surpass it!)

15. Conclusions • Basic strategy needs good CPU time management • Our suggested ways to improve CPU time management are: • never schedule processes that don’t want time • identify and block processes that are hogging the CPU • let processes sleep longer than they want to • With the best of these techniques, the basic strategy far surpasses the inactivity timer strategy • 53% less processor energy consumption • 20% more battery lifetime