power aware software architecture l.
Skip this Video
Loading SlideShow in 5 Seconds..
Power Aware Software Architecture PowerPoint Presentation
Download Presentation
Power Aware Software Architecture

Loading in 2 Seconds...

play fullscreen
1 / 53

Power Aware Software Architecture - PowerPoint PPT Presentation

  • Uploaded on

Power Aware Software Architecture Rajesh K. Gupta University of California, Irvine Instrumented wide-area spaces Internet end-points In-body, in-cell, in-vitro spaces Personal area spaces The “Noveau Rich” in Computing Generational shift in computing devices

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Power Aware Software Architecture' - daniel_millan

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
power aware software architecture

Power Aware Software Architecture

Rajesh K. Gupta

University of California, Irvine

the noveau rich in computing


wide-area spaces

Internet end-points

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

Personal area spaces

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
  • 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
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”
power management places
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
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
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
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
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
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
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
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
Lower Envelope Idea




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

State 4






For each state i, plot:

experimental study ibm mobile hard drive


Power Consumption

Start-up Energy (Joules)

Transition Time to Active

















Experimental Study: IBM Mobile Hard Drive

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

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








Modified OS Services




Hardware Abstraction Layer


A Power-Aware Software Architecture
power aware software architecture20
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
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.
dvs related functions
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


set the paremeters of the adaptive policy (it will be described later) for a given task.


choses the policy to be using for DVS

dvs related functions contd
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


kills a thread that missed a deadline


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

80200EVB w/ voltage scaling board and

the host system

Compaq IPAQ

running eCos

Maxim board for voltage scaling

using power aware os example
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()


mpeg_decoding_t =


paapi_dvs_set_policy(SHUTDOWN | STATIC



mpeg_decoding_t, mpeg_decode_thread);






void mpeg_decode_thread()


for (;;) {


/* original code */





Selects the DVS policy for all threads

Kills the thread instance when

deadline is missed

an experiment
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
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
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
Application Set
  • Three different real applications running concurrently:
    • AnMPEG2 decoder
    • AnADPCM (Adaptive Differential Pulse Code Modulation) speech enconding
    • Floating pointFFT application
task set
Task Set
  • We used three tasksets based on the applications described earlier as shown in the table below:
frequency voltage scaling
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:
results taskset a
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%
results taskset b
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
results taskset c
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
using application level knob
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 batterylife is extended by18% with a slight (= “not noticeable by human eye”) degradation of image quality

concluding remarks
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

Yes, but Microsoft...

… and others have already solved the problem?

operating system power management ospm
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
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 processor power states
ACPI Processor Power States

Power Throttling


C1 < C2 < C3


C1 > C2 > C3

overview of acpi system states
Overview of ACPI System States





Wake Up

Context Tracking


C0: Executing @ Full Speed

C1:C3 Executing in PM state

(ie Thermal Throttle/HLT)

Powered Up & Down

based on demand



Power: ON

Refresh: Normal


Not Executing

Context Retained


System CLK: ON

Power: ON


H/W responsible for saving

context of CPU, System I/O,

& Memory

Devices Power down

depending on wakeup &

power requirements

Lowest Latency

Restart @ CS:IP +1


Power : ON

Refresh : Normal


Not Executing

CPU/Sys Cache Context Lost


System CLK: OFF

Power: ON


Power : ON

Refresh : Standby /



Devices Power down

depending on wakeup &

power requirements

H/W responsible for saving

context of System I/O & Memory

OS responsible for saving CPU


Latency > S1

Restart @ Boot Vector



Not Executing

CPU/Cache Context Lost


System CLK: OFF

Power: OFF

H/W responsible for saving

Memory context BIOS restores

Memory Controller

Context. OS responsible for saving

CPU & System I./O context

Devices Power down

depending on wakeup &

power requirements

Latency > S2

Restart @ Boot Vector


Power : ON

Refresh : Standby /




Not Executing

CPU/Cache Context Lost

Everything: OFF

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

Context Lost

Power : OFF

Refresh : N/A





Devices are OFF,

Power Button Press will

wake up the system

Latency > S4

Restart @ Boot Vector

OS uses S5 to turn the machine off


Soft OFF


- 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
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
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
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
OnNow Components

Ref.: Microsoft’s “OnNow Power Management Architecture for Applications”

onnow architecture
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