Supports d’exécution pour grappes de machines SMP

Supports d’exécution pour grappes de machines SMP

Raymond NamystProjet INRIA ReMaPLIP, ENS Lyon

Plan

Multithreading Introduction et rappels

Exploitation efficace des machines SMP Ordonnancement mixte, activations

Multithreading distribué Modèles de programmation Intégration des threads et des

communications Conclusion

Pas si simple…

Multithreading

Introduction et rappels

Rappel : les processus lourds

Caractéristiques Entité active directement supportée par

l’OS Flot d’exécution Espace d’adressage privé Ressources systèmes

Exécution séquentielle Coût de gestion élevé

Allocation des ressources Appels systèmes

Processus lourds

Ressources “noyau” + données “utilisateur”

processeur processeur processeur

Noyau

Processus

Ordonnanceur

Espace utilisateur

Processus Processus

Threads : Motivations

Difficulté de programmation Fil d’exécution unique

une seule chose à la fois !

Partage de données laborieux Réactivité aux sollicitations externes

Performances Opérations de base coûteuses Recouvrement des opérations d’E/S

difficiles

Simplicité de programmation

Objectif Mener plusieurs activités indépendantes

au sein d’un processus Exemples

Simulations Serveurs de fichiers Systèmes d’exploitation (!)

Seule solution (?) Automate à états finis implanté « à la

main »(sauvegardes d’états)

Structure d’un OS monolytique

Exemple

Séquence infinie d’opérations courtes Ordre et fréquence des scrutations ?

for (;;) {

if(networkMsgIn()) getNetworkMsg();

if(kbdReady()) getKey();

if(diskBlockReady()) handleDiskBlock();

…

}

Systèmes multiprogrammés

Exécution indépendante des activités Concurrence entre les différents

traitements

for (;;) {

wait for network msg;

getNetworkMsg();

}

for (;;) {

wait for key stroke;

getKey();

}

for (;;) {

wait for disk block;

handleDiskBlock();

}

Processus serveur classique

Sérialisation des requêtes

Pas de recouvrement des E/S Exploitation SMP délicate Prise en compte de priorités ?

OS OS

client serveur

Sur l’efficacité des E/S

Caractéristiques du serveur de fichiers Tps de traitement d’une requête = 15ms Tps supplémentaire pour l’accès disque =

75ms (pour 1/3 des requêtes)

Débit sans/avec recouvrement des E/S Sans recouvrement

25 requêtes/seconde

Avec recouvrement 33.33 requêtes/seconde (+33%)

Les processus légers

Principe Détacher flot d’exécution et ressources

Introduits dans divers langages & systèmes Programmation concurrente Recouvrement des E/S Exploitation des architectures SMP

thread

ressources

Caractéristiques de base

Thread = pile + contexte Partage de ressources

Code, tas, … : espace d’adressage Fichiers ouverts Etc.

Opérations de base performantes Création, destruction Synchronisation, commutation de contextes

Création d’un processus léger Adresse de fonction à exécuter +

paramètres

Performance des threads

Opérations critiques Création/destruction (gestion mémoire) Changement de contexte (temps-

partagé) Synchronisation (mode utilisateur)

Programme d’évaluation Création d’une activité (processus,

thread)+ synchronisation (terminaison de l’activité)

OS/Processeur Processus

Thread noyau

Thread utilisateur

PM2

Linux 2.2/PII 450 0.540 0.130 - 0.006

Solaris 2.7/PII 350

8.622 0.214 0.160 0.009

Repères historiques

L’ancêtre : les coroutines Entrelacement explicite des exécutions Langages : Simula (67), Modula2 (82) Primitives clés : create + resume

Les threads dans les systèmes Cthread (Mach) -> DecThread -> PThread

(~90) Chorus, Solaris (87), winNT, IRIX, Linux, etc.

Les threads dans les langages Ada (83), Java, etc. C++ //, Eiffel //, etc.

Multithreading

Premier contact

L’interface POSIX-Threads

Interface de programmation standard pour Unix Portabilité des applications Solaris, IRIX, HP-UX, Linux, etc.

Fonctionnalités Création/destruction de threads Synchronisation Ordonnancement, priorités Signaux Etc.

Exemple: création

Création d’un nouveau thread Éventuels attributs dans la structure attr Exécution de start_func avec le paramètre

arg *pid est l’identificateur du thread créé

int pthread_create( pthread_t *pid,

pthread_attr_t *attr,

void * (*start_func)(void *),

void *arg);

Attente de fin d’exécution

Attente de la terminaison du thread pid Récupération de son code de retour

status On peut contourner ce mécanisme en

« détachant » les threads :

int pthread_join( pthread_t pid,

void **status);

int pthread_detach( pthread_t pid);

« Hello World! »

#include <stdio.h>#include <pthread.h>

void *func(void *arg){

printf(“Thread %x says %s\n”, pthread_self(), arg);return NULL;

}

int main(void){

pthread_t pid;

pthread_create(&pid, NULL, func, “Hello World!”);printf(“This is the main thread\n”);pthread_join(pid, NULL);return 0;

}

Attributs

Ensemble fixé de caractéristiques Utilisé à l’initialisation Threads, verrous, variables de condition,

etc. Threads

Priorité Pile : taille, emplacement Détaché : oui/non Type d’ordonnancement

Verrous Inversion de priorités, récursivité

Attributs : exemple

#include <stdio.h>#include <pthread.h>

void *handle_request(void *arg){

…}

int main(void){ …

pthread_attr_t attr;

for(;;) {fd = accept(sock, …);pthread_attr_init(&attr);pthread_attr_setdetachstate(&attr,

PTHREAD_CREATE_DETACHED);pthread_create(NULL, &attr, handle_request, fd);

}}

Exemple bis : pile

À manipuler avec précaution ! Quelle taille de pile choisir ? Comment prévenir/détecter les

débordements ?

pthread_attr_t attr;

pthread_attr_init(&attr);pthread_attr_setstacksize(&attr, 128*1024);pthread_create(NULL, &attr, func, NULL);

Le standard OpenMP

Interface pour écrire des applications multithreads portables (sur SMP) Directives de compilation (C, C++, Fortran)

+ routines Objectif = simplicité + portabilité Constructeurs + fabricants de logiciels +

etc. Modèle de programmation

« Fork-Join » Parallélisation des boucles (#pragma omp)

Multithreading

Partage mémoire efficace

Les threads et la mémoire

Chaque thread possède sa propre pile Variables locales « privées » ( visibilité)

Les threads partagent l’espace d’adressage Variables globales Tas (malloc) Variables locales (piles) également !

Intérêt Communications par pointeurs ! Parallélisation de programmes séquentiels

aisée ?

Problèmes de réentrance

Exemple simple :int glob = 0;

void *inc(void *arg){ int i;

for(i=0; i<100; i++)glob++;

}

int main(void){

pthread_create(&t1, NULL, inc, NULL);pthread_create(&t2, NULL, inc, NULL);

pthread_join(t1, NULL); pthread_join(t2, NULL);printf(“glob = %d\n”, glob);

}

Résultat ?

Explication

glob++ n’est pas forcément une opération atomique

Scénario d’exécution concurrente par 2 threads :

Mov @glob, $r1 ; chargerInc r1 ; incrémenterMov $r1, @glob ; enregistrer

Mov @glob, $r1Inc r1

Mov @glob, $r1Inc r1Mov $r1, @glob…

Mov $r1, @glob

Mov @glob, $r1Inc r1

Mov @glob, $r1Inc r1Mov $r1, @glob…

Mov $r1, @glob

Outils pour la synchronisation

Exclusion mutuelle : les verrous

Synchronisations plus complexes : Variables de condition (cf moniteurs de

Hoare) pthread_cond_wait pthread_cond_signal, pthread_cond_bcast

int glob = 0;

void *inc(void *arg){

for(i=0; i<100; i++) {pthread_mutex_lock(&mutex);glob++;pthread_mutex_unlock(&mutex);

}}

Code réentrant

« code demeurant correct lorsqu’il estexécuté simultanément par plusieurs threads »

Exemples typiques Fonction n’utilisant que des variables locales Code protégé par un verrou

Quid du code que l’on écrit pas soi-même ? Malloc, free, …, la bibliothéque standard Fonctions « MT-safe »

Option –D_REENTRANT Certains prototypes changent…

Importance de la synchro.

Cohérence séquentielle de la mémoire ? Compilateurs/Optimiseurs

Instructions réordonnées

Processeurs modernes Ecritures réordonnées

On ne peut pas supposer l’ordre des écritures

Primitives de synchronisation Agissent comme des « barrières

mémoire »

Variables spécifiques

Pb : comment gérer les variables globales « privées »

int my_x;

void g(void){

…my_x…}

void f(void){

my_x = do_compute();…g();

}

Variables spécifiques

Principe Variable accessible à partir d’une clé Allocation globale (souvent à l’initialisation)

pthread_setspecific(clé, valeur) pthread_getspecific(clé) -> valeur

Exemple : la variable errno Fichier errno.h

#ifdef _REENTRANT#define errno (*__errno_location())

#elseextern int errno;

#endif

Multithreading

Quelques idées reçues ?

A propos d’efficacité…

Les threads sont-ils toujours meilleurs que MPI sur architectures SMP ?

Approche « processus communicants » Communications pénalisantes (copies) Surcoût en utilisation de ressources Recouvrement plus difficile

Approche « processus légers » Synchronisations additionnelles Accès aux variables spécifiques coûteux

Exploitation efficacedes machines SMP

Quelle catégorie de threads ?

Multithreading utilisateur

Deux ordonnanceurs indépendants :

processor processor processor

OS Kernel

Process Process Process

Scheduler

User Space

Scheduler Scheduler

Multithreading noyau

Un seul ordonnanceur :


OS Kernel


Scheduler

User Space

Multithreading mixte

Deux ordonnanceurs coopérants


OS Kernel


Scheduler

User Space

Scheduler Scheduler

Note: Quid des appels systèmes bloquants ?

Performances

Athlon 1.4GHz, DDR2100Opération Unix

(fork)pthrea

dclone Marce

l SMPMarce

l mono

Chgt contexte

600 ns

370 ns 350 ns

180 ns

65 ns

Création 80 us 35 us 14 us 1.7 us 0.82 us

Alpha 500MHzOpération Unix

(fork)pthrea

dclone Marcel

SMPMarc

el mono

Chgt contexte

1.750 us 1.740 us

1.7 us

815 ns 560 ns

Création 640 us 190 us 90 us

8 us 4 us

E/S et ordonnancement

Threads noyaux : OK Threads utilisateurs

Appel bloquant -> blocage du processus entier

Threads mixtes Idem au bout d’un certain nombre !

Solutions ? Appels toujours non-bloquants (polling) Appels effectués par des threads dédiés Support système spécifique

Exploitation efficacedes machines SMP

Scheduler Activations

Recouvrement des E/S

Au lieu de

Espace noyau

Espace utilisateur

Matériel

syscall

…on voudrait :

Espace noyau

Espace utilisateur

Matériel

I/O request interrupt

Temps CPU perdu

CPU utilisé

Scheduler Activations

Introduit par [Anderson et al. 91] Idée: la coopération entre les deux

ordonnanceurs est bidirectionnelle L’ordonnanceur utilisateur utilise des appels

systèmes L’ordonnanceur noyau utilise des upcalls!

Upcalls Informe l’application des événements noyaux

Activations Autant d’activations en exécution que de

processeurs Contrôlées par le noyau

Principe mis en œuvre dans Solaris

Illustration du principe

Process

User scheduler


Process

new


Déroulement d’un appel bloquant…

Process

Appel système bloquant



Process

New + blocked



Process

Appel terminé



Process

Unblocked



Process

Difficultés de mise en œuvre

Retour d’un appel bloquant Un « unblock upcall » nécessite deux

appels systèmes supplémentaires… La généricité coûte cher !!

Perte du processeur Signalée par un upcall particulier

Objectif = éviter les attentes actives ! Conséquences

L’ordonnanceur de niveau utilisateur doit se prémunir contre ces interruptions intempestives

Le coût est prohibitif !

Coût de la préemption

Lorsqu’une activation est préemptée… L’ordonnanceur doit être averti Pourquoi ?

Un thread peut détenir un « spin-lock » ! Comment ?

En déclenchant un upcall preempt

Problèmes Une préemption peut survenir n’importe

quand Changements de contexte asynchrones Nécessité de protéger beaucoup de code

e.g. la fonction thread_yield() ...

Coût des appels bloquants

thread

blockingsyscall

spregisters

sp

activation


thread

sp

thread

activation

spregisters

sp

spblocked

activation

Clock int.

registerssp


thread

sp

thread

activation

spregisters

sp

registerssp

registersregisters

activation


thread

sp

thread

activation

sp

registerssp

registersregisters


thread

sp

thread

activation

jb sp

registersregisters

sys_restart


thread

sp

thread

activation

registers

Un modèle revisité

Contexte = calcul haute performance Une application // à la fois sur la grappe Optimisations pour ce cas de figure

Les activations perdent rarement le processeur

Propositions Suppression des évènements « preempt » Utilisation d’une pile par processeur

Implantation Linux 2.2.x Bibliothèque de threads Marcel

A propos de réactivité…

Problèmes liés aux évènements « unblock » Coût important, réactivité non-garantie

Proposition Pour les notifications non-urgentes

Positionnement d’une variable partagée Test à chaque changement de contexte

Pour les notifications critiques Lors du retour en mode utilisateur :

- Déviation vers le thread « client » de l’événement

Déviation éventuellement différée…

Modifications du noyau Linux

Parties du noyau modifiées schedule(), do_fork() and do_exit()

Implantation des transitions

task_struct structure Nouveaux champs (état des activations, etc.)

Code ajouté Appels systèmes + API pour les upcalls Gestion des upcalls (~signaux) Code pour les changements d’état des

activations

Performance (PC)

Single processor Dual processor

Library Synchro test I/O test With computations

Marcel/user-level 0.308ms Infini 6932ms

Marcel/hybrid 0.435ms 0.761ms 3807ms

Marcel/activations 0.417ms 1.300ms 3551ms

LinuxThread 13.319ms 0.773ms 3566ms

MultithreadingDistribué

Principe et Enjeux

Principe

Introduire les threads dans les applications distribuées

procproc proc proc

réseau

Enjeux

Bénéfices escomptés Meilleur support du parallélisme à grain

fin Recouvrement naturel des

communications Uniformisation de la configuration

Machines monoprocesseur/machines SMP

Intérêts

Apports des threads Virtualisation de l’architecture

Threads = processeurs virtuels Passage à l’échelle (scalability) Bonne cible pour des compilateurs

Meilleure réactivité au réseau Traitement asynchrone des messages

Équilibrage de charge par migration de threads Équilibrage dynamique Régulateur indépendant de l’application (plug-

ins) !


Quel modèle de programmation ?

Approche par juxtaposition

Principe : pas de modèle ! Simplement utiliser conjointement

Une bibliothèque de communication (ex: MPI) Une bibliothèque de multithreading

Problèmes Conceptuels

Pas de visibilité globale des threads Sémantique des communications ?

Techniques Compatibilité entre les bibliothèques Travail d’intégration spécifique -> non

réutilisable

Approche intégrée

Threads communicants A0, Chant

Pthreads + extensions Rthreads

Pthreads DSM-threads

Appels de procédure à distance « threadés » A0, Nexus, PM2

Threads communicants

Principe Envoi de message entre threads

Modèle « MPI-like » Modèle « Acteurs »

Nommage Nommage global des threads Ports de communication

Exemples Chant (M. Haines, ICASE) Athapascan-0b (J. Briat, INRIA Grenoble)

Modèle Pthreads étendu

Principe Threads + primitives étendues

Create/Join à distance Synchronisations distribuées

Particularités Nommage global des threads Restriction du modèle Pthreads

Exemples Chant (M.Haines, ICASE),

Rthreads (M. Zahn, Allemagne)

Modèle Pthreads distribué

Principe Adaptation complète (?) de Pthreads

Threads + mémoire virtuellement partagée

Transparence Cohérence assurée lors des défauts de

pages Restriction sur les E/S

Extensions Cohérences mémoires relâchées

Exemple DSM-Threads (F. Mueller, Berlin)

Modèle dérivé des RPC

Principe Appel de procédure à distance (A. Birell)

Extension du concept aux threads Création de threads pour exécuter les

procédures

Désignation globale des services Numéro fonction Souches (stubs) pour la transmission des

paramètres

Exemples Nexus (I. Foster, Argonne), PM2


L’environnement PM2

Projet PM2 (95-xx)

Objectif ambitieux : virtualisation Indépendance de la machine cible

(#processeurs) Degré de parallélisme important (#processus) Parler de “traitement” / “processus”

mécanismes de décomposition parallèle

Propositions Mécanisme de décomposition

Appel de procédure à distance léger (LRPC)

Support des activités Processus légers (threads)

Régulateur dynamique de charge Placement + Migration

Appel de procédure à distance

Différentes déclinaisons Synchrone Attente différée Asynchrone

PM2 PM2

LRPC

Nos concurrents... Nexus : RSR Athapascan : appels de service

Mobilité des activités

Migration de processus légers

PM2 PM2

Pourquoi ? Régulation de charge Localité des données

Comment ? Transfert du contexte Programmes SPMD


Communications dans un environnement multithreads

Communications performantes

Comment exploiter les réseaux rapides ? Faible latence

Quelques microsecondes Bande passante élevée

De l’ordre du Gb/s

Tendance actuelle Interaction directe avec la carte réseau

Communication en « mode utilisateur » Transmissions zéro-copie

La carte récupère/dépose les données au bon endroit

Ethernet

Cartes passives (sauf Giga-Ethernet) Interfaces : TCP, SBP, GAMMA, VIA, …

Network

TX reg

RX reg

Packet InterfacePacket InterfacePCI

Bridge

PCI

Bridge

PCI Bus

DMADMA

Memory

TX-ring

NIC

Myrinet

Produit Myricom (C. Seitz) Réseau commuté, routage wormhole

Carte programmable Protocoles de transmission

« intelligents » Stratégie adaptée à la taille des messages Déclenchement d’interruptions

NetworkRISC

Packet

Interface

DMADMA

PCI

Bridge

PCI

Bridge

PCI Bus

LANai

SRAMSRAM

NIC

Interface efficace pour Myrinet

BIP : Basic Interface for Parallelism Loic Prylli (ReMaP) en 1997

Performances Latence 5 s, bande passante > 125 Mo/s

Fonctionnalités réduites au minimum Messages courts : recopiés à l’arrivée Messages longs : mode zéro-copie (RDV)

Contrôle de flux minimal Matériel (msgs “évaporés” au dela de

50ms)

SCI : Scalable Coherent Interface

Réseau à “capacité d’adressage” Normalisé par IEEE en 1993 Principal constructeur : Dolphin ICS

Principe Accés mémoire distants

Implicites (après projection) Explicites (remote DMA)

Support matériel pour une MVP (?)

Performances Ecriture 2 s, lecture 4 s Bande passante 85 Mo/s (difficilement !)

Adressage à distance

Projections effectués par le pilote (SISCI) Zones de mémoire physiques souvent spécifiques

Accès mémoire effectués par le processeur Le processeur distant n’est pas (forcément) interrompu

Interconnexion SCI

Processus A

Espace d'adressage

virtuel

Bus PCI

PCI-SCI

Processus B

Espace d'adressage

virtuel

Bus PCI

PCI-SCI

Mémoire physique

Ce qu’il faut retenir

Interfaces de très bas niveau ! Fonctionnalités proches du matériel

Grande efficacité Paradigmes très différents Approche non généralisable

Pas de consensus Tentative de standard : VIA

- Virtual Interface Architecture (Intel, Microsoft, Compaq)

- But : dénominateur commun- Bas niveau, peu adapté à certaines technologies

Portabilité ???

Contexte et motivations

Concilier efficacité et portabilité

Il y a MPI…

Implantations efficaces existantes MPICH/BIP, MPICH/SISCI, etc.

Quid des schémas de communication de la vraie vie ?

Messages dont le contenu est inconnu a priori par le récepteur

- Transmissions zéro-copie ?

Messages asynchrones- Recouvrement des communications ?

Accès mémoire distants (PUT/GET)- Temps de réponse ?

Transmissions zéro-copie

Processus A Processus BRéseau

Préparation mémoire

Acquittement

Message

EntêteDonnées

DMA

Et la réactivité alors ?

Problèmes Assurer la progression des communications

asynchrones Réagir rapidement aux sollicitations extérieures

procproc proc proc

réseau

Envois asynchrones

Parvient-on vraiment à assurer du recouvrement ?

Processus A Processus B

Acquittement

MPI_Isend

MPI_recv

MPI_test

L’interface Madeleine

Principe

Madeleine

Interface de communication Efficace et portable

Double objectif Support de multiples paradigmes/modes Support de multiples réseaux simultanément

Proposition Programmation par « contrat »

Contrôle du niveau d’optimisation Transferts immédiats possibles

Statut Disponible sur BIP, SISCI, TCP et MPI. Portage en cours sur VIA

Construction des messages

Gestion des canaux (~ communicators) Choix explicite du dispositif physique

Interface

mad_begin_packing

mad_pack

mad_end_packing

mad_begin_unpacking

mad_unpack

mad_end_unpacking

Packing et Unpacking

Commandes : mad_pack (cnx, buffer, len, pack_mode, unpack_mode) mad_unpack (cnx, buffer, len, pack_mode,

unpack_mode)

Modes :Send_SAFER

Send_CHEAPER

Send_LATER

Receive_EXPRESS

Receive_CHEAPER

RPC efficaces avec Madeleine

LRPC, Migration

Madeleine

Gestion générique de tampons

Gestion des transmissions

BIP, SISCI, VIA, TCP, MPI

Emission : modes d’empaquetage

Version transmise

Pack

Modification

End_packing

Send_SAFER Send_LATER Send_CHEAPER

Réception : mode de déballage (1)

Unpack

Après Unpack

End_packing

Tampon

Données disponibles

RECV_EXPRESS

Réception : mode de déballage (2)

RECV_CHEAPER

Unpack

Après Unpack

End_packing

Tampon

Données disponibles ???

Données disponibles

Exemple

mad_end_unpacking(cnx);

send_CHEAPER,receive_CHEAPER);

mad_unpack(cnx, s, n,

s = malloc(n);

send_CHEAPER,receive_EXPRESS);

mad_unpack(cnx, &n, sizeof(int),

cnx = mad_begin_unpacking(channel);

p_mad_connection_t cnx;

char *s = NULL;

int n;

mad_pack(cnx, s, n,

send_CHEAPER, receive_CHEAPER);

mad_end_packing(cnx);

send_CHEAPER, receive_EXPRESS);

mad_pack(cnx, &n, sizeof(int),

n = strlen(s) + 1;

cnx = mad_begin_packing(channel, dest);

p_mad_connection_t cnx;

char *s = "Hello, World !";

int n;

Sending side Receiving side

Madeleine – structure

BMM1 BMMn

TM1 TMn

Network

Application

Generic BufferManagement

ModulesSwitch

Selection

BMM1 BMMm

TM1 TMn

Application

Switch

Selection

Specific Transmission Modules

Adaptativité

Sélection du mode de transmission adéquat

Interface

Gestion des

tampons

Gestionde

protocole

Pack

??

Implementation

Madeleine II a été portée sur : SISCI/SCI BIP/Myrinet MPI VIA TCP SBP

BIP/Myrinet

Latency: Madeleine II/BIP

0

2

4

6

8

10

12

0 64 128

Packet size (bytes)

Lat

ency

(µ

s)

Latency: Madeleine II/BIP

0

2

4

6

8

10

12

0 64 128

Packet size (bytes)

Lat

ency

(µ

s)

BIP/Myrinet

Bandwidth: Madeleine II/BIP

0

20

40

60

80

100

120

4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

Bandwidth: Madeleine II/BIP

0

20

40

60

80

100

120

4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

SISCI/SCI

Latency: Madeleine II/SCI

0123456789

10

0 64 128

Packet size (bytes)

Lat

ency

(µ

s)

Latency: Madeleine II/SCI

0123456789

10

0 64 128

Packet size (bytes)

Lat

ency

(µ

s)

SISCI/SCI

Bandwidth: Madeleine II/SCI

0

10

20

30

40

50

60

70

80

90

1 4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

4194

304

1,7E

+07

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

Bandwidth: Madeleine II/SCI

0

10

20

30

40

50

60

70

80

90

1 4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

4194

304

1,7E

+07

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

Quelques résultats

Latence 7 µs sur BIP/Myrinet 4 µs sur SISCI/SCI

Bande passante 125 Mo/s sur BIP/Myrinet 80 Mo/s sur SISCI/SCI

Migration (PM2) 24 µs sur SISCI/SCI 52 µs sur BIP/Myrinet

MPICH/Madeleine II

MPICH: general-purpose portable MPI implementation well-defined protocol interface Abstract Device

Madeleine: cluster-specific high-performance communication generic structure available on Gigabit networks highly optimized implementation

The best of both worlds! Madeleine as a MPICH device

MPICH/Madeleine II

MPI API

ADI

ProtocolInterface

Generic part (collective operations, context/group management, ...)

Generic ADI code, datatype management, request queues management

SMP_PLUG device

intra-node communication

CH_SELF device

self communication

CH_MAD device

inter-node communication

polling loopseager protocol rendez-vous-

protocol

Madeleine II

multi-protocol management

Fast-Ethernet SCI Myrinet

TCP SISCI BIP

Latency

Comparison: various MPI/SCI implementations

0

5

10

15

20

25

30

35

40

1 10 100 1000

Packet size (bytes)

Lat

ency

(µ

s)

SCI-MPICH

SCA-MPI

MPI/ MadII/ SCI


0

5

10

15

20

25

30

35

40

1 10 100 1000

Packet size (bytes)

Lat

ency

(µ

s)

SCI-MPICH

SCA-MPI

MPI/ MadII/ SCI

Bandwidth


0

10

20

30

40

50

60

70

80

1 4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

SCI-MPICH

SCA-MPI

MPI/ MadII/ SCI


0

10

20

30

40

50

60

70

80

1 4 16 64 256

1024

4096

1638

4

6553

6

2621

44

1048

576

Packet size (bytes)

Ban

dw

idth

(M

B/s

)

SCI-MPICH

SCA-MPI

MPI/ MadII/ SCI


Vers des communicationssur grappes de grappes…

Objectifs

Support des grappes de grappes Communications hétérogènes Transparence Efficacité du routage sur les machines

« passerelles » Minimisation des copies Maintien du débit par techniques de pipeline Utilisation des threads !

PC/MyrinetPC/SCI

Réseau rapide

PACX-MPI

2 nœuds sacrifiés pour les communications

Transparence pour l’application

Protocole TCP/IP entre les grappes

MPI MPI

TCP

Globus

Principe : Appel de Procédure à Distance

Librairie de communication : Nexus Multiprotocole Multithreading non nécessairement préemptif La passerelle est sacrifiée

Tout est à faire par l’utilisateur Pas de gestion explicite des grappes de

grappes

Pas adapté au problème

Madeleine II

Bibliothèque de communication Multiprotocole Canaux de communication

indépendants Un canal correspond à un adaptateur

réseau

Canal TCP

Canal TCP

Canal SCI

Structure interne

Couche générique de gestion de tampons

Couche de portabilité avec les protocoles

Réseau

Application

MGT1 MGTnMGT2

MT1 MTnMT2

Structure interne

MGT1 MGTn

MT1 MTn

Réseau

Application

Couche de

gestion de tampons

Couche de portabilité

Aiguillage

Sélection

MGT1 MGTn

MT1 MTn

Réseau

Application

Aiguillage

Sélection

Structure (suite)

Organisation des données Madeleine : données globales Driver : spécifique à un protocole Adapter : virtualisation d’une carte

réseau Channel : isolation des communications Connection : connexion point à point Link : virtualisation d’une méthode de

transfert

Ce qui manque

Utilisation de réseaux qui ne sont pas présents sur tous les nœuds

Envoi de messages entre des machines non directement reliées

SCI Myrinet

Intégration dans Madeleine

MTs : pas portable

MGTs : problèmes de conversion

Au-dessus : perte d’efficacité

Application

MGT1 MGT2 MGTn

MT1 MT2

Réseau

Solution retenue

MT générique entre les MTs et les MGTs

Pas de MGT au niveau de la passerelle

MT générique

MGT1 MGT2 MGTn

MT1 MT2

Réseau

Application

Canaux virtuels

Contiennent plusieurs canaux réels

Permettent de séparer les messages à retransmettre des messages normaux (canaux réels différents)

1 2 3 4

Canaux SCI

Canaux Myrinet

Canal spécial

Canal normal

Canal

virtuel

Réactivité et parallélisme

Retransmission des messages par des threads dédiés Une paire de threads par réseau

physique Mécanisme de pipeline

Réception des messages normaux sur la passerelle Pas d’informations à priori sur la

provenance Threads de scrutation

Principe de la passerelle

Application

Threads de

retransmission

Thread de scrutation

SCI

Myrinet

Tests de performances

Ping-pong entre 2 machines séparées par une passerelle

SCI Myrinet

321

Évaluation

SCI

BIP

BIP/SCI Avec une passerelle

Bande passante

80 Mo/s

116 Mo/s

41 Mo/s

Latence

5,3 μs

7,8 μs

32,5 μs


Intégration des threadset des communications

Progression des communications

Problème Comment assurer la progression des

communications ?

procproc proc proc

réseau

Scrutation et interruptions

La scrutation est nécessaire API réseau ne fournissant pas d’appels

bloquants OS ne fournissant pas “d’activations”

Problème Fréquence difficile à assurer Coûteux en présence de multiple “pollers ”

Les interruptions sont nécessaires Réactivité

Problème Outils de synchronisation “interrupt safe” ?

Support de l’ordonnanceur

Ordonnanceur = serveur de scrutation Choix de la méthode d’accès

(scrutation/intr.) Support pour la scrutation

Fréquence contrôlée Factorisation des scrutations multiples

Support pour les interruptions Utilisation possible des activations Verrous spécifiques « interrupt-safe »

Scrutation par l’ordonnanceur

Ordonnanceurdes threads

Création d’une catégoriede polling (ex: MPI), assignation d’une fréquence et enregistrement de callbacks.

Polling jobsqueue

MPI

MPI_IsendMarcel_poll

Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque.

MPI_IrecvMarcel_poll

callbackcallback

Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur...

Polling( )


L’environnement PM2

PM2 : architecture logicielle

Légende Marcel : noyau de processus légers Madeleine : module de communication

Marcel PM2 Madeleine

Architecture (grappes, machines parallèles)

Unix (~10 versions)

Interface de programmation (RPC, migration, allocation iso-adresse)

Régulation HPF, C* C++//, Java

Applications

PM2PM2

MICRO-PM2MARCEL MADELEINE

Structure de PM2

API : non-threaded RPC (“packs” Madeleine), thread create, API MarcelAPI : non-threaded RPC (“packs” Madeleine), thread create, API Marcel

API : LRPC avec stubs, migration iso-adresse, DSMAPI : LRPC avec stubs, migration iso-adresse, DSM

PM2 Intrinsics

Migration LRPC “ancien style”

Iso-addr

DSM-PM2

Console

API : MICRO PM2 + PM2 IntrinsicsAPI : MICRO PM2 + PM2 Intrinsics

Structure


Conclusion

Conclusion

Multithreading Exploitation efficace des architectures SMP Contrôle fin de l’ordonnancement

Conditionné par les fonctionnalités du système

Multithreading distribué Communications de type RPC

Support spécifique nécessaire

Intégration des threads et des communications Délicate !! Mieux maîtrisée si fonctionnement coopératif

Supports d’exécution pour grappes de machines SMP

Documents

Transcript of Supports d’exécution pour grappes de machines SMP