Cross-Layer Frameworks for Constrained Power and Resources Management of Embedded Systems Final PhD Dissertation of: Patrick Bellasi Politecnico di Milano Dipartimento di Elettronica e Informazione Advisor: Prof. William Fornaciari Industrial tutor (STMicroelectronics): Ing. David Siorpaes March, 3 - 2010
80
Embed
Cross-Layer Frameworks for Constrained Power and Resources Management of Embedded Systems
Power and resource management are key goals for the success of modern battery-supplied multimedia devices. This kind of devices are usually based on SoCs with a wide range of subsystems, that compete in the usage of shared resources, and offer several power saving capabilities, but need an adequate software support to exploit such capabilities. This presentation introduces Constrained Power Management (CPM), a cross-layer formal model and framework for power and resource management, targeted to MPSoC-based devices. CPM allows coordination and communication, among applications and device drivers, to reduce energy consumption without compromising QoS. A dynamic and multi-objective optimization strategy is supported, which has been designed to have a negligible overhead on the development process and at run-time.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Cross-Layer Frameworks forConstrained Power and Resources Management
of Embedded Systems
Final PhD Dissertation of:
Patrick Bellasi
Politecnico di Milano
Dipartimento di Elettronica e Informazione
Advisor:Prof. William Fornaciari
Industrial tutor (STMicroelectronics):
Ing. David Siorpaes
March, 3 - 2010
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• Objective Function (−→og )◦ Optimization layer C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
• to identify a solution-equivalent and efficient optimization strategy◦ guide the design of an efficient implementation◦ exploit problem specificities
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
• 415 automatically identified FSC (≃70ms)◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
Motivation Proposal Results Conclusions
Dissemination
Achievements and Dissemination
• Main conference publications◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “Constrained Power Management:
Application to a Multimedia Mobile Platform”. DATE - Dresden, 03/2010.◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “A Hierarchical Distributed Control for
Power and Performances Optimization of Embedded Systems”. ARCS -Hannover, 02/2010. (Runner-up for Best Paper Award)
◦ P. Bellasi, S. Bosisio, M. Carnevali, W. Fornaciari, D. Siorpaes, “Cross-LayerConstrained Power Management: Application to Multimedia Mobile Platforms”.LASCAS - Iguacu Falls, 02/2010.
◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “Predictive Models for MultimediaApplications Power Consumption Based on Use-Case and OS Level Analysis”.DATE - Nice, 04/2009
• US patent pending (by STMicroelectronics)◦ “Power Management Using Constraints in Multi-Dimensional Parameter Space”
• Book Chapter◦ Run-time Resource Management at the Operating System level in
“Multi-objective design space exploration of multiprocessor SoC architectures: theMULTICUBE approach”, edited by Springer. (to be published)
• Collaboration on EU sponsored projects◦ Dynamic Power and Resource Management
2PARMA - 7FP (STREP) and COMPLEX - 7FP (IP)
Motivation Proposal Results Conclusions
Conclusions and Future Work
Lesson Learned
Hierarchical Power and Resource Management is foreseen as a validapproach to keep in pace with complexity of upcoming architectures
• Distributed approach for performances vs power trade-off control◦ automatic identification of feasible configurations◦ supports the constraint based power management model◦ scalable on upcoming more and more complex architectures◦ provides multi-objective optimizations◦ layered design to improved code reuse◦ exploits platform and devices fine-details
Motivation Proposal Results Conclusions
Conclusions and Future Work
Outlook
• The implementation is going to be released in ML for RFC◦ Push the constrained PM concept to the Linux community
• P.Bellasi, D. Siorpaes “Constrained Power Management”.ELC-E - Grenoble, 10/2009.
• L. De Marchi, P. Bellasi, W.Betz, “Multi-core Scheduling Optimizations forSoft Real-time Multi-threaded Applications – A Cooperation AwareApproach”. ELC - San Francisco, 04/2010.
• Improve the user-space interface◦ OS-level automatic application behaviors extraction◦ automate QoS requirement assertion (work in progress)
• Integrate more interesting real-world applicationse.g., Scalable Video Coding, Cognitive Radio, Multi-View Image Processing
• Integration with other resource manager
e.g., memory access, and tasks scheduling
• Investigate on HW acceleration opportunity
Thanks for your attention!
I am not to blame for putting forward, in the course of
my work on science, any general rule derived from a
previous conclusion.
Leonardo Da Vinci
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Application proac-tive
Being able to collect applications requirements to bet-ter support their processing expectations and to givefeed-back on effective resources availability.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Application proac-tive
Being able to collect applications requirements to bet-ter support their processing expectations and to givefeed-back on effective resources availability.
3 7
Linux Support
Provide a complete support at least for the Linux op-erating system by means of a well designed frameworkthat should be accepted by the community for mergingin mainline kernel
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Hierarchical
Power
Manager
5 5
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Hierarchical
Power
Manager
5 5
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
The global policy is used to
fine-tune the local ones
Approach CPM in a Nutshell Implementation
The Abstraction Layer
System-Wide Metric (SWM)
A parameter describing the behaviors of a running system and usedto track resources availability
• QoS requirements are expressed as validity ranges on SWMmainly upper/lower bounds
• Different abstraction levels◦ Abstract System-wide Metric (ASM), platform independent
exposed to user-lande.g. ambient light/noise, power source, specific application requirements
◦ Platform System-wide Metric (PSM), platform dependentprivate to platform code and platform driverse.g. bus bandwidth, devices’ latency
• Allow to track QoS inter-dependencies◦ platform code and drivers can translate ASM’s requirements into
PSM’s constraints
Code Example
Approach CPM in a Nutshell Implementation
The Abstraction Layer
Device Working Region (DWR)
The mapping of a deviceoperating mode on SWMs’ ranges
• A device could have differentworking modes◦ different QoS => different
SWM range
• Defined by the device driver
• Support tracking of devicesfunctional dependencies
µ21
µ24
µ25
µ26
µ23
µ22
µ12µ11 µ13 µ14
C32
C33
C31
m1
m2
A device with 3 DWR (cdm) mapping 2 SWM (mi )
Code Example
Approach CPM in a Nutshell Implementation
The Modelling Layer
Feasible System-wide Configurations (FSC)
The intersection of at least aDWR for each device
• identify all and only the feasiblesystem’s working modes◦ all devices can support the
required QoS level◦ no functional conflicts
• all the possible solutions for thePM optimization problem◦ abstract model for system-wide
optimizations
C12C11
C22
C21
C23
C32
C33
C31
m1
m2
FSC 3
FSC 2
FSC 1
The 3 FSCs existing on this system
Approach CPM in a Nutshell Implementation
The Optimization Layer
Linear Programming (LP) Formulation
• The PM optimization problem can be formulated as an LP problem
• LP elements:◦ solution space – SWMs Domain◦ objective function – vector representing QoS optimization directions◦ constraints – QoS requirements
• dynamically reduce the number of valid FSCs
◦ convex hall – the smallest convex polygon including all valid FSCs◦ valid solution – every point inside the convex hall◦ optimal solutions – vertexes or edges of the convex hall
• can always be mapped to 1 or 2 FSCs
Go to Motivations
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
m1
m2
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
m1
m2
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hull
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API