Transcript Power Aware Software Architecture

Power Aware Software
Architecture
Rajesh K. Gupta
University of California, Irvine
The “Noveau Rich” in Computing
 Generational shift in computing devices
lot more of everything including networking and
communications
 Instrumented
lot less of power, energy, volume, weight, patience
wide-area spaces
Internet end-points
 Application is everything, the possibilities are limitless

 System architectures are due for an overhaul



the architectures are (radically) changed/challenged
the programming context is changed
In-body, in-cell, in-vitro spaces
Personal area spaces
the system software contract is changed
 new awareness: location, power, timing, reactivity, stability
Outline
 The case for power awareness in


application development
system software
 Managing power in the OS

knobs and strategies
 Making software power aware


the hardware knobs (DVS, DPM)
the application knobs (duty cycling, criticality, aesthetics)
 An ongoing experiment
The Case for Power Awareness
16x
IP
S)
 Limited availability
 Energy and power uses of new devices is
ac
ap
es
(c
oc
12x
Pr
Im p ro v e m e n t (c o m p a re d to y e a r 0 )
so
ity
)
r(
M
14x



k
markedly different from laptops and notebook
computers
ar
d
D
is
10x
H
8x
J. R abaey , B W R C
6x
(c
a
c
pa
ity
)
much wider dynamic range of power demand
increasing share of memory, communication and signal
processing
multiple power use modalities depending upon application
M
4x
em
o
ry
B a tte ry (e n e rg y s to re d )
2x
1x
0
1
2
3
4
5
6
T im e (y e a rs )
 “immortal”, “paging-mode
RX”, “lifeline TX”, “mission-mode”
Power Management Places
 Hardware & firmware

don’t know the global state and application-specific knowledge
 Users

don’t know component characteristics, and can’t make frequent
decisions
 Applications


operate independently
and the OS hides machine information from them
 OS plays an important role in allocation, sharing of
critical resource


it is a logical place for dynamic power management
application-specific constraints and opportunities for saving energy that
can be known only at that level
Operating System Directed
Power Management
 Significant opportunities in power management lie with
application-specific “knobs”

quality of service, timing criticality of various functions
 Needs of applications are driving force for OS power
management functions & power-based API

collaboration between applications and the OS in setting “energy use
policy”
 OS helps resolve conflicts and promote cooperation
 OS is the most reasonable place, but…
 OS should incorporate application information in power management
 OS should expose power state and events to applications for them to
adapt.
Power Savings Mechanisms
 Dynamic Power Management (DPM)

When a device is idle, it can transition to low-power “sleep”
states. .
 Dynamic Voltage Scaling (DVS)


A device can be run at different speeds at different power
levels
Execution of jobs can be slowed down to save power as
long as all jobs are completed by their deadline.
 Plus any application level “knobs”

quality and performance measures, application tolerances
Implementing DVS
 Often done using slowdown factors

can be static or dynamic
 For example:




Given a frequency range of [fmin ,fmax ]
Slowdown factor is frequency scaled to [min,1], where
min = fmin /fmax..
When we use a slowdown factor of , we set the frequency
to, f = * fmax .
The voltage is changed to the minimum voltage supported
at f.
Slowdown Factors
 Much of the work in the context of real-time
systems

makes sense since we need something to tradeoff against
power saved
 Known results

Essentially use schedulability tests to determine amount of
slowdown possible
Our Work In Context
 DPM for devices with multiple active and
multiple sleep states.
 Design and analyze algorithms for systems that
allow both DPM and DVS.
Dynamic Power Management
 When a device becomes idle, it can transition to
lower power usage state.
 A fixed amount of additional time and energy are
required to transition back to active state when a
new request for service arrives.
 What is the best time threshold to transition to
the sleep state?
Too soon: pay start-up cost too frequently.
 Too late: spend too much time in the high-power state
 Generally, transition to sleep state when the cost of
being in active state is at least the cost of `waking up’.

Multi-state Case
 Let there be k+1 states






Let State k be the shut-down state and 0 be the active state
Let i be the power dissipation rate at state i
Let i be the total energy dissipated to move back to State k
States are ordered such that i+1  i
k = 0 and 0 = 0 (without loss of generality).
Power down energy cost can be incorporated in the power up cost
for analysis (if additive).
Lower Envelope Idea
State1
State2
State3
State 4
Energy
t1
t2
t3
Time
For each state i, plot: Energy   i (Time )   i
 LEA can be deterministic or probabilistic

PLEA is e/(e-1) competitive.
Experimental Study: IBM Mobile Hard Drive
State
Power
Consumption
Start-up Energy
(Joules)
Transition Time
to Active
Sleep
0
4.75
5s
Stand-by
0.2
1.575
1.5s
Idle
0.9
0.56
40ms
Active/Busy
2.4
0
0s
Trace data with arrival times of disk accesses
from Auspex file server archive.
IBM Mobile Hard Drive
Competitive Ratio wrt
Energy Usage
2.5
Optimal
LEA
PLEA
LAST:P
LAST:NP
TREE:P
EXP:P
EXP:NP
2
1.5
1
0.5
0
0
500
1000
1500
Latency
2000
2500
Goal
 Provide ways by which Application, Operating
System and Hardware can exchange
energy/power and performance related
information efficiently.
 Facilitate the continuously dialogue / adaptation
between OS / Applications.
 Facilitate the implementation of power aware OS
services by providing a software interface to low
power devices

A power-aware API to the end user that enables one to
implement energy-efficient RTOS services and applications
Power-aware API Requirements
 Independent of Hardware and RTOS implementations

enables its use in different hardware platforms
 for this all routines should access the HAL (Hardware Abstraction Layer)
rather than the Hardware directly

enables its use in different RTOS as well as its use with different scheduling
strategies
 do not count on specific RTOS info and/or specific schedulers
 Services provided

processor frequency scaling and low-power state transitions
 with costs of making such transitions


battery status (if the system is battery based)
appropriate routines to control energy-speed and energy-accuracy knobs
available on I/O devices:
 network interface, serial interface, LCD, etc.
Power-aware API
The applications interface provides the following services:
 The application is able to



tell RT information to OS (period, deadlines, WCET, hardness)
create new threads
tell OS time predicted to finish a given task instance
 depending on the conditions of the environment (application dependent and
not yet implemented)
 OS must be able to predict and tell applications the time estimated
to finish the task

depends on the scheduling scheme used
 A hard task must be killed if its deadline is missed.
A Power-Aware Software
Architecture
Application
PA-API
PA-Middleware
POSIX
PA-OSL
Operating
System
Modified
OS Services
Operating
System
PA-HAL
Hardware Abstraction Layer
Hardware
Power Aware Software
Architecture
 PA-API (Power Aware API)

interfaces applications and OS making
the power aware OS services available
to the application writer.
 PA-OSL (Power Aware
Operating System Layer)

implements modified OS services and
active components such as a DPM
manager.
 PA-HAL (Power Aware
Hardware Abstraction Layer)

interfaces OS and Hardware making
the power control knobs available to
the OS programmer.
Software Architecture
 PA-API - Power aware function calls available to the application writer.

Some functions of this layer are specific to certain scheduling techniques.
 PA-Middleware - Power aware services

implemented on the top of the OS (power management threads, data handling, etc...).
 POSIX - Standard interface for OS system calls.

This isolates PA-API and PA-Middleware from OS.
 PA-OSL - Power aware OS layer.

Calls related to modified OS services should go through this level. Also isolates OS from
PA-API and PA-Middleware.
 PA-HAL - Power Aware Hardware Abstraction Layer.

Isolates OS from underlying power aware hardware.
 Modified OS services

Implementation / modification of OS services in a power related fashion. Ex: scheduler,
memory manager, I/O, etc.
Layer Functionality
Layer
Function name
PA-API
paapi_dvs_create_thread_type(), paapi_dvs_create_thread_instance()
paapi_dvs_app_started(), paapi_dvs_get_time_prediction()
paapi_dvs_set_time_prediction(), paapi_dvs_app_done(),
paapi_dvs_set_adaptive_param()
paapi_dvs_set_policy(), paapi_dpm_register_device()
PA-OSL
paosl_dvs_create_task_type_entry(), paosl_dvs_create_task_instance_entry(),
paosl_dvs_killer_thread(), paosl_dvs_killer_thread_alarm_handler(),
paosl_dpm_register_device(), paosl_dpm_deamon()
PA-HAL
pahal_dvs_initialize_processor_pm(), pahal_dvs_get_frequency_levels_info()
pahal_dvs_get_current_frequency(), pahal_dvs_set_frequency_and_voltage()
pahal_dvs_pre_set_frequency_and_voltage(),
pahal_dvs_post_set_frequency_and_voltage()
pahal_dvs_get_lowpower_states_info(), pahal_dvs_set_lowpower_state()
pahal_dpm_device_check_activity(), pahal_dpm_device_pre_switch_state()
pahal_dpm_device_switch_state(), pahal_dpm_device_post_switch_state()
pahal_dpm_device_get_info(), pahal_dpm_device_get_curr_state()
pahal_battery_get_info()
DVS Related Functions
paapi_dvs_create_thread_type(), paapi_dvs_create_thread_instance()
creates type and instance of a task respectively
paapi_dvs_app_started(), paapi_dvs_app_done()
delimits execution of useful work in a thread. Tell the OS whether the task has
finished execution or not.
paapi_dvs_get_time_prediction(), paapi_dvs_set_time_prediction()
get current execution time prediction for a given thread
paapi_dvs_set_adaptive_param()
set the paremeters of the adaptive policy (it will be described later) for a given
task.
paapi_dvs_set_policy()
choses the policy to be using for DVS
DVS Related Functions (contd.)
paosl_dvs_create_task_type_entry(), ...
create a type and an instance of a thread in the kernel internal tables of type and
instance respectively
paosl_dvs_killer_thread()
kills a thread that missed a deadline
pahal_dvs_initialize_processor_pm()
initialize structures for processor power management
pahal_dvs_get_current_frequency(),
pahal_dvs_set_frequency_and_voltage()
pahal_dvs_pre_set_frequency_and_voltage(),
pahal_dvs_get_frequency_levels_info()
pahal_dvs_post_set_frequency_and_voltage()
functions to switch processor among possible frequencies levels
pahal_dvs_get_lowpower_states_info(),
pahal_dvs_set_lowpower_state()
functions to switch processor among low power states
DPM Functions
 paapi_dpm_register_device()

just register the device to be power managed
 paosl_dpm_deamon()

implements the actual policy for a specific device. This deamon uses PA-HAL
functions to decide on how to switch devices among all possible states.
 pahal_dpm_device_switch_state()

switch device’s state
 pahal_dpm_device_check_activity()

check whether the device has been idle and for how long. This functions needs
support from the device driver.
 pahal_dpm_device_get_info(), pahal_dpm_device_get_curr_state()

gets information about the device and about its current state respectively
 Others

functions for helping implementing power policies. For example:
 pahal_battery_get_info() – gets battery status
Current Status
 API specification available from

http://www.ics.uci.edu/~cpereira/pads/
 Implementation

eCOS RTOS:
 open source, Object oriented and highly configurable RTOS
(by means of scripting language)

Hardware platforms we are currently working with:
 Linux-synthetic (emulation of eCos over Linux - debugging
purposes only)
 Compaq iPaq Pocket PC - StrongARM SA1110 based
platform
 Accelent IDP (Integrated Development Environment) - also
StrongARM SA1110 based.
 LRH Intel evaluation board 80200EVB - Intel Xscale based
Implementation
80200EVB w/ voltage scaling board and
the host system
Maxim board for voltage scaling
Compaq IPAQ
running eCos
Using Power Aware OS: Example
• The scheduler adapts frequency according to the real time parameters passed
in as parameter on the thread type.
• The frequency is adjusted by means of factors by which it is multiplied
resulting in lower speed (a factor can also speed up the processor if it is > 1).
deadline
void main()
WCET
period
{
mpeg_decoding_t =
paapi_dvs_create_thread_type(100,30,100,hard);
paapi_dvs_set_policy(SHUTDOWN | STATIC
DYNAMIC | ADAPTIVE);
Selects the DVS policy for all threads
paapi_dvs_create_thread_instance(
mpeg_decoding_t, mpeg_decode_thread);
}
...
Kills the thread instance when
deadline is missed
void mpeg_decode_thread()
{
for (;;) {
paapi_dvs_app_started();
/* original code */
mpeg_frame_decode()
paapi_dvs_app_done();
}
}
An Experiment
 Application + OS running on
80200 XScale board
 Altera FPGA board generating
interrupts to wake up the
processor
 Maxim board providing voltage
scaling
 Host PC for debugging and for
loading the App. + OS into the
board
The Experiment with DVS
 Shutdown when idle

as soon as CPU becomes idle shutdown the processor
 Shutdown + static slow down factors

offline slow down factors are applied. The CPU is shutdown when idle.
 Shutdown + static slow down + dynamic slow down

run-time slow down factors are computed based on a history of
execution times in addition to the static and shutdown
 Shutdown + static slow down + dynamic slow down +
adaptive slow down

a deadline driven factor is also applied in addition to the other factors
and shutdown. This factor adapts itself according to number of deadline
missed in a previous window of executions.
DVS Experiment
 Four parameters are defined for the adaptive factor:




% of deadlines missed tolerable (D) every W executions
Window size (W)
Lower bound for the factor (L)
Increments and decrement steps (Inc and Dec)
 For every W executions

if the number of deadlines missed is less than D
 lower the adaptive factor by Dec if it is greater than L, otherwise
keep it as it was.

if the number of deadlines is greater than D
 increment the adaptive factor by Inc.
Application Set
 Three different real applications running concurrently:



An MPEG2 decoder
An ADPCM (Adaptive Differential Pulse Code Modulation) speech
enconding
Floating point FFT application
Task
T1
Application
MPEG2 (wg_gdo_1.mpg)
WCET (us) Std Dev (us)
30700
3100
T2
MPEG2 (wg_cs_1.mpg)
26300
2100
T3
T4
ADPCM
FFT
9300
15900
3300
0
T5
FFT (gaussian distribution)
13600
800
Task Set
 We used three tasksets based on the applications
described earlier as shown in the table below:
Taskset
Characteristics
Static Factors
A
T1 = (26300, 40000, 40000)
T3 = ( 9300, 80000, 80000)
T4 = (15900, 120000, 120000)
0.9495
B
T2 = (30700, 47000, 47000)
T3 = ( 9300, 94000, 94000)
T4 = (15900, 141000, 141000)
0.8979
C
T1 = (30700, 45000, 45000)
T3 = ( 9300, 90000, 90000)
T5 = (13600, 135000, 135000)
0.9207
Frequency & Voltage Scaling
 For the 4 schemes and the 3 tasksets experimented we
measured processor power consumption using a shunt resistor
and a DAQ board.
 The voltage of the Xscale processor is dynamically varied
according to the frequency as in the table below:
Frequency (Mhz)
733
666
600
533
466
400
333
Voltage (Volts)
1.5
1.4
1.3
1.25
1.2
1.1
1.0
Results: Taskset A
 Column deadlines missed shows the number of deadlines missed per task
(T1, T3, T4) for a total of 415/207/138 executions respectively. For the
adaptive algorithm, M varies as the number between parentheses, Inc=0.1,
Dec=0.5, W=10 and D=20%
Scheme
Energy Power Ratio
Deadlines missed
Normal
39.085
0.779
1
0/0/0
Only Shutdown
31.504
0.628
0.80
0/0/0
Shut./Static
32.024
0.638
0.81
0/0/0
Shut./Static/Dyn.
28.496
0.568
0.72
1/1/2
Shut./Static/Dyn./Adapt. (0.95)
26.581
0.527
0.68
3/2/1
Shut./Static/Dyn./Adapt. (0.90)
26.258
0.522
0.67
3/2/1
Shut./Static/Dyn./Adapt. (0.85)
25.251
0.502
0.64
3/1/4
Shut./Static/Dyn./Adapt. (0.80)
24.835
0.494
0.63
3/2/51
Shut./Static/Dyn./Adapt. (0.75)
24.330
0.483
0.62
3/2/63
Results: Taskset B
• Column deadlines missed shows the number of deadlines missed per task (T2,
T3, T4) for a total of 130/65/43 executions respectively
Scheme
Energy Power Ratio
Deadlines missed
Normal
12.546
0.798
1
0/0/0
Only Shutdown
11.265
0.716
0.89
0/0/0
Shut./Static
9.819
0.624
0.78
1/0/1
Shut./Static/Dyn.
9.811
0.624
0.78
1/0/1
Shut./Static/Dyn./Adapt. (0.95)
9.795
0.623
0.78
1/0/1
Shut./Static/Dyn./Adapt. (0.90)
8.815
0.562
0.70
1/1/31
Shut./Static/Dyn./Adapt. (0.85)
8.828
0.562
0.70
1/1/31
Shut./Static/Dyn./Adapt. (0.80)
8.185
0.522
0.65
34/10/34
Shut./Static/Dyn./Adapt. (0.75)
8.211
0.525
0.65
34/10/34
Results: Taskset C
• Column deadlines missed shows the number of deadlines missed per task (T1,
T3, T5) for a total of 130/65/43 executions respectively
Scheme
Energy Power Ratio
Deadlines missed
Normal
13.080
0.838
1
0/0/0
Only Shutdown
12.342
0.772
0.94
0/0/0
Shut./Static
12.391
0.789
0.94
0/0/0
Shut./Static/Dyn.
10.892
0.693
0.83
0/1/18
Shut./Static/Dyn./Adapt. (0.95)
10.958
0.697
0.83
0/1/18
Shut./Static/Dyn./Adapt. (0.90)
9.875
0.627
0.75
1/8/32
Shut./Static/Dyn./Adapt. (0.85)
9.990
0.637
0.76
11/16/32
Shut./Static/Dyn./Adapt. (0.80)
9.889
0.631
0.75
11/16/32
Shut./Static/Dyn./Adapt. (0.75)
9.789
0.624
0.74
11/16/32
Scheme
Shut./Static/Dyn./Adap
t. (0.75)
Shut./Static/Dyn./Adap
t. (0.80)
Shut./Static/Dyn./Adap
t. (0.85)
Shut./Static/Dyn./Adap
t. (0.90)
Shut./Static/Dyn./Adap
t. (0.95)
Shut./Static/Dyn.
Shut./Static
Only Shutdown
Normal
Ratio of energy consumption
between Normal and Scheme
OS-directed DVS Results
Energy Consumption for each scheme
1.2
1
0.8
Taskset A
0.6
Taskset B
0.4
Taskset C
0.2
0
Using Application-level “knob”
 Example: Image Compression Algorithm





tradeoff image quality against energy available by varying
the compression parameters such as BPP (bits per pixel)
The image compression algorithm is ran in a continuous
loop with battery polling every 10 secs.
A simple power tradeoff policy is added to adapt the quality
of the image against the battery voltage left.
Whenever the battery drops 30mV the application adjusts
the image BPP by -0.5 starting at 1.5.
For a cut-off of 4020mV, the battery life is extended from
290 seconds to 340 seconds.
• The battery life is extended by 18% with a slight (= “not
noticeable by human eye”) degradation of image quality
Concluding Remarks
 Computers with radios present a very wide
range of system optimization opportunities for
power, size and performance
 Efficient power and energy management is key
to enabling new range of applications
 Energy efficiency is a system-level concern that
cuts across subsystem components,
functionality layers and its implementations
 Application programming needs to be energy
aware and provide knobs for the system
designer to incorporate in DPM.
Yes, but Microsoft...
… and others have already solved the
problem?
Operating System Power
Management (OSPM)
 Supported by Microsoft’s desktop operating
systems via APM - Advanced Power
Management




OS/BIOS co-operation
When OS goes to idle condition it performs an access to a
register that causes an SMI#
SMI handler puts system into low power state
APM required OS to trust the system BIOS
Current OSPM - ACPI
 Advanced Configuration and Power Management
Interface (ACPI)


OS visible (SCI-based) as opposed to OS invisible (SMI-based)
OS/drivers/BIOS are in sync regarding power states
 Standard way for the system to describe its device
config. & power control h/w interface to the OS

register interface for common functions
 system control events, processor power and clock control,
thermal management, and resume handling
 Info on devices, resources, & control mechanisms
 Thermal Management
Applications
Kernel
Device
Driver
OS
Dependent
Application
APIs
OSPM System Code
ACPI Driver/
AML Interpreter
ACPI Table
Interface
ACPI
Register
Interface
Existing
industry
standard
register
interfaces to:
CMOS, PIC,
PITs, ...
OS Specific
technologies,
interfaces, and code.
ACPI BIOS
Interface
ACPI Registers
ACPI BIOS
OS
Independent
technologies,
interfaces,
code, and
hardware.
ACPI Tables
Platform Hardware
- ACPI Spec Covers this area.
- OS specific technology, not part of ACPI.
- Hardware/Platform specific technology, not part of ACPI.
BIOS
P o w er
F a ilu re
G 3 -M e c h
O ff
M o d em
HDD
D3
D3
D2
D2
D1
D1
D0
D0
CD ROM
D3
D2
D1
D0
C0
B IO S
R o u tine
S4
S3
S2
S1
G 0 (S 0 ) W o r k in g
Legacy
G1 S le e p in g
W ake
Even t
Perf orm anc e
St at e Px
T hrott ling
C0
C1
G 2 (S 5 ) S o ft O ff
C2
CPU
Cn
ACPI Processor Power States
Power Throttling
Latency
TH T_EN = 1
an d
D T Y = va lu e
C1 < C2 < C3
C0
Full Spee d
Throttling
TH T_EN = 0
I n ter ru p t o r
B M A cc ess
H LT
P _L V L 2
I n ter ru p t
I n ter ru p t
C1
Power
C1 > C2 > C3
C2
G0
W o rk in g
P _L V L 3,
A R B _D I S = 1
C3
Overview of ACPI System States
State
G0
Working
S1
Sleeping
S2
Sleeping
S3
Sleeping
S4
S4BIOS
Sleeping
G2/S5
Soft OFF
CPU
Memory
Devices
Wake Up
Context Tracking
C0: Executing @ Full Speed
C1:C3 Executing in PM state
(ie Thermal Throttle/HLT)
Retained
Power: ON
Refresh: Normal
Powered Up & Down
based on demand
D0-D3
Not Executing
Context Retained
CPU CLK: OFF
System CLK: ON
Power: ON
Retained
Power : ON
Refresh : Normal
Devices Power down
depending on wakeup &
power requirements
Not Executing
CPU/Sys Cache Context Lost
CPU CLK: OFF
System CLK: OFF
Power: ON
Retained
Power : ON
Refresh : Standby /
Auto
Devices Power down
depending on wakeup &
power requirements
Not Executing
CPU/Cache Context Lost
CPU CLK: OFF
System CLK: OFF
Power: OFF
Retained
Power : ON
Refresh : Standby /
Auto
Devices Power down
depending on wakeup &
power requirements
Latency > S2
Restart @ Boot
Vector
Not Executing
CPU/Cache Context Lost
Everything: OFF
Context Lost
Power : OFF
Refresh : N/A
Devices Power down
depending on wakeup &
power requirements
Latency > S3
Restart @ Boot
Vector
OS(S4) / BIOS(S4bios) is
responsible for saving and restoring
all system context, including memory
OFF
OFF
Devices are OFF,
Power Button Press will
wake up the system
Latency > S4
Restart @ Boot
Vector
OS uses S5 to turn the machine off
Lowest Latency
Restart @ CS:IP
+1
Latency > S1
Restart @ Boot
Vector
H/W responsible for saving
context of CPU, System I/O,
& Memory
H/W responsible for saving
context of System I/O & Memory
OS responsible for saving CPU
context
H/W responsible for saving
Memory context BIOS restores
Memory Controller
Context. OS responsible for saving
CPU & System I./O context
NOTES:
- OS chooses the lowest supported sleep state in which all enabled wakeup devices still functions under the latency requirements from apps.
- ASL binds each Sx state to a SLP_TYP value, which based on platform design of power planes & clocking logic det what portions of the h/w power down.
- For each Device, ASL lists which power resources are needed to maintain a ‘wakeup’ capable state
- ‘System I/O’ refers to Motherboard Devices: PIT, PIC, DMAC, NMI State....OS saves & restores this stuff for S3
Summary of functional areas
covered by ACPI
 System Power Management

ACPI defines mechanisms for putting the computer as a
whole in and out of system sleeping states.
 Device Power Management

ACPI tables describe devices, their power states, the power
planes the devices are connected to, and controls for putting
devices into different power states.
 Processor power management

While the OS is idle but not sleeping, it will use commands
described by ACPI to put processors in low-power states.
 Device and processor performance management

DPM to achieve desirable balance between performance and
ACPI functionalities (cont.)
 Plug and Play

hierarchically arranged device and configuration
information
 System Events

a general event mechanism for system events such as
thermal events, power management events, docking, device
insertion and removal, and so on
 Battery management

either through a Smart Battery subsystem interface
controlled by the OS directly through the embedded
controller interface, or a Control Method Battery interface.
 Thermal management
Microsoft’s OnNow
 Win32 API extension allows applications to


affect the power management decision making
adapt to power state
 find out if running on batteries so as to reduce processing
 discover disk state & postpone low priority I/O
e.g. paging
 Requires changes in hardware, firmware (BIOS),
OS, and application software



bus & device power management standards for h/w
ACPI interface standard between OS & hardware
integration of power management into app control
OnNow Components
Ref.: Microsoft’s “OnNow Power Management Architecture for Applications”
OnNow Architecture
 User’s view: system is either on or off
 Reality: system transitions among a number of
“power states” according to OS’s power policy
 Global power states


working: apps are executing
sleep: software is not executing, & CPU is stopped
 OS tracks user’s activities & application execution states to
decide when to enter sleep
monitor user input, hints from applications
 wake-up is time-based or device-based

off: system has shutdown and must reboot