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.
What Are The Drone Anti-jamming Systems Technology?
Cross-Layer Frameworks for Constrained Power and Resources Management of Embedded Systems
1. 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
2. Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
Multi−core Host Processor
General Purpose (CortexA9)
• Focus on modern MPSoC architectures Core Host Core
#1
Core
#2
Core
#3
Core
#4
Asymmetric Processing
◦ implicit architectural inter-dependencies HW
Block
HW
Block
◦ resource sharing and competition HW
Block
HW
Block
• many resources impact on performances HW
Block
e.g., clocks, memories, communication channels HW HW HW
Block Block Block
• energy is the most precious resource Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
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
3. Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
Multi−core Host Processor
General Purpose (CortexA9)
• Focus on modern MPSoC architectures Core Host Core
#1
Core
#2
Core
#3
Core
#4
Asymmetric Processing
◦ implicit architectural inter-dependencies HW
Block
HW
Block
◦ resource sharing and competition HW
Block
HW
Block
• many resources impact on performances HW
Block
e.g., clocks, memories, communication channels HW HW HW
Block Block Block
• energy is the most precious resource Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
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
4. Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
Multi−core Host Processor
General Purpose (CortexA9)
• Focus on modern MPSoC architectures Core Host Core
#1
Core
#2
Core
#3
Core
#4
Asymmetric Processing
◦ implicit architectural inter-dependencies HW
Block
HW
Block
◦ resource sharing and competition HW
Block
HW
Block
• many resources impact on performances HW
Block
e.g., clocks, memories, communication channels HW HW HW
Block Block Block
• energy is the most precious resource Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
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
5. Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
Multi−core Host Processor
General Purpose (CortexA9)
• Focus on modern MPSoC architectures Core Host Core
#1
Core
#2
Core
#3
Core
#4
Asymmetric Processing
◦ implicit architectural inter-dependencies HW
Block
HW
Block
◦ resource sharing and competition HW
Block
HW
Block
• many resources impact on performances HW
Block
e.g., clocks, memories, communication channels HW HW HW
Block Block Block
• energy is the most precious resource Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Find the optimal trade-off between power General Purpose
Multi−core Host Processor
(CortexA9)
Core Host
consumption and perceived performance
Core Core Core Core
#1 #2 #3 #4
Symmetric Computation Fabric
• hardware support is not enough
◦ simple software support is required
• consider upcoming many-core architectures
Peripherials’ Interfaces and Memory
High Density
Programmable Fabric
6. Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model distributed control: multiple local policies
“configuration space explosion” “risk of conflicting decisions”
7. Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model distributed control: multiple local policies
“configuration space explosion” “risk of conflicting decisions”
The change on a single sub-system
requires a complete policy redesign
8. Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model distributed control: multiple local policies
“configuration space explosion” “risk of conflicting decisions”
The change on a single sub-system
requires a complete policy redesign
Cannot handle the complexity of new
generation platforms
9. Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model distributed control: multiple local policies
“configuration space explosion” “risk of conflicting decisions”
The change on a single sub-system The composition of independent
requires a complete policy redesign optimization policies cannot grant a
system-wide optimization
Cannot handle the complexity of new
generation platforms
10. Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model distributed control: multiple local policies
“configuration space explosion” “risk of conflicting decisions”
The change on a single sub-system The composition of independent
requires a complete policy redesign optimization policies cannot grant a
system-wide optimization
Cannot handle the complexity of new Cannot achieve system-wide optimization
generation platforms
11. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization
◦ global multi-objective optimization
strategy
◦ considering QoS requirements
• Modeling Abstraction
◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
12. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization
◦ global multi-objective optimization
strategy
◦ considering QoS requirements
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide DWR
ASM
feasible configurations (FSCs) PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
13. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization
◦ global multi-objective optimization Model
strategy Layer
◦ considering QoS requirements FSC
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide DWR
ASM
feasible configurations (FSCs) PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
14. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization
◦ global multi-objective optimization Optimization Model
strategy Layer Layer
QoS
◦ considering QoS requirements Requirements Global Optimization
policies
FSC
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide DWR
ASM
feasible configurations (FSCs) PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
15. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies Resource
Tasks
Manager
• Model optimization
Operating System
◦ global multi-objective optimization Optimization Model
strategy Layer Layer
QoS
◦ considering QoS requirements Requirements Global Optimization
policies
FSC
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide DWR
ASM
feasible configurations (FSCs) PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
16. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies Resource
Tasks
Manager
• Model optimization
Operating System
◦ global multi-objective optimization Optimization Model
strategy Layer Layer
QoS
◦ considering QoS requirements Requirements Global Optimization
policies
FSC
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide System−Wide DWR
ASM
feasible configurations (FSCs) Constraints
PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
17. Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies Resource
Tasks
Manager
• Model optimization
Operating System
◦ global multi-objective optimization Optimization Model
strategy Layer Layer
QoS
◦ considering QoS requirements Requirements Global Optimization
policies
FSC
• Modeling Abstraction Abstraction
Layer
◦ identification of system-wide System−Wide DWR
ASM
feasible configurations (FSCs) Constraints
PSM
• Abstracting reality
◦ portability and fine-details Local Optimization
policies
Drivers Platform Code
◦ represent resources (PSM/ASM)
HW Platform Silicon and Architectural
and working modes (DWR) mechanisms
Devices
• Devices local control
Hierarchical Distributed Control
18. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )
◦ Resources availability
◦ Abstraction layer (SWM)
• Constraints (vi )
◦ QoS requirements
◦ Model layer (DWR ⇒ FSC)
• Objective Function (− )
→
og
◦ Optimization layer
19. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )
◦ Resources availability
◦ Abstraction layer (SWM)
• Constraints (vi )
◦ QoS requirements
◦ Model layer (DWR ⇒ FSC)
• Objective Function (− )
→
og
◦ Optimization layer
20. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi ) m2
C 23
◦ Resources availability FSC3 C 33
◦ Abstraction layer (SWM)
C 31 FSC1
• Constraints (vi ) C 22
◦ QoS requirements
C 32 FSC2
◦ Model layer (DWR ⇒ FSC)
• Objective Function (− )
→
og C 21
◦ Optimization layer C 11 C 12
m1
21. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi ) m2 v1
C 23
◦ Resources availability FSC3 C 33
◦ Abstraction layer (SWM) µ2M v2
C 31 FSC1
• Constraints (vi ) C 22
Convex−Hull
◦ QoS requirements
C 32 FSC2
◦ Model layer (DWR ⇒ FSC)
• Objective Function (− )
→
og C 21
v3
◦ Optimization layer C 11 C 12
µ1c µ1M m1
22. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi ) m2 v1
O’ C 23
◦ Resources availability FSC3 C 33
◦ Abstraction layer (SWM) µ2M v2
C 31 O FSC1
• Constraints (vi ) C 22 og
Convex−Hull
◦ QoS requirements
C 32 FSC2
◦ Model layer (DWR ⇒ FSC)
o2
• Objective Function (− )
→
og C 21
o1 v3
◦ Optimization layer C 11 C 12
µ1c µ1M m1
23. Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)
◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi ) m2 v1
O’ C 23
◦ Resources availability FSC3 C 33
◦ Abstraction layer (SWM) µ2M v2
C 31 O FSC1
• Constraints (vi ) C 22 og
Convex−Hull
◦ QoS requirements
C 32 FSC2
◦ Model layer (DWR ⇒ FSC)
o2
• Objective Function (− )
→
og C 21
o1 v3
◦ Optimization layer C 11 C 12
µ1c µ1M m1
• to identify a solution-equivalent and efficient optimization strategy
◦ guide the design of an efficient implementation
◦ exploit problem specificities
24. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
25. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
26. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
27. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
28. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
29. Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficient
implementation
• Exploit three different time domains
◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy update
i.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirement
i.e., application functionality change
• Support complexity partitioning
◦ high-overhead operations are executed less frequently
• Modular design
◦ split operations between different modules
◦ better support optimization of each operation
• off-line computation (FI)
• HW acceleration, e.g. look-up based implementation (FO, FS)
30. Motivation Proposal Results Conclusions
Overheads Analysis (Worst-Case)
Overheads analysis
Low run-time overhead is the key for actual use
• FSC Identification • FSC Selection
◦ Upper-bound O(DWR D ) ◦ Lower-bound O(FI )
Optimal Boot-Time requirements
~10ms => +1% overhead
~300 FSC
• could be “constant” • undefined relative overhead
◦ off-line identification ◦ f(user-space)
• ACET ≪ WCET • could be HW accelerated
31. Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation
◦ Using a Nomadik board based on the STn8815 SoC
◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload
◦ Two concurrent application: Youtube streamer and Torrent client
◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)
◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
32. Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation
◦ Using a Nomadik board based on the STn8815 SoC
◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload
◦ Two concurrent application: Youtube streamer and Torrent client
◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)
◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
33. Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation
◦ Using a Nomadik board based on the STn8815 SoC
◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload
◦ Two concurrent application: Youtube streamer and Torrent client
◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)
◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
34. 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-Layer
Constrained Power Management: Application to Multimedia Mobile Platforms”.
LASCAS - Iguacu Falls, 02/2010.
◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “Predictive Models for Multimedia
Applications 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: the
MULTICUBE approach”, edited by Springer. (to be published)
• Collaboration on EU sponsored projects
◦ Dynamic Power and Resource Management
2PARMA - 7FP (STREP) and COMPLEX - 7FP (IP)
35. Motivation Proposal Results Conclusions
Conclusions and Future Work
Lesson Learned
Hierarchical Power and Resource Management is foreseen as a valid
approach 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
36. 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 for
Soft Real-time Multi-threaded Applications – A Cooperation Aware
Approach”. 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 applications
e.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
37. 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
38. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
39. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
40. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
Exploit all the low-level knowledge about each device
Fine-details in order to improve the fine tuning capabilities of the
control policy.
41. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
Exploit all the low-level knowledge about each device
Fine-details in order to improve the fine tuning capabilities of the
control policy.
Exploit the global view on: system resources availabil-
ity, power-vs-performances trade-off of each device and
System-wide
all the applications requirements in order to achieve a
system-wide optimal configuration.
42. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
Exploit all the low-level knowledge about each device
Fine-details in order to improve the fine tuning capabilities of the
control policy.
Exploit the global view on: system resources availabil-
ity, power-vs-performances trade-off of each device and
System-wide
all the applications requirements in order to achieve a
system-wide optimal configuration.
Tune the control policy to changing usage scenarios in
Time adaptability
order to better track user expected performance.
43. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
Exploit all the low-level knowledge about each device
Fine-details in order to improve the fine tuning capabilities of the
control policy.
Exploit the global view on: system resources availabil-
ity, power-vs-performances trade-off of each device and
System-wide
all the applications requirements in order to achieve a
system-wide optimal configuration.
Tune the control policy to changing usage scenarios in
Time adaptability
order to better track user expected performance.
Application proac- Being able to collect applications requirements to bet-
ter support their processing expectations and to give
tive feed-back on effective resources availability.
44. Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Smoothly apply to more and more complex architec-
tures such as the up-coming many-core based systems,
Scalability
without impacting too much on design and run-time
complexity.
Smoothly adapt to local changes on devices of the sys-
Portability tem without requiring a complete redesign of the con-
trol solution.
Exploit all the low-level knowledge about each device
Fine-details in order to improve the fine tuning capabilities of the
control policy.
Exploit the global view on: system resources availabil-
ity, power-vs-performances trade-off of each device and
System-wide
all the applications requirements in order to achieve a
system-wide optimal configuration.
Tune the control policy to changing usage scenarios in
Time adaptability
order to better track user expected performance.
Application proac- Being able to collect applications requirements to bet-
ter support their processing expectations and to give
tive feed-back on effective resources availability.
Provide a complete support at least for the Linux op-
erating system by means of a well designed framework
Linux Support DPM QoSPM
that should be accepted by the community for merging
in mainline kernel
45. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
46. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
47. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel
framework
Drivers
define working modes
and
available resources
48. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel
framework
System−Wide
optimization policy
Drivers
define working modes
and
available resources
49. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
System−Wide
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
50. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
System−Wide
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
Fundamental approach:
51. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
System−Wide
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
Fundamental approach:
FSC
identification
52. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
System−Wide
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
Fundamental approach:
FSC FSC
identification ordering
53. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
System−Wide
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
Fundamental approach:
FSC FSC FSC
identification ordering selection
54. Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Context:
System’s complexity Major opportunity Multifunction Control cannot Easily adapt
increase due to advent
of multi−threaded
of optimizations
are related to
devices with
frequently changing
impact on
system
to different
evolving
• Motivations
applications HW capabilities use−case performances architectures
Requirements:
• Approach
• Implementation
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Decisions:
In−Kernel Hierarchical
framework control
divide
System−Wide and conquere
optimization policy
Drivers
define working modes
and Applications assert
available resources QoS requirements
Fundamental approach:
FSC FSC FSC
identification ordering selection
55. 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
56. 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 Device
Local
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
5. Constraint assertion
◦ QoS requirements
◦ set constraint on local policies
57. 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 2
◦ track resource availability and Framework
devices interdependencies Device
Local
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
5. Constraint assertion
◦ QoS requirements
◦ set constraint on local policies
58. Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies Execution
Applications
Context
◦ targeted to power reduction
◦ fine-details, low-overhead Libraries Buses
2. Coordination entity QoS Requirements 3
◦ exploit system-wide view 2
◦ track resource availability and Framework
devices interdependencies Device
Local
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
5. Constraint assertion
◦ QoS requirements
◦ set constraint on local policies
59. Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies Execution
Applications
Context
◦ targeted to power reduction
◦ fine-details, low-overhead Libraries Buses
2. Coordination entity QoS Requirements 3
global
◦ exploit system-wide view 2 policy
4
◦ track resource availability and Framework
devices interdependencies Device
Local
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
5. Constraint assertion
◦ QoS requirements
◦ set constraint on local policies
60. Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies Execution
Applications
Context
◦ targeted to power reduction
◦ fine-details, low-overhead Libraries Buses
2. Coordination entity Hierarchical
QoS Requirements 3
Power global
◦ exploit system-wide view Manager 2 policy
4
◦ track resource availability and Framework
devices interdependencies Device
5
Local 5
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
5. Constraint assertion
◦ QoS requirements
◦ set constraint on local policies
61. Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies Execution
Applications
Context
◦ targeted to power reduction
◦ fine-details, low-overhead Libraries Buses
2. Coordination entity Hierarchical
QoS Requirements 3
Power global
◦ exploit system-wide view Manager 2 policy
4
◦ track resource availability and Framework
devices interdependencies Device
5
Local 5
local 1 1 local
3. User-space interface Control
policy policy
Driver Driver
◦ collects QoS requirements
◦ feedback on resource availability Platform Code
Device Device
4. Global optimization policy
◦ multi-objective, low frequency
The global policy is used to
5. Constraint assertion fine-tune the local ones
◦ QoS requirements
◦ set constraint on local policies
62. Approach CPM in a Nutshell Implementation
The Abstraction Layer
System-Wide Metric (SWM)
A parameter describing the behaviors of a running system and used
to track resources availability
• QoS requirements are expressed as validity ranges on SWM
mainly upper/lower bounds
• Different abstraction levels
◦ Abstract System-wide Metric (ASM), platform independent
exposed to user-land
e.g. ambient light/noise, power source, specific application requirements
◦ Platform System-wide Metric (PSM), platform dependent
private to platform code and platform drivers
e.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
63. Approach CPM in a Nutshell Implementation
The Abstraction Layer
Device Working Region (DWR)
The mapping of a device m2
operating mode on SWMs’ ranges µ26
C 33
• A device could have different µ25
µ24
working modes C 31
µ23
◦ different QoS = different
µ22
SWM range
C 32
• Defined by the device driver µ21
• Support tracking of devices
functional dependencies
µ11 µ12 µ13 µ14
m1
A device with 3 DWR (cdm ) mapping 2 SWM (mi )
Code Example