Adaptability:viewpoint from INRIA-Rennes

and the UNIPI-INRIA joint-work

CoreGrid WP3 Kraków meeting - June 2006Françoise André & Jérémy Buisson

Subtask 3.3Research group on “Performance models and adaptivity”

2

Outline

• Collaborative work UNIPI/INRIA– Leading to a common high-level model

• UNIPI’s interpretation: ASSIST

• INRIA’s interpretation: Dynaco/AFPAC

3

Dynamic adaptability

• Ability of applications to modify themselves at runtime in order to adapt to their dynamically changing context

• Many independent projects: ASSIST, Dynaco/AFPAC, GrADS , PCL, Safran, Plasma, AppLeS/AMWAT/APST, Active Harmony, …

4

Adaptability for grid computing

• Platform: availability evolves dynamically– Not only faults– But also activities of concurrent users– And planned maintenance

5

Adaptability for grid computing• Example of announced maintenance operations

– Table of planned events for the Grid5000 platform– Source: www.grid5000.fr, taken upon June the 7th

• Should applications ignore those warnings?

Notification Date of the event Site Description

07 jun 6:59 08 jun 8:00 → 08 jun 12:00 Rennes Maintenance, instable platform

05 jun 15:35 08 jun 9:00 → 08 jun 18:00 Orsay Air conditioning maybe off again, so maybe also our cluster ?!

23 may 10:46 08 jun 9:00 → 09 jun 18:00 Lille Cluster upgrade: cluster will be shutdown to install new nodes, management cards, console management

6

Adaptability for grid computing

• Applications– May experience long execution time

• Usually longer than the mean time between platform changes

– May have dynamic needs• E.g. data-driven behavior

Applications should adapt at runtime

7

Common schema

• Aims at providing a high-level abstract model– Unifies the approaches of UNIPI (ASSIST)

and INRIA-Rennes (Dynaco/AFPAC)– Applies to other approaches

• Helps developers in designing and implementing adaptability

8

Common schema

• Hierarchically splits the adaptation process in phases– Voluntarily under-specified– Two main phases at the higher level

• Decide whether the application should adapt

• Commit the decisions

9

Decide phase

• Decides whether the application should adapt– Filters the changes that occur in the platform

• Identify those that are significant enough• Discard the others

– Determines a strategy for adapting the application

• Two sub elements– Trigger: notification reception from the platform– Policy: specialization of the decide phase to the actual

application

10

Commit phase

• Applies a given strategy– Identifies the actions that should be performed– Executes those actions

• Two sub elements– Plan: creation of an implementation of the strategy– Execute: execution of the plan

• Split in turn into– Mechanisms: individual actions used to implement the strategy

– Timing: scheduling and synchronization with the execution of the application

11

Approach of UNIPI

• Compiler-based approach– Allows adaptability transparently to developers

• Adaptation points placed by the compiler• Some adaptation mechanisms automatically generated

– E.g. redistribution

• Implemented in the ASSIST development environment for grid computing– Parmod skeleton is intrinsically adaptable

• Changing the number of Virtual Processes Managers (VPM) executing the Virtual Processes (VP)

• Redistributing VPs over VPMs

– Parmod skeleton has a known performance model

12

ASSIST

• Runtime support– Reflects the common

abstract model

• Control loop– Receive feedback from the

trigger interface– Make decisions depending

on the parmod skeleton performance model

– Target only involved VPMs

13

Approach of INRIA-Rennes

• Framework-based– Allows adaptability for legacy applications– Allows developers to design their own adaptability– May provide a runtime support for compiler-based

approach/automatic adaptability generation

• Split in two parts– Dynaco: generic adaptability framework– AFPAC: SPMD adaptable components

14

Dynaco

• Defines an architecture for adaptability– Some key components

• Monitor; Decider; Planner; Executor

– Interactions and interfaces between those components

– Concerns implemented by each of those components

• Provides a reference implementation– Written in Java for the Julia implementation of Fractal

• Gives some hints for binding adaptability to components– Using Fractal’s controllers and AOP

15

Dynaco framework• Reflects the common abstract model• Contains four major components, which model the four major

phases and the four major concerns– Monitor the platform and resources– Decide whether the component should adapt– Plan how the component could be adapted– Execute the plan, which is composed of actions

16

AFPAC toolbox

• One Dynaco component that wraps an SPMD code– With one special action that triggers SPMD actions, i.e. one

action replicated in each process

• One executor local to each process– Coordinates together the execution of local actions

• Based upon developer-provided “adaptation points”

17

Connections to the GCM

• Could be used to make GCM components adaptable– ASSIST adaptable parmods can be

encapsulated into GCM components– Dynaco may allow to implement adaptability

for GCM components

18

Requirements from GCM

• Whatever the case, requires from GCM– Place-holder for adaptability

• In a customizable controller/membrane/container?

– Technology for integrating it• Aspect oriented programming?• Specialized structured programming paradigm?

19

Some web links

• Research group on “Performance models and adaptivity”: http://www.di.unipi.it/~marcod/WP3homepage/RG_adaptivity/index.html

• Assist website: http://www.di.unipi.it/Assist.html

• Dynaco website: http://dynaco.gforge.inria.fr/

• Adaptability within the PARIS team: http://www.irisa.fr/paris/web/adapt.html