cross-layer frameworks for constrained power and resources management of embedded systems

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


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


Application Oriented Cores

Specialized Hardware

Multi−core Host Processor(CortexA9)

Core#1

Core#2

Core#3

Core#4

General Purpose

Core Host

Asymmetric Processing


Symmetric Computation Fabric

High Density

Programmable Fabric

Core#1

Core#2

Core#3

Core#4

Multi−core Host Processor(CortexA9)General Purpose

Core Host


Previous Approaches to Power Management

Centralized vs Distributed Control Models

centralized control: complex global model

“configuration space explosion”

distributed control: multiple local policies

“risk of conflicting decisions”






The change on a single sub-system

requires a complete policy redesign










Cannot handle the complexity of new

generation platforms














The composition of independent

optimization policies cannot grant a

system-wide optimization












The composition of independent

optimization policies cannot grant a

system-wide optimization

Cannot achieve system-wide optimization


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◦ represent resources (PSM/ASM)

and working modes (DWR)

• Devices local control

HW Platform

Local Optimization

policies

Silicon and Architectural

mechanisms

Devices

DriversPlatform Code


CPM in a Nutshell










ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices



CPM in a Nutshell










FSC

LayerModel

ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices



CPM in a Nutshell










QoS

RequirementsGlobal Optimization

policies

OptimizationLayer

FSC

LayerModel

ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices



CPM in a Nutshell










Operating System

TasksResourceManager

QoS


policies

OptimizationLayer

FSC

LayerModel

ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices



CPM in a Nutshell










System−Wide

Constraints

Operating System


QoS


policies

OptimizationLayer

FSC

LayerModel

ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices



CPM in a Nutshell










System−Wide

Constraints

Operating System


QoS


policies

OptimizationLayer

FSC

LayerModel

ASM

PSM

LayerAbstraction

DWR

HW Platform

Local Optimization

policies


mechanisms

Devices


Hierarchical Distributed Control


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







• Objective Function (−→og )◦ Optimization layer C12C11

C21

C23

C22

C32

C33

C31

m1

m2

FSC2

FSC1

FSC3








C21

C23

C22

C32

C33

C31

µ1M

µ2M

µ1c

v1

v2

v3

m1

m2

Convex−Hull

FSC2

FSC1

FSC3








C21

C23

C22

C32

C33

C31

µ1M

µ2M

µ1c

v1

v2

v3

m1

m2

Convex−Hullog

o2

o1

O

O’

FSC2

FSC1

FSC3








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



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)

◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change

◦ constraint assertion => FSC Selection (FS) QoS requirementi.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)


Overheads Analysis (Worst-Case)

Overheads analysis

Low run-time overhead is the key for actual use

• FSC Identification◦ Upper-bound O(DWRD)

~300 FSC

~10ms => +1% overhead

Optimal Boot-Time requirements

• could be “constant”◦ off-line identification

• ACET ≪ WCET

• FSC Selection◦ Lower-bound O(FI )

• undefined relative overhead◦ f(user-space)

• could be HW accelerated


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)


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)


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


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


Requirements



Scalability


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


Requirements



Scalability


7 3


7 3

Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.

3 7


Requirements



Scalability


7 3


7 3


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


Requirements



Scalability


7 3


7 3


3 7

System-wide


3 7

Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.

7 3


Requirements



Scalability


7 3


7 3


3 7

System-wide


3 7


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


Requirements



Scalability


7 3


7 3


3 7

System-wide


3 7


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

DPM QoSPM


The proposed approach

Our Fundamental Approach

Requirements:

System−Wide Fine−Details Dynamic Low−Overhead Scalable

Context:

applications

of multi−threaded

increase due to advent

System’s complexity Major opportunity

of optimizations

are related to

HW capabilities use−case

frequently changing

devices with

Multifunction Control cannot

impact on

system

performances architectures

evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




In−Kernel

framework

Drivers

define working modes

and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




Fundamental approach:

Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




identification

FSC


Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




FSC

orderingidentification

FSC


Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




selection

FSCFSC


FSC


Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• Implementation




and conquere

divide

selection

FSCFSC


FSC


Applications assert

QoS requirements

control

Hierarchical

optimization policy

System−Wide

In−Kernel

framework

Drivers


and

available resources

Decisions:

Requirements:


Context:

applications

of multi−threaded



of optimizations

are related to


frequently changing

devices with


impact on

system


evolving

to different

Easily adapt

• Motivations

• Approach

• 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










Framework

2

Device

Local

Control

Platform Code

Driver

local

policy

1

Device

Driver

Device

local

policy

1










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










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










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










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


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


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


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


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



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







4. FSC validation





C12C11

C21

C23

C22

C32

C33

C31

m1

m2

FSC2

FSC1

FSC3







4. FSC validation





C12C11

C21

C23

C22

C32

C33

C31

µ1M

µ2M

µ1c

v1

v2

v3

m1

m2

FSC2

FSC1

FSC3







4. FSC validation





C12C11

C21

C23

C22

C32

C33

C31

µ1M

µ2M

µ1c

v1

v2

v3

m1

m2

Convex−Hull

FSC2

FSC1

FSC3







4. FSC validation





C12C11

C21

C23

C22

C32

C33

C31

µ1M

µ2M

µ1c

v1

v2

v3

m1

m2

Convex−Hullog

o2

o1

O

O’

FSC2

FSC1

FSC3


Design

Framework Design

• framework core◦ data types, ASM◦ glue code◦ user-space API

• platform code◦ PSM definition

• device drivers◦ DWR definition◦ constraints auth.

• governor◦ FSC identification

• policy◦ FSC ordering◦ constraints auth.

cpm_core

cpm_sysfs

cpm_policy

cpm_governor

platform_code

cpm_data

4 update

2 register

7 monitor

1 register 3 subscribe

driver

5 update_request

6 notify

Device Drivers

export framework

data

require framework

integration

provide framework

implementation

indirect calldirect callfunctional dependency

Legend

Platform Code

CPM Framework

CPM Policies

Main framework components and their relationship


Usage examples

Example - System-Wide Metrics Definitions

// SWM Identifiers definitions

#define SWM_AMBA_BANDWIDTH CPM_ASM_TOT+0

#define SWM_ADSP_CLK CPM_ASM_TOT+1

// Platform specific SWM (PSM) definition

struct cpm_swm cpm_platform_psm[] = {

CPM_PLATFORM_SWM("AMBA_BANDWIDTH", CPM_TYPE_GIB, CPM_USER_RW,

CPM_COMPOSITION_ADDITIVE, 0, 8000),

CPM_PLATFORM_SWM("ADSP_CLK", CPM_TYPE_GIB, CPM_USER_RO,

CPM_COMPOSITION_ADDITIVE, 0, 266),

};

// PSM Registration

struct cpm_platform_data cpm_platform_data = {

.swms = cpm_platform_psm,

.count = ARRAY_SIZE(cpm_platform_psm),

};

cpm_register_platform_psms(&cpm_platform_data);

Go to Definition


Usage examples

Example - Device Working Region

struct cpm_swm_range vdsp_dwr0_ranges[] = { /* V-DSP MPEG4 decoding mode */

DEV_DWR_ASM(CPM_VCODEC, 1, 1, CPM_ASM_TYPE_RANGE),

DEV_DWR_ASM(CPM_DSP_CLK, 40, 132, CPM_ASM_TYPE_RANGE),

};

struct cpm_swm_range vdsp_dwr1_ranges[] = { /* V-DSP OFF mode */

DEV_DWR_ASM(CPM_VCODEC, 0, 0, CPM_ASM_TYPE_RANGE),

DEV_DWR_ASM(CPM_DSP_CLK, 0, 132, CPM_ASM_TYPE_RANGE),

};

struct cpm_dev_dwr vdsp_dwrs_list[] = { /* V-DSP working mode */

DEV_DWR("Mpeg4", vdsp_dwr0_ranges, ARRAY_SIZE(vdsp_dwr0_ranges)),

DEV_DWR("OFF", vdsp_dwr1_ranges, ARRAY_SIZE(vdsp_dwr1_ranges)),

};

static struct cpm_dev_data vdsp_data = { /* V-DSP DWR’s registration */

.notifier_callback = vdsp_cpm_callback,

.dwrs = vdsp_dwrs_list,

.dwrs_count = ARRAY_SIZE(vdsp_dwrs_list),

};

ret = cpm_register_device(&vdsp.dev, &vdsp_data);

Go to Definition

cross-layer frameworks for constrained power and resources management of embedded systems

Technology