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 lot less of power, energy, volume, weight, patience 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 the system software contract is changed

new awareness: location, power, timing, reactivity, stability

Instrumented wide-area spaces

Personal area spaces

Internet end-points

In-body, in-cell, in-vitro spaces

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

Limited availability Energy and power uses of new devices is

markedly different from laptops and notebook computers much wider dynamic range of power demand increasing share of memory, communication and signal

processing multiple power use modalities depending upon application

“immortal”, “paging-mode RX”, “lifeline TX”, “mission-mode”P

roce

ssor

(MIP

S)

Har

d D

isk

(cap

acity

)

Memory (capacity

)

Battery (energy stored)

0 1 2 3 4 5 6

16x

14x

12x

10x

8x

6x

4x

2x1xIm

pro

vem

ent

(co

mp

ared

to

yea

r 0)

Time (years)

J. Rabaey, BWRC

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).

Energy

Time

State 4

State1 State2 State3

t1 t2 t3

ii TimeEnergy )(For each state i, plot:

Lower Envelope Idea

LEA can be deterministic or probabilistic PLEA is e/(e-1) competitive.

Experimental Study: IBM Mobile Hard Drive

0s02.4Active/Busy

40ms0.560.9Idle

1.5s1.5750.2Stand-by

5s4.750Sleep

Transition Time to Active

Start-up Energy (Joules)

Power Consumption

State

Trace data with arrival times of disk accesses Trace data with arrival times of disk accesses from Auspex file server archive.from Auspex file server archive.

IBM Mobile Hard Drive

0

0.5

1

1.5

2

2.5

0 500 1000 1500 2000 2500

Latency

Co

mp

etit

ive

Ra

tio w

rt

En

erg

y U

sag

e

Optimal

LEA

PLEA

LAST:P

LAST:NP

TREE:P

EXP:P

EXP:NP

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

OperatingSystem

OperatingSystem

Modified OS Services

Hardware Abstraction Layer

PA-HAL

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 Functionspaapi_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

Compaq IPAQrunning eCos

80200EVB w/ voltage scaling board andthe host system

Maxim board for voltage scaling

Using Power Aware OS: Example

void main() { mpeg_decoding_t = paapi_dvs_create_thread_type(100,30,100,hard);

paapi_dvs_set_policy(SHUTDOWN | STATIC DYNAMIC | ADAPTIVE);

paapi_dvs_create_thread_instance( mpeg_decoding_t, mpeg_decode_thread);}...

void mpeg_decode_thread(){ for (;;) { paapi_dvs_app_started(); /* original code */ mpeg_frame_decode() paapi_dvs_app_done(); }}

• 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).

periodWCET

deadline

Kills the thread instance whendeadline is missed

Selects the DVS policy for all threads

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.

Task Application WCET (us) Std Dev (us)

T1 MPEG2 (wg_gdo_1.mpg) 30700 3100

T2 MPEG2 (wg_cs_1.mpg) 26300 2100

T3 ADPCM 9300 3300

T4 FFT 15900 0

T5 FFT (gaussian distribution) 13600 800

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 Set

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

We used three tasksets based on the applications described earlier as shown in the table below:

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) Voltage (Volts)733 666600533466400333

1.5 1.4 1.3

1.25 1.2 1.1 1.0

Results: Taskset A

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





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%

Results: Taskset B


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






• Column deadlines missed shows the number of deadlines missed per task (T2, T3, T4) for a total of 130/65/43 executions respectively

Results: Taskset C


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






• Column deadlines missed shows the number of deadlines missed per task (T1, T3, T5) for a total of 130/65/43 executions respectively

OS-directed DVS Results

Energy Consumption for each scheme

0

0.2

0.4

0.6

0.8

1

1.2

No

rma

l

Onl

y S

hutd

ow

n

Shu

t./S

tatic

Shu

t./S

tatic

/Dyn

.

Shu

t./S

tatic

/Dyn

./Ad

ap

t. (0

.95

)

Shu

t./S

tatic

/Dyn

./Ad

ap

t. (0

.90

)

Shu

t./S

tatic

/Dyn

./Ad

ap

t. (0

.85

)

Shu

t./S

tatic

/Dyn

./Ad

ap

t. (0

.80

)

Shu

t./S

tatic

/Dyn

./Ad

ap

t. (0

.75

)

Scheme

Ra

tio

of

en

erg

y c

on

su

mp

tio

n

be

twe

en

No

rma

l an

d S

ch

em

e

Taskset A

Taskset B

Taskset C

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

ACPI TablesACPI BIOSACPI Registers

Kernel

DeviceDriver

ACPIRegisterInterface

ACPI TableInterface

ACPI BIOSInterface

- ACPI Spec Covers this area.- OS specific technology, not part of ACPI.- Hardware/Platform specific technology, not part of ACPI.

Platform Hardware

Existingindustrystandardregister

interfaces to:CMOS, PIC,

PITs, ...

ACPI Driver/AML Interpreter

ApplicationsOS

DependentApplication

APIs

OS Specifictechnologies,

interfaces, and code.

OSIndependenttechnologies,

interfaces,code, andhardware.

BIOS

OSPM System Code

G3 -MechOff

Legacy

WakeEvent

G0 (S0) -Working

G1 -Sleeping

S4S3

S2S1

PowerFailure

G2 (S5) -Soft Off

BIOSRoutine

C0

D0D1

D2D3

Modem

D0D1

D2D3HDD

D0D1

D2D3

CDROM

C2C1

Cn

PerformanceState Px

Throttling

C0

CPU

ACPI Processor Power States

InterruptInterrupt

HLT

P_LVL2

THT_EN=1and

DTY=value

THT_EN=0

Full Speed Throttling

C1 C2 C3

P_LVL3,ARB_DIS=1

Interrupt orBM Access

G0Working

C0

Latency

C1 < C2 < C3

Power

C1 > C2 > C3

Power Throttling

Overview of ACPI System States

G0

State CPU Memory Context TrackingC0: Executing @ Full Speed C1:C3 Executing in PM state (ie Thermal Throttle/HLT)

DevicesPowered Up & Downbased on demandD0-D3

S1

Wake Up

Not ExecutingContext Retained CPU CLK: OFFSystem CLK: ONPower: ON

Retained Power : ONRefresh : Normal

Devices Power downdepending on wakeup &power requirements

Lowest LatencyRestart @ CS:IP +1

H/W responsible for savingcontext of CPU, System I/O,& Memory

S2Not ExecutingCPU/Sys Cache Context LostCPU CLK: OFFSystem CLK: OFFPower: ON

RetainedPower : ONRefresh : Standby / Auto

Latency > S1Restart @ Boot Vector

H/W responsible for savingcontext of System I/O & MemoryOS responsible for saving CPU context

S3 Not ExecutingCPU/Cache Context LostCPU CLK: OFFSystem CLK: OFFPower: OFF

RetainedPower : ONRefresh : Standby / Auto


H/W responsible for saving Memory context BIOS restores Memory Controller Context. OS responsible for saving CPU & System I./O context

Working

Sleeping

Sleeping

Sleeping

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

S4 Not ExecutingCPU/Cache Context LostEverything: OFF

Context LostPower : OFFRefresh : N/A


OS(S4) / BIOS(S4bios) is responsible for saving and restoring all system context, including memory

S4BIOSSleeping

G2/S5 OFF OFF Devices are OFF,Power Button Press willwake up the system


OS uses S5 to turn the machine off

Soft OFF




Retained Power: ONRefresh: Normal

Summary of functional areascovered 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 energy by

transitioning devices and processors into different states when the system is active.

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 provides a model to allow OEMs to define thermal zones, thermal indicators, and

methods for cooling thermal zones.

A standard hw and sw interface between OS and Embedded Controller allows any OS to provide a standard bus enumerator that can directly communicate with

an embedded controller in the system, thus allowing other drivers within the system to communicate with and use the resources of system embedded controllers.

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

Documents

Power Aware Software Architecture