1. DPM (Dynamic Power Management)

2. Introduction Trend: Increase of power-aware processor design
Voltage scaling is supported in most processors for mobile applications
Dynamic power management is being implemented in most operating systems for embedded systems

3. Power Management Dynamic power management
  Allows selective shutdown of different blocks based on
activity
  Stops clock switching of a specific unit
  Can be implemented at high level (FUs) or at low level (a block inside an FU)
Static power management
 Activity of the entire system is monitored
 Entire chip or part of it is put into sleep mode

4. DPM : Power-Aware OS Process Management Mechanism
Various process states for power
Various operating points (ex. voltage, temperature)
Policy Management Schemes
Low power Device Control
ACPI (Advanced Configuration and Power Interface)
Shutdown Schemes
Adaptive, Predictive, Markov, by Learning, etc.
Power Management Overheads

5. DPM : Power-Aware OS OS Jobs Typical Power-Aware OS Approaches
Task scheduling
Interrupt handling
Memory management
File system
Device control
etc.
Typical Power-Aware OS Approaches
Operation/Power mode management (shutdown)
DVS (slowdown)
Low power intra-/inter-task scheduling

6. DPM : Power-Aware OS Windows APM and ACPI
Device centric, shutdown based
Power-aware Linux
Power-aware ECOS (Embedded Configurable OS)
MicroC/OS II : real-time kernel
-- An active research topic !!

7. DPM : Power-Aware Software Architecture
Application
PA-API
PA-Middleware
POSIX
PA-OSL OS
Modified OS
Services OS
Hardware Abstraction Layer
PA-HAL
Hardware

8. DPM
Systems are designed to deliver peak performance, but do not need peak performance most of time
DPM reduces power consumption by dynamically adjusting performance level
Low energy consumption is required
By portable systems, to extend operational time
By non-mobile systems, to reduce heat problems and environmental impacts
Power manager
Real-time resource monitoring and control
Power manager overhead is negligible

9. DPM Wide applicability of power management in different applications
Computers and portable communication devices
Different implementation styles
Circuit level: clock gating, frequency control, supply voltage variations, etc.
System level: hardware/software tradeoffs, OS

10. DPM Requirements
Goal is to reduce system-wide energy consumption in portable systems
Current generation of embedded devices are so power-hungry with processors, memories, and displays
Only being concerned with voltage/frequency scaling for processor core may be insufficient
ex. Scaling bus frequency can drive significant reductions in system-wide energy consumption
The requirements aggressively manage power consumption based on the states of peripheral devices

11. DPM Requirements
The most efficient way to manage energy consumptions are highly application-dependent
Application means a complete embedded system
A DPM architecture needs to be flexible enough to support multiple platforms w/different requirements
Leave the workings of DPM system to be transparent to most tasks for simplicity and flexibility
Be aware of the trends in SoC processors
High level of integration, symmetric/asymmetric multi-processing on a single chip and more flexible DPM schemes

12. When to apply DPM Use power management if
Average idle time is long enough
Shut-down delay is short enough
Shut-down power is low enough
Sleep power consumption is low enough
When designing a system for a known workload
Above conditions can be seen as design constraints

13. Concept of Power Management
System-level PM saves power of subsystems (also called devices)
ex. Shutting down hard disks and displays
Eg.
P = 400 mW
run
160 ms
10 us
90 us
10 us
90 us
idle
sleep
P = 50 mW
P = 0.16 mW

14. Concept of Power Management
Workload
Device
Power state
Request
Request
Busy
Idle
Busy
Work
Tsd
Sleep
Twu
Work
power t

15. Break-even Time Break-even time Tbe
Minimum length of idle period to save power
Move to sleep state if Tidle > Tbe
Ps ,Pw : power in sleep and working states
To, Eo : Transition (shutdown/wakeup) delay and energy
Pw * Tbe = Eo + Ps (Tbe - To)
=> Tbe = (Eo - Ps * To )/(Pw - Ps)
Tbe = max {(Eo - Ps * To )/(Pw - Ps), To }

16. Power and Performance Issues
Shutdown delays and wake-up delays
Changing power states has significant overhead
Waking up a sleeping device may take extra energy
The rules to determine whether to shut down a device are called policies

17. Shut-down Strategies Fixed Shutdown after predetermined time
Predictive
Shutdown as soon as idle if predicted idle period is greater than break-even time
Previous active period
Shutdown if active period is below a predefined time
Adaptive
Prediction is adapted during runtime
Stochastic

18. Shut-down Policies: Classification
DPM
Fixed Timeout
Adaptive
Device dependent
Predictive
L shape
Exponential average
Predictive wakeup
Predictive shutdown
Adaptive disk shutdown
Learning tree
OS directed
Task based
Task scheduling
Stochastic
Sliding window
Competitive

19. Shut-down Policies: Fixed Time-out
Static
Assume that if a device is idle for τ, it will remain idle for at least Tbe
If a device is idle for τ, change state to sleep
τ is computed and set off-line
Simple to implement. Requires a timer
Power is wasted in waiting for timeout
Timeout policies
ATO (Adaptive Timeout Policy)
Adjust τ by the ratio of τ and previous idle period
DDT (Device-Dependent Timeout Policy)
Select τ based on Tbe

20. Shut-down Policies: Predictive
Predictive shut-down [Golding 1996]
Decision based on the observations of past idle, busy times, take decision as an idle time starts
Tpredn = f(Tbusyn-1, …, Tbusyn-k , Tidlen-1, …, Tidlen-k )
The equation f yields a predicted idle time Tpred
Shut down if sampled data fit to a non-linear regression equation f (off-line)
Tpredn > Tbe
* Computation and memory requirements

21. Shut-down Policies: Predictive
L-Shape [Srivastava 1996]
Short busy periods are followed by long idle periods
Long busy periods are followed by short idle periods
Problem in the left corner, only short periods
Idle period (sec)
Tbe
Busy period (sec)

22. Shut-down Policies: Predictive
Learning Tree (LT)
Adaptive learning tree can control multiple sleeping states
A sequence of idle periods is transformed into a sequence of discrete events
All leaf nodes are predictions for the next idle periods and store the Prediction Confidence Level (PCL) a b c d 1 e 3 2 1 2 3

23. Shut-down Policies: Predictive
Exponential Average
Use both the predicted and the actual length αof a previous idle period to predict the next idle period
p(n+1) = α * I(n) + (1- α) * p(n)
The constant α has a value between 0 and 1

24. Shut-down Policies: Stochastic
Predictive and adaptive policies lack some properties
They are based on a two-state system model
Parameter tuning is difficult
Stochastic policies provide a more general and optimal strategies
Modeled by Markov chain
Stationary Discrete-time Markov process
The optimal probability for device to sleep obtained by solving the stochastic optimization problem
To generalize, extend it to other stochastic models

25. Shut-down Policies: Stochastic
0.05 1
0.15
0.85
0.95 on
off
S_on: 1.0
S_off: 0.8 S_
S_on: 0.9
S_off: 1.0
S_on: 0.0
S_off: 0.2
S_on: 0.1
S_off: 0.0

26. Shut-down Policies: Stochastic
Sliding window
w(0) w(1) w(2) ………. w(ws-2) w(ws-1)
Sliding window is based on the stochastic model
It is used for non-stationary service requests
The basic window operation is to shift one slot constantly every time slice
The shutdown decision is evaluated each period, thus causing overhead
Single or multiple window approach 1

27. Resource Requirements
Prediction accuracy and power savings are two major criteria in choosing appropriate policy for specific applications
Resource requirements are also important
Memory requirement
Runtime computation
Timer generation

28. IBM - Monta Vista DPM Architecture

29. DPM Architecture Overview
Policy architecture
Operating point (Vol., freq.)
Operating states
Device management
Policy manager
Coordinate the activation of different policies
Device constraint manager
Dynamic power manager
OS kernel
User/application space
user/application
space
policy
manager
OS kernel
DPM
policies

30. Policy Architecture (1)
A DPM policy is
A named data structure
Installed in the DPM implementation in the OS
Managed by policy manager that may be outside of the OS
A DPM system is initialized and activated, then the system will be always executing under a particular DPM policy
The structure of a DPM policy is a hierarchy of abstracted objects
Operating point
Operating states
Device management and operating point congruence classes
Policies and policy manager

31. Policy Architecture (2)
Operating points
Is the lowest-level object in the DPM system hierarchy
Encapsulates the minimal set of inter-dependent, physical and discrete parameters that defines a specific system performance level along with an associated energy cost
Inter-dependency : relation between voltage and frequency of a processor core
Discrete parameters : SDRAM timing parameters
At any given time, a system is said to be executing at a particular operating point

32. Policy Architecture (3)
* 3 abbreviated operating point descriptions for IBM PowerPC 405LP
Operating points
“33/33”
“200/100”
“266/133”
Core voltage
1.0 V
1.5 V
1.8 V
PLL-VCO frequency
800 MHz
533 MHz
CPU frequency
(VCO:CPU)
33 MHz (24:1)
200 MHz (4:1)
266 MHz (2:1)
PLB frequency
(CPU:PLB)
33 MHz (1:1)
100 MHz (2:1)
133 MHz (2:1)
EBC frequency
(PLB:EBC)
33 MHz (3:1)
33 MHz (4:1)
SDRAM timing
CAS 2
CAS 3

33. Policy Architecture (4)
Operating state
for a given system supporting multiple operating points, some rules and mechanism are required to move from one point to another
Active/idle/interrupt
Interrupt received
interrupted
idle
Interrupt handling
System is idle
Task+
Task-
Task
scheduling

34. Policy Architecture (5)
Significant system-wide energy saving can be achieved by reducing processor and bus frequencies, and core voltage while the system is idle
A different operating point should be selected in each active and idle state
The DPM in OS helps a smooth and efficient transition between them
Operating state provides task-specific operating points for power-aware tasks
This requires multiple task-specific active states or task states
Operating states appear in the DPM policy architecture
A DPM policy simply associates an operating point with each of the system operating states
Changing to a new DPM policy simply changes the association

35. Policy Architecture (6)
Policies and Policy manager
The highest-level abstraction of the DPM architecture is the policy, which maps each operating state to congruence class of operating points
A class of operating points is assigned to a system
DPM architecture does not require the presence of any operating states other than a single task state common to all platforms
If multiple policies are needed, then a policy manager must exist in the system to coordinate the activation of different policies

36. Device Constraints Management (1)
The automatic selection of operating points as devices change state is central feature of DPM
Embedded systems may not have a BIOS, so OS and device drivers have to do this task
The most aggressive management strategies will also require the system designer to carefully consider the influence of attached devices on the strategy

37. Device Constraints Management (2)
Example on reference designs for the IBM PowerPC 405LP
A VGA LCD panel
Receives a variable-speed pixel clock generated by on-chip clock dividers
Pixel clock frequency determines the LCD refresh rate and processor local bus bandwidth to SDRAM frame buffer required to service LCD
An external security chip for secure key management function requires the 405LP to source a precise 33 MHz clock via an external clock port

38. Device Constraints Management (3)
A simplified example policy
The operating point classes for 2 operating states, task and idle
An operating point is described by (core voltage, CPU, PLB, pixel clock, external clock frequency)
Each circle represents an operating point within the boundaries of congruence of classes of operating points for the task and idle states
V: 1.8
CPU: 266
PLB: 133
PXL: 4
EXT: 0
PXL: 22
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 33
CPU: 8
PLB: 8
PXL: 0
task
idle

39. Device Constraints Management (4)
A simplified example policy
High performance policy : 1.8V, 266MHz operating point for the task state
Lower voltage and frequency operating points for the idle state
Three operating points are specified for each of two states
The leftmost operating point of each set is the lowest-energy state in the pixel clock and the external clock are disabled
V: 1.8
CPU: 266
PLB: 133
PXL: 4
EXT: 0
PXL: 22
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 33
CPU: 8
PLB: 8
PXL: 0
task
idle

40. Device Constraints Management (5)
The ‘normal’ operation of application, where LCD controller is active but the security chip is offline
When LCD controller is enabled, the DPM will invalidate the indicated operating points
The next operating points in each class are valid, so this is a valid policy
The idle state provides adequate performance for static images
V: 1.8
CPU: 266
PLB: 133
PXL: 4
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 33
V: 1.0
CPU: 8
PLB: 8
PXL: 0
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 33
task
idle

41. Device Constraints Management (6)
The state of the policy while LCD is active and the security chip is performing
The operating point that enables the external clock port at 33 MHz is left
As soon as the security chip device driver determines that the security chip can be taken offline, this will be communicated to the power management system and the policy will revert to the previous one
V: 1.8
CPU: 266
PLB: 133
PXL: 4
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 33
V: 1.0
CPU: 8
PLB: 8
PXL: 0
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 33
task
idle

42. Device Constraints Management (7)
The state of the policy when both devices are disabled
In this situation the lowest-energy operating point from each class is selected
LCD is disabled, PLB and memory bandwidth demand is very limited
The idle state needs extremely low energy that takes the system out of idle state and return to the task state
V: 1.8
CPU: 266
PLB: 133
PXL: 4
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 0
V: 1.8
CPU: 266
PLB: 133
PXL: 22
EXT: 33
V: 1.0
CPU: 8
PLB: 8
PXL: 0
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 0
V: 1.0
CPU: 33
PLB: 33
PXL: 17
EXT: 33
task
idle

43. Example Strategies (1) A simple one-policy task task- task+ Idle
1.8 V
1.0 V
1.0 V

44. Example Strategies (2) Another complete yet simple task+ task- Idle
1.8 V
1.0 V
1.0 V
1.0 V
1.5 V

45. Example Strategies (3) Simple dynamic scaling
A simple activity-based power manager for a dynamic voltage and frequency scalable system
Task-state specific dynamic scaling (simple a simple video decoder)
policy
Task[+/-]
Idle
Idle-Task
Low(1.0V)
100/
Medium(1.5V)
High(1.8V)
Policy
Task+
Task
Task-
Idle-Task
Idle
Battery Critical
Battery Low
Battery Good

46. ACPI
Advanced Configuration and Power Interface (by Intel, Microsoft, Toshiba)
An interface specification
Allows OS-directed power management (OSPM)
Defines
Hardware registers – implemented in chipset silicon
BIOS interfaces
Configuration tables
Interpreted executable function interface (control method)
System and device power states
ACPI thermal model

47. ACPI interfaces Applications OS dependent Application APIs Kernel
OS specific technology
ACPI spec covers this area
Kernel
OSPM system code
Provided by ACPI CA
Hardware platform
OS specific technologies,
Interfaces, and code
Device
driver
ACPI driver
AML interpreter
interfaces
OS independent
technologies,
interfaces,
codes, and hardware
Existing industry
standard register
interfaces
ACPI registers
ACPI BIOS
ACPI tables
Platform hardware
BIOS

48. Vertigo: Linux Performance Setting
LongRun
Adjust clock rate based on past processor utilization
Power management policy Implemented in processor firmware
Vertigo
Implemented as a set of kernel modules
Hook into the Linux kernel to monitor program execution
Control the speed and voltage level of processor

49. Linux performance setting
Power-aware processors
Most mobile processors support voltage scaling
Lack of performance-setting policies at OS level
Performance-setting algorithms
Derive deadline based on past processor utilization and event classification
Utilize task deadlines in real-time kernels

50. Performance-setting algorithms
Algorithm decision hierarchy
At the top
An algorithm qualifying the performance requirement of interactive application
In the middle
DVS-aware application can submit information about their performance requirement
At the bottom
An algorithm that attempts to estimate the future utilization of the processor based on past information
Focus is on the interactive algorithm at the top of the stack and perspective-based algorithm at the bottom

51. Performance-setting algorithms
Perspective-based algorithm
Processor derives required performance level
Calculates performance prediction from each task
Processor adjusts performance setting from acquired performance prediction

52. Performance-setting algorithms: Implementation issues
Policy (performance control) stack
Mechanism for supporting multiple independent performance-setting
Policy stack
Policy event handler
Level 2
Set-IFGT 80
Level 1
Ignore
Common events
on reset
on task switch
on perf change
Level 0
Set 25
command
perf

53. Vertigo Architecture Allows the composition of multiple algorithms
User processes
- Monitored through kernel hooks
System calls
Task switch/create/exit
- May specify application-specific hints
kernel
Performance policy modules
- Multiple policies
- Best chosen dynamically
System
calls
Scheduler
Conventional
power manager
(sleep/awake)
Vertigo module
- Coordinate policies
- Controls perf setting
- Event tracing
- Proc interface
hooks