MISSION TO SOLUTIONS

Document Sample
MISSION TO SOLUTIONS Powered By Docstoc
					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 of power, energy, volume, weight, patience lot less 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-cell, in-vitro spaces In-body, 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
the hardware knobs (DVS, DPM) the application knobs (duty cycling, criticality, aesthetics)

 Making software power aware
 

 An ongoing experiment

The Case for Power Awareness
 Limited availability  Energy and power uses of new devices is
(M

16x 14x 12x

IP

S)

es so r

Improvement (compared to year 0)

oc

10x markedly different from laptops and notebook 8x ) J. computersRabaey, BWRC ity ac p
Ha rd

Pr






much wider dynamic range of power demand M 4x increasing share of memory, communication and signal Battery (energy stored) 2x processing 1x multiple power use modalities depending upon application 0 1 2 3 4 5 6
ry mo e

6x

 “immortal”, “paging-mode RX”, “lifeline TX”, “mission-mode”
Time (years)

Di

sk

(ca

(c

ap ac ity

)

Power Management Places
 Hardware & firmware


don‟t know the global state and application-specific knowledge don‟t know component characteristics, and can‟t make frequent decisions operate independently and the OS hides machine information from them

 Users


 Applications
 

 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.
quality and performance measures, application tolerances

 Plus any application level “knobs”


Implementing DVS
 Often done using slowdown factors


can be static or dynamic 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.

 For example:








Slowdown Factors
 Much of the work in the context of real-time
systems


makes sense since we need something to tradeoff against power saved Essentially use schedulability tests to determine amount of slowdown possible

 Known results


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
Sleep Stand-by Idle Active/Busy
Power Consumption Start-up Energy (Joules) Transition Time to Active

0 0.2 0.9 2.4

4.75 1.575 0.56 0

5s 1.5s 40ms 0s

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

IBM Mobile Hard Drive
2.5

Competitive Ratio wrt Energy Usage

2

1.5

1

0.5

Optimal LEA PLEA LAST:P LAST:NP TREE:P EXP:P EXP:NP

0 0 500 1000 1500 2000 2500

Latency

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.
implemented on the top of the OS (power management threads, data handling, etc...). This isolates PA-API and PA-Middleware from OS. Calls related to modified OS services should go through this level. Also isolates OS from PA-API and PA-Middleware. Isolates OS from underlying power aware hardware. Implementation / modification of OS services in a power related fashion. Ex: scheduler, memory manager, I/O, etc.

 PA-Middleware - Power aware services


 POSIX - Standard interface for OS system calls.


 PA-OSL - Power aware OS layer.


 PA-HAL - Power Aware Hardware Abstraction Layer.


 Modified OS services


Layer Functionality
Layer Function name
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() 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-API

PA-OSL

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 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. switch device‟s state check whether the device has been idle and for how long. This functions needs support from the device driver.

 paosl_dpm_deamon()


 pahal_dpm_device_switch_state()


 pahal_dpm_device_check_activity()


 pahal_dpm_device_get_info(), pahal_dpm_device_get_curr_state()


gets information about the device and about its current state respectively
functions for helping implementing power policies. For example:
 pahal_battery_get_info() – gets battery status

 Others


Current Status
 API specification available from


http://www.ics.uci.edu/~cpereira/pads/ eCOS RTOS:
 open source, Object oriented and highly configurable RTOS (by means of scripting language)

 Implementation




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).
void main() WCET period { mpeg_decoding_t = paapi_dvs_create_thread_type(100,30,100,hard); paapi_dvs_set_policy(SHUTDOWN | STATIC DYNAMIC | ADAPTIVE);

deadline

Selects the DVS policy for all threads
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(); } }

Kills the thread instance when deadline is missed

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 offline slow down factors are applied. The CPU is shutdown when idle. 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 factors


 Shutdown + static slow down + dynamic slow down


 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
T3 T4 T5

MPEG2 (wg_cs_1.mpg)
ADPCM FFT FFT (gaussian distribution)

26300
9300 15900 13600

2100
3300 0 800

Task Set
 We used three tasksets based on the applications
described earlier as shown in the table below:
Taskset Characteristics
T1 = (26300, 40000, 40000) T3 = ( 9300, 80000, 80000) T4 = (15900, 120000, 120000) T2 = (30700, 47000, 47000) T3 = ( 9300, 94000, 94000) T4 = (15900, 141000, 141000) T1 = (30700, 45000, 45000) T3 = ( 9300, 90000, 90000) T5 = (13600, 135000, 135000)

Static Factors
0.9495

A
B C

0.8979

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
Normal Only Shutdown Shut./Static Shut./Static/Dyn. Shut./Static/Dyn./Adapt. (0.95) Shut./Static/Dyn./Adapt. (0.90) Shut./Static/Dyn./Adapt. (0.85) Shut./Static/Dyn./Adapt. (0.80) Shut./Static/Dyn./Adapt. (0.75)

Energy Power Ratio
39.085 31.504 32.024 28.496 26.581 26.258 25.251 24.835 24.330 0.779 0.628 0.638 0.568 0.527 0.522 0.502 0.494 0.483 1 0.80 0.81 0.72 0.68 0.67 0.64 0.63 0.62

Deadlines missed
0/0/0 0/0/0 0/0/0 1/1/2 3/2/1 3/2/1 3/1/4 3/2/51 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
Normal Only Shutdown Shut./Static Shut./Static/Dyn. Shut./Static/Dyn./Adapt. (0.95) Shut./Static/Dyn./Adapt. (0.90) Shut./Static/Dyn./Adapt. (0.85) Shut./Static/Dyn./Adapt. (0.80) Shut./Static/Dyn./Adapt. (0.75)

Energy Power Ratio
12.546 11.265 9.819 9.811 9.795 8.815 8.828 8.185 8.211 0.798 0.716 0.624 0.624 0.623 0.562 0.562 0.522 0.525 1 0.89 0.78 0.78 0.78 0.70 0.70 0.65 0.65

Deadlines missed
0/0/0 0/0/0 1/0/1 1/0/1 1/0/1 1/1/31 1/1/31 34/10/34 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
Normal

Energy Power Ratio
13.080 0.838 1

Deadlines missed
0/0/0

Only Shutdown
Shut./Static Shut./Static/Dyn. Shut./Static/Dyn./Adapt. (0.95) Shut./Static/Dyn./Adapt. (0.90) Shut./Static/Dyn./Adapt. (0.85) Shut./Static/Dyn./Adapt. (0.80) Shut./Static/Dyn./Adapt. (0.75)

12.342
12.391 10.892 10.958 9.875 9.990 9.889 9.789

0.772
0.789 0.693 0.697 0.627 0.637 0.631 0.624

0.94
0.94 0.83 0.83 0.75 0.76 0.75 0.74

0/0/0
0/0/0 0/1/18 0/1/18 1/8/32 11/16/32 11/16/32 11/16/32

Ratio of energy consumption between Normal and Scheme
0.2 1 0.4 0.6 0.8 1.2 0

Normal

Only Shutdown

Shut./Static

Shut./Static/Dyn.
Scheme

Shut./Static/Dyn./Adap t. (0.95) Shut./Static/Dyn./Adap t. (0.90) Shut./Static/Dyn./Adap t. (0.85) Shut./Static/Dyn./Adap t. (0.80) Shut./Static/Dyn./Adap t. (0.75)

OS-directed DVS Results
Energy Consumption for each scheme

Taskset B

Taskset A

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

Applications

OS Dependent Application APIs OSPM System Code OS Specific technologies, interfaces, and code.

Kernel

Device Driver

ACPI Driver/ AML Interpreter

ACPI Register Interface

ACPI Table Interface ACPI BIOS Interface

OS Independent technologies, interfaces, code, and hardware.

Existing industry standard register interfaces to: CMOS, PIC, PITs, ...

ACPI Registers

ACPI BIOS

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

Power Failure

G3 -M e ch Off

Modem HDD CDROM D3 D3 D3 D2 D2 D2 D1 D1 D1 D0 D0 D0 C0

BIOS Routine

Le gacy

G0 (S0) Working
Wake Ev ent

S4 S3 S2 S1

G1 Sle e ping

Performance State Px

T hrottling

C0 C1

G2 (S5) Soft Off

C2 CPU Cn

ACPI Processor Power States
Latency
C1 < C2 < C3
Full Speed
THT_EN=1 and DTY=value

Power Throttling

C0

Throttling

THT_EN=0 HLT Interrupt P_LVL2 Interrupt Interrupt or BM Access P_LVL3, ARB_DIS=1

C1

C2

C3

Power C1 > C2 > C3

G0 Working

Overview of ACPI System States
State
G0
Working

CPU
C0: Executing @ Full Speed C1:C3 Executing in PM state (ie Thermal Throttle/HLT) Not Executing Context Retained CPU CLK: OFF System CLK: ON Power: ON Not Executing CPU/Sys Cache Context Lost CPU CLK: OFF System CLK: OFF Power: ON Not Executing CPU/Cache Context Lost CPU CLK: OFF System CLK: OFF Power: OFF Not Executing CPU/Cache Context Lost Everything: OFF OFF

Memory
Retained Power: ON Refresh: Normal

Devices
Powered Up & Down based on demand D0-D3

Wake Up

Context Tracking

S1
Sleeping

Retained Power : ON Refresh : Normal

Devices Power down depending on wakeup & power requirements

Lowest Latency Restart @ CS:IP +1

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

S2
Sleeping

Retained Power : ON Refresh : Standby / Auto

Devices Power down depending on wakeup & power requirements

Latency > S1 Restart @ Boot Vector

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 OS(S4) / BIOS(S4bios) is responsible for saving and restoring all system context, including memory OS uses S5 to turn the machine off

S3
Sleeping

Retained Power : ON Refresh : Standby / Auto Context Lost Power : OFF Refresh : N/A OFF

Devices Power down depending on wakeup & power requirements

Latency > S2 Restart @ Boot Vector

S4
S4BIOS Sleeping

Devices Power down depending on wakeup & power requirements Devices are OFF, Power Button Press will wake up the system

Latency > S3 Restart @ Boot Vector Latency > S4 Restart @ Boot Vector

G2/S5
Soft OFF

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.
ACPI tables describe devices, their power states, the power planes the devices are connected to, and controls for putting devices into different power states. While the OS is idle but not sleeping, it will use commands described by ACPI to put processors in low-power states. DPM to achieve desirable balance between performance and

 Device Power Management


 Processor power management


 Device and processor performance management


ACPI functionalities (cont.)
 Plug and Play


hierarchically arranged device and configuration information
a general event mechanism for system events such as thermal events, power management events, docking, device insertion and removal, and so on either through a Smart Battery subsystem interface controlled by the OS directly through the embedded controller interface, or a Control Method Battery interface.

 System Events


 Battery management


 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


				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:54
posted:8/10/2009
language:English
pages:53