Introduction

Download Report

Transcript Introduction

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
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
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
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
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
The basic strategy
Energy and time costs to turn
on and off the CPU are low
We want the CPU off
whenever it is idle
Window-based operating
systems are event-driven
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...
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
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
multiplier s, set by user or OS to maximize energy
savings while maintaining desired performance
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
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
Processor energy savings
(%)
Results
100
90
80
70
60
50
40
30
20
10
0
Energy savings for each strategy
82.33
66.18
51.72
47.1
28.79
31.98
C
B
BI
Strategy
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%.
BIS
BIG
OPT
11.5% more
20.0% more
battery lifetime battery lifetime
than C
than C
Energy savings for each user
Processor energy
savings (%)
C
B
BI
BIS
BIG
100
90
80
70
60
50
40
30
20
10
0
1
2
3
4
User
5
6
1-6
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
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!)
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