AutoDVS: An Automatic, General-Purpose, Dynamic

Clock Scheduling System for Hand-Held Devices

Selim GurunChandra 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 yetFuel cells, ambient energy, . . .

2600 mAh 23 Grams

1450 mAh 45 Grams

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

Our Work: AutoDVS

• Goal: To provide a DVS system for handheld computers Real device/real applications Transparent to application Unobtrusive to user General-purpose

MultimediaInteractive applicationsGamesBatch tasks

Efficient even when the voltage switching latency is high

5

Typical Handheld Platform: iPAQ H3800

CPU

PERIPHERALDEVICES

6

Frequency Scheduling Timeline

Time

milliseconds

Old speed New speed

PRECLK Phase POSTCLK

Clock Scheduling Request Update Clock Speed

0 35 40

iPAQ H3800, Linux Kernel v2.4

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

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

• A period of user interaction: Each application has a specific pattern

Interactivity Sessions - Tetrix

Eve

nt I

nter

arri

val T

ime

(mse

cs)

Interactive SessionT

hink

Tim

e

10

Interactive Sessions

• A period of user interaction: Each application has a specific pattern

Interactivity Sessions - Solitaire

Eve

nt I

nter

arri

val T

ime

(mse

cs)

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

Load Length

0.2 2.34s

0.4 1.20s

… …

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

Architecture

Application 1 Application 2 Application 3G

UI

KE

RN

EL

Linux Scheduler

CPU ClockDriver

I/O Drivers

Event FilterInteractive Task

Scheduler (NWSLite)

CPU LoadSensors

Arbiter

(frqstep,len)

eventevent

14

Arbiter

CPU load average

Idle task entry count & period

Interactive CPU Load &

Period Length1

2

3CPU

Load

S

en

sor

Inte

ract

ive

Task

S

ched

ule

r 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

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

Interactive Workloads - Energy Factor

0.0

0.2

0.4

0.6

0.8

1.0

Dra Gen Sol Tet-1 Tet-2 Che-1 Che-2 Che-3 Avg

Ra

tio

to

MA

X

AutoDVS

IDEAL_FLAT

18

Results

Interactive Workloads - Stall Rate

0.0

0.1

0.2

0.3

0.4

0.5

Dra Gen Sol Tet-1 Tet-2 Che-1 Che-2 Che-3 Avg

Rat

io t

o M

AX

AutoDVS

IDEAL_FLAT

Periodic tasks

19

Checkers: Periodic Tasks

• Checkers generates periodic tasks

• CPU load alternates between idle and full load

G C G I G C G

GGUI task

CComputationally intensive task

I I

IIdle

Waiting for user input

Searching next move using Min-Max

CPU util

Predicted CPU util

0 -

1 0

0 1

… …

Prediction

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?