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
• Weiser94, Govil95, Pering95, Grunwald00,
  Flautner02, Lorch03,
• 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 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
Interactive Task Scheduler
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
  events 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
Think Time
Event Interarrival Time (msecs)
10
Interactive Sessions

• 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

Load Length
0.2 2.34s
0.4 1.20s

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 gt lost frames,
  noise, etc
• Extant approaches gt 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)
I/O Drivers
CPU Load Sensors
CPU Clock Driver
Arbiter
event
event
KERNEL
Linux Scheduler
14
Arbiter
ARBITER RULES
POLICY STACK
Parameters
Set CPU speed as requested, however, if predicted
load lt 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 gt HiThr Increase speed Load Avg lt
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
Prediction

• Checkers generates periodic tasks
• CPU load alternates between idle and full load

I
Idle
G
GUI task
G
C
G
I
G
C
G
I
I
CPU util Predicted CPU util
0 -
1 0
0 1

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?
22
Future Work

• Enhance for platforms with low voltage scaling
  latency
• PPACE
• Provide application interface
• Grace-OS
• User level power manager
• Improvements to evaluation platform
• Better techniques to estimate event completion
• Voltage scaling

23
Results
5.55
4.36
24
Interactive Tasks

• Response time is critical for interactive tasks
• Human perception threshold 50 ms
• Lorch
• Rescheduling GUI events using PACE (a gradual CPU
  acceleration technique)
• Flautner
• Extend GUI events to perception threshold
• Applying to a real PDA
• Batch tasks interval scheduling
• Interactive tasks other scheduling, I.e. flat
  max, PACE based, etc.
• Challenge Slow voltage/frequency scaling response

25
Interval Scheduling

• Monitor CPU load in fixed intervals
• Future load is modeled as a function of past
• Many techniques exist
• Time-series
• Heuristics based on observations
• Weiser, Chan
• Considers immediate history only
• Intervals are short 1-50 ms.
• Not very effective

26
Application-assisted

• Grace-OS
• Targeting periodic multimedia applications
• EDF scheduling for soft-real time, round-robin
  for others
• Soft-RT Applications use system calls to mark
  start and end of tasks, Grace-OS maintains task
  deadline information
• Chameleon
• OS level interface
• Application implements power manager
• Application delegates power management to other
  processes

27
Results
28
Results
29
Results
30
Results PPACE Parameters

• Added PPACE
• An algorithm to reschedule voltage scaling for
  pre-deadline cycles
• Developed by Xu et al
• How much extra energy can be saved when voltage
  switch latency is low (i.e. ignorable)
• Rescheduling only interactive events
• 6 voltage transition points during the first 50
  milliseconds of execution

31
Results - PPACE
-Reduction for pre-deadline cycles of GUI events
only-
32
Energy Measurement

• iPAQ does not support voltage scaling
• Approximate voltage levels using XSA data
• Formula given in paper
• Frequency scaling data collected using
  microsecond resolution timer