rcim 2008 - - alari
TRANSCRIPT
Coordinated Management of Hardware andSoftware Self-adaptivity
What do we need from Reconfigurable Computing?
Onur Derin, Alberto Ferrante, Antonio V. Taddeo
Advanced Learning and Research InstituteFaculty of InformaticsUniversity of Lugano
Lugano, 6900, Switzerland
December 19, 2008
Outline
Introduction
Adaptation ManagementLayered ModelSimulations
Component-based ApproachComponent-based Model at Application LevelComponent-based Model at Hardware Level
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 2/29
Introduction
What is the aim of this presentation?
provide requirements for a reconfigurable platformto implement our vision of Self-Adaptive Run-timeEnvironment (RTE).
What have we done?
modelling of Self-Adaptive Systems;
management of adaptation at SW and HW level;
enabling self-adaptation at Application level;
enabling self-adaptation at RTE & HW level.
This work was supported by EU-FET AETHER project.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 3/29
Introduction: Self-Adaptivity
DefinitionSelf-adaptivity is the capability of a system to adapt itselfdynamically to achieve its goals.
Why self-adaptation?
Changing internal and/or external conditionse.g. moving with a portable device between wired and wirelessnetworks, switching to battery power
Increasing complexity of systems and difficulties in integration(self-organization - specification tradeoff principle Buchli andSantini [2005])
Some information is available only at run-time (applicationspecific vs. general purpose)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 4/29
Monitor-Controller-Adaptor Paradigm
AdaptationSpace
Controller
Self-adaptive system
MonitorableSpace
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
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 5/29
Quality measures for a self-adaptive system
Adaptation coverageHow big is the adaptation space?
Separation of concernsIs the application programmer concerned with self-adaptivityaspects?
Adaptation managementHow good is the controller?
Adaptation requirements (goal) specificationHow big is the monitorable space? How are goals specified?
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 6/29
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
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 7/29
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
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 7/29
Layered Model
Resource Manager
Hardware Abstraction Layer
Resource Allocator
RTE level
RTE-SW Interface
RTE-HW Interface
Application level
SW-RTE Interface
Hardware level
HW-RTE Interface Self-*
Self-*
Goal achievement+tasks Results
Goals+tasks + recommendations
Results + monitored parameters
Component Repository Component Framework
Component-based Application
Self-*
Recommender
Goals
application level self-adaptivitywill be mentioned in the nextsection.
RTE adapts concurrency(resource allocator) andmapping (HAL).
Goals as lower/upper bounds orMin/Max.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 8/29
Evaluation of the model
covers self-adaptation at application, RTE and HW level
separates functionality from adaptation concern
simple decentralized controllers coordinated with arecommendation mechanism
goals are externalized, made explicit and have to be specifiedby the application programmer
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 9/29
Simulation: A self-adaptation example
Given a system with
adaptation space
AS = ASApplication × ASRTE × ASHardware such thatASApplication = {Impl1, Impl2} and that Impl2 yields higherthroughput on a reference architectureASRTE = {} (no concurrency adaptation or dynamic mapping!)ASHardware = {flow , fhigh}
monitorable space
MSApplication = {throughput}MSRTE = {}MSHardware = {power}
goals
mTh > mTTh
mP < mTP
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 10/29
Simulation Model
Application-level Controller
Hardware Controller
Adaptable/Monitorable System
clock frequency
algorithm implementation
power
throughput
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 11/29
Simulation Model
Application-level Controller
RTE Controller (Recommender)
Hardware Controller
Adaptable/Monitorable System
rec. activation goal achievement
recommendation
clock frequency
algorithm implementation
power
throughput
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 11/29
Controller 1
Impl1
start
Impl2
mTh < mTTh
mTh > mTTh
mTh > mTTh
mTh < mTTh
App. Controller
flow fhigh
start
mP < mTP
mP > mTP
mP > mTP
mP < mTP
HW Controller
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 12/29
Simulation Results (Controller 1)
flow
fhigh
0 20 40 60 80 100 120 140 160 180 200
freq
uenc
y
time (unit)
HW controller
HW adaptation
Impl1
Impl2
0 20 40 60 80 100 120 140 160 180 200
impl
emen
tatio
n
time (unit)
App. controller
App. adaptation
mPT
0 20 40 60 80 100 120 140 160 180 200
pow
er
time (unit)
System Power (mP)
mThT
0 20 40 60 80 100 120 140 160 180 200
thro
ughp
ut
time (unit)
System Throughput (mTh)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 13/29
Controller 2
Impl1
start
Impl2
mTh < mTTh
mTh > mTTh
App. Controller
flow fhigh
startmP > mT
P
mP < mTP
HW Controller
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 14/29
Simulation Results (Controller 2)
flow
fhigh
0 20 40 60 80 100 120 140 160 180 200
freq
uenc
y
time (unit)
HW controller
w/ recommendationw/o recommendation
Impl1
Impl2
0 20 40 60 80 100 120 140 160 180 200
impl
emen
tatio
n
time (unit)
App. controller
w/ recommendationw/o recommendation
mPT
0 20 40 60 80 100 120 140 160 180 200
pow
er
time (unit)
System Power (mP)
w/ recommendationw/o recommendation
mThT
0 20 40 60 80 100 120 140 160 180 200
thro
ughp
ut
time (unit)
System Throughput (mTh)
w/ recommendationw/o recommendation
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 15/29
Introduction: Component-based Design
Main enabler for SW-RTE-HW adaptation is a component-basedapproach.
DefinitionA component is a self-contained element which encapsulates aspecification of a functionality, with well-defined interfaces tointeract with other components.
DefinitionA component model specifies a formalism to design a component.It defines inputs/outputs and component usage.
DefinitionA component framework manages components by instantiatingand composing them.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 16/29
Enabling Self-adaptivity at Application Level
Resource Manager
Hardware Abstraction Layer
Resource Allocator
RTE level
RTE-SW Interface
RTE-HW Interface
Application level
SW-RTE Interface
Hardware level
HW-RTE Interface Self-*
Self-*
Goal achievement+tasks Results
Goals+tasks + recommendations
Results + monitored parameters
Component Repository Component Framework
Component-based Application
Self-*
Recommender
GoalsComponent Framework
run-time system that implements theglue logic in compliance with thecomponent model
Component model
defines the standard interfacesbetween components
This model
allows the framework to beaware of the run-timecharacteristics of softwarecomponents
thus separation of concernsTaddeo, ALaRI RCIM 2008— Self-adaptive Systems, 17/29
New application development flow
Design time
extend component run-time system with an adaptation loopand adaptation skills (next slide)create adaptable (parameterized or compliant) versions of thecomponents in the component repository
Given a component graph and application goals
Run-time
parse goalsreplace components with their adaptable versionshook up relevant monitoring componentsinstatiate the controller
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 18/29
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 goalssuch as dependability and securityGi{C} ⇒ Gj{C ′}
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 19/29
Case Study: A self-adaptive video streaming server
Adapter
Monitor
Controller
Monitor Controller Recomm.
Recommendationsfor HW level
Adapter
Monitor
Controller
Video streaming server Hardware
Hardware levelApplication level
Clock frequency, Voltage level
Power
Picture size, Quality level
Latency
GoalFPS > FPST ⇒ Latency < 1
FPST and FrameSize < BandwidthFPST
Adaptation & Monitoring Space
ASApplication = {PictureSize, EncodingQuality}MSApplication = {Latency}
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 20/29
GStreamer
a library for constructing of graphs of media-handlingcomponents i.e. software component framework
already ported to N800
extendible
An Ogg player
gst-launch filesrc location="test.ogg" ! oggdemux name=d
d. ! queue ! theoradec ! ffmpegcolorspace ! ximagesink
d. ! queue ! vorbisdec ! audioconvert ! audioresample ! osssink
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 21/29
Enabling SW-RTE-HW Self-Adaptation
Provide a unified view of SW and HW components
extend the RTE with a component middleware in order tomanage software and hardware components.enable adaptation capabilities with a mix of HW and SWcomponents (e.g. replacement of a SW component with a HWcomponent)
Case study
Create gstreamer components that use the DSP processor ofN800 (already done by TI)
Implement transparent migration of a software componentbetween ARM and DSP processors (of N800)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 22/29
What do we need from Reconfigurable Computing?
What does the component middleware needfrom the reconfigurable platform?
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 23/29
HW component abstraction
What is a hardware component for our Middleware point ofview?
it can have different size;
it should implement a specific functionality(e.g. FFT);
it should be compliant to the component model;
it should be manageable by the component framework.
What is reconfigurable? (i.e. adaptation skills)
The component itself!
The component interactions (e.g. topology).
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 24/29
HW component: adaptation
How is the HW component adaptation by Middlewareperformed?
Instantiation of components.Component-Create("FFT");
Adaptation of high level component interactions.Component-Connection("FFT", ...);
Requirements:
The reconfigurable platform should allow these ”services”.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 25/29
HW component: placement
The role of the Middleware
The Middleware is not responsible of component placement.
The Middleware considers HW components as resources touse.
The role of the Reconfigurable Platform (?)
Efficient use of fabric.
Garbage Collector.
De-fragmentation.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 26/29
Conclusion
Proposed a model for self-adaptive systems that features
decentralized controllers and a recommendation mechanism tocoordinate adaptation management;HW-SW adaptation coverage;separation of self-adaptivity concerns from functionality;goal specification interface.
Proposed a flow to implement self-adaptive applications basedon component technologies.
Tried to identify the requirements for a reconfigurableplatform to implement our Self-Adaptive RTE.
Self-adaptivity and component-based approach works welltogether
self-adaptivity enables satisfying NFRs.component-based approach enables self-adaptivity by providingan adaptation space.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 27/29
Publications
A. Ferrante, A. V. Taddeo, O. Derin. Security in self-adaptivesystems. presented in 1st AETHER-Morpheus Workshop(AMWAS’07), Paris, October 2007.
O. Derin, A. Ferrante, A. V. Taddeo. Coordinated management ofhardware and software self-adaptivity. Journal of SystemArchitecture, doi:10.1016/j.sysarc.2008.07.002, July 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, M. Sami, F. Mantovani, J. FridkinsSelf-adaptive Security at Application Level: a Proposal.presented in ReCoSoC 2007, Montpellier, France, Jun. 2007.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 28/29
References I
J. Buchli and C.C. Santini. Complexity Engineering: HarnessingEmergent Phenomena as Opportunities for Engineering. InReports of the Santa Fe Institute’s Complex Systems SummerSchool 2005. Santa Fe Institute, 2005.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 29/29