Simulation of a Self-adaptive Run-time Environment with Hardware and - - PowerPoint PPT Presentation

Simulation of a Self-adaptive Run-time Environment with Hardware and Software Components

Onur Derin, Alberto Ferrante

Advanced Learning and Research Institute Faculty of Informatics Universit` a della Svizzera italiana Lugano, 6900, Switzerland name.surname@alari.ch

SINTER’09

August 25, 2009

Outline

A model of self-adaptive systems SACRE Framework Extending SACRE on heterogeneous platforms Conclusion

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 2/20

Introduction: Self-Adaptivity Definition

Self-adaptivity is the capability of a system to adapt itself dynamically to achieve its goals.

Why self-adaptation?

Changing internal and/or external conditions e.g. moving with a portable device between wired and wireless networks, switching to battery power Increasing complexity of systems and difficulties in integration (self-organization - specification tradeoff principle Some information is available only at run-time (application specific vs. general purpose, design space exploration vs. run-time adaptation)

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 3/20

Monitor-Controller-Adaptor Paradigm

Adaptation Space Controller

Self-adaptive system

Monitorable Space Goals

A goal is a boolean expression with terms from monitorable space. e.g. different implementations- parameters, available cores, available HW functional units, clock frequency e.g. frame size, resource utilization, cache miss rate, power consumption

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 4/20

Quality measures for a self-adaptive system

Adaptation coverage How big is the adaptation space? Separation of concerns Is the application programmer concerned with self-adaptivity aspects? Adaptation management How good is the controller? Adaptation requirements (goal) specification How big is the monitorable space? How are goals specified?

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 5/20

Layered Model

ASApplication ASRun−timeEnvironment ASHardware Controller

Self-adaptive system

MSApplication MSRun−timeEnvironment MSHardware Goals

A goal is a boolean expression with terms from monitorable space. e.g. different implementations- parameters, available cores, available HW functional units, clock frequency e.g. frame size, resource utilization, cache miss rate, power consumption

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 6/20

Layered Model

ASApplication ASRun−timeEnvironment ASHardware CApplication CRun−timeEnvironment CHardware

Self-adaptive system

MSApplication MSRun−timeEnvironment MSHardware Goals

A goal is a boolean expression with terms from monitorable space. e.g. different implementations- parameters, available cores, available HW functional units, clock frequency e.g. frame size, resource utilization, cache miss rate, power consumption

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 6/20

Component-based approach

Main enabler for application-level and RTE-level adaptation is a component-based approach. allows the framework to be aware of the run-time characteristics

• f components

thus separation of concerns

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 7/20

Model of a self-adaptive heterogeneous system Self-adaptive Component Framework

the component run-time environment is extended with an MCA loop does application level adaptations does RTE-level adaptations

Resource manager adapts concurrency, redundancy and mapping.

Goals as lower/upper bounds or Min/Max.

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 8/20

SACRE Framework Component model

based on the KPN model of computation suited for streaming applications A SACRE component

extends the SACREComponent abstract class implements the task() method has a thread of its own specifies its input and output ports exchanges typed messages through its named input and output ports is adaptable

has a command interface for adaptations input and output ports are hookable ports can be connected to a different connector at run-time declares its adaptable parameters

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 9/20

SACRE Framework

Connectors

unbounded buffers that hold typed messages blocking read, non-blocking write connects one output port to one input port

Pipelines

created by means of a simple language

;-separated list of statements & for parallel, ! for serial composition & has precedence over !

no cycles = ⇒ deadlock-freedom

A B C D E F input port connector

• utput port

Figure: A & B ! C ! D ! E & F

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 10/20

Possible adaptations at Application Level

Parameter adaptation of a component Ci(pi) ⇒ Ci(pj) Structural adaptation

Replacement of a component Ci ⇒ Cj Parallelization of a component Ci ⇒ {Cij} Transformation with adaptation patterns for high level goals such as dependability and security Gi{C} ⇒ Gj{C ′}

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 11/20

Case Study: A self-adaptive MJPEG streaming server

Adapter Controller Monitor

R2B

Quality level

Source DCT Quantize ZZE RLE Sink

Picture size, Network bandwidth Latency,

Goal

FPS > FPST ⇒ Latency <

1 FPST and FrameSize < Bandwidth FPST

maximize PictureSize and Quality

Adaptation & Monitoring Space

ASApplication = {PictureSize, EncodingQuality} MSApplication = {Latency, Bandwidth}

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 12/20

Enabling RTE-level adaptations with HW and SW components

Need for a component run-time environment with a unified view of SW and HW components

a distributed component middleware on the heterogeneous platform

a software layer on processor cores a hardware wrapper/proxy on reconfigurable units

its extension to enable adaptation capabilities with a mix of HW and SW components (e.g. replacement of a SW component with a HW component)

Initial solution: Extending SACRE

functional simulation an abstract solution to be refined on real platforms

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 13/20

Extending SACRE for RTE-level adaptations Assembly

composition of components into a single SACRE component Composite Resource

Mapping

a total function from components to resources to show that a component runs on a resource

Resource pipeline

the pipeline that emerges from the composition of resource components

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 14/20

An extended SACRE example

CPU2 FPGA1 CPU1 B D A input port connector

• utput port

E F G C

resource CPU1: A, B, D resource CPU2: C, G resource FPGA1: E, F pipeline App1: A ! B & C ! D ! E ! F ! G

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 15/20

How to connect the internal ports to resource ports?

Problem: Cyclic resource pipeline is prone to deadlocks!

• Sol. 1

merge the two ports as one ⇒ resource thread becomes useless

• Sol. 2

resource thread transfers tokens between internal and external connectors ⇒ connector concept has to be modified, reading order is important

• Sol. 3

introduce middleware components ⇒ reading order is important. MW components can also be used to implement adaptation capabilities.

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 16/20

Inserting middleware components

CPU2 FPGA1 CPU1 B D A C G E F

1 1 2 2 3 5 4

task() of a middleware component is simply implemented by calling read and write operations on its ports labeling function label the edges of the application pipeline with an integer value that represent the maximum number of application components that a token may go through until arriving to that edge. tokens are forwarded from the input channels with a smaller-labeled-channel-first fashion

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 17/20

Adaptation capabilities to be implemented in extended SACRE

parametric adaptation of the resource structural adaptation of the resource pipeline structural adaptation of the application pipeline over the resource pipeline

migration of a component from one resource to another

create the same type component instance in the destination resource remove/add ports from/to middleware components relabel edges

paralellization onto multiple cores dependability pattern makes sense as well

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 18/20

Conclusion

extended our model for self-adaptive systems for RTE-level adaptations on heterogeneous platforms identified the requirements for a self-adaptive heterogeneous component run-time environment proposed to extend SACRE as an initial solution

provides an abstract solution for future refinements allows experimenting with adaptation algorithms

associate costs to application components (e.g. execution time, power) centralized vs. decentralized control mapping policies adaptation patterns for high-level goals

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 19/20

Publications

• O. Derin, A. Ferrante, A. V. Taddeo. Coordinated management of

hardware and software self-adaptivity. Journal of System Architecture, 55(3):170-179, 2009.

• O. Derin, A. Ferrante, A. V. Taddeo. Coordinated management of

hardware and software self-adaptivity: What do we need from reconfigurable computing?. presented in Reconfigurable Computing Italian Meeting (RCIM’08), Milano, December 2008.

• O. Derin, A. Ferrante. Enabling self-adaptivity at application level.

presented in 2nd AETHER-Morpheus Workshop (AMWAS’08), Lugano, October 2008.

• A. Ferrante, A. V. Taddeo, O. Derin. Security in self-adaptive
• systems. presented in 1st AETHER-Morpheus Workshop

(AMWAS’07), Paris, October 2007.

Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 20/20