Supports d

1
Supports dexécution pour grappes de machines SMP

• Raymond Namyst
• Projet INRIA ReMaP
• LIP, ENS Lyon

2
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

3
Multithreading
Introduction et rappels
4
Rappel les processus lourds

• Caractéristiques
• Entité active directement supportée par lOS
• Flot dexécution
• Espace dadressage privé
• Ressources systèmes
• Exécution séquentielle
• Coût de gestion élevé
• Allocation des ressources
• Appels systèmes

5
Processus lourds

• Ressources noyau données utilisateur

Espace utilisateur
Processus
Processus
Processus
Ordonnanceur
Noyau
6
Threads Motivations

• Difficulté de programmation
• Fil dexé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 dE/S difficiles

7
Simplicité de programmation

• Objectif
• Mener plusieurs activités indépendantes au sein
  dun processus
• Exemples
• Simulations
• Serveurs de fichiers
• Systèmes dexploitation (!)
• Seule solution (?)
• Automate à états finis implanté  à la main 
• (sauvegardes détats)

8
Structure dun OS monolytique

• Exemple
• Séquence infinie dopérations courtes
• Ordre et fréquence des scrutations ?

for () if(networkMsgIn()) getNetworkMsg() i
f(kbdReady()) getKey() if(diskBlockReady())
handleDiskBlock()
9
Systèmes multiprogrammés

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

for () wait for key stroke getKey()
for () wait for network msg getNetworkMsg()

for () wait for disk block handleDiskBlock(
)
10
Processus serveur classique

• Sérialisation des requêtes
• Pas de recouvrement des E/S
• Exploitation SMP délicate
• Prise en compte de priorités ?

client
serveur
OS
OS
11
Sur lefficacité des E/S

• Caractéristiques du serveur de fichiers
• Tps de traitement dune requête 15ms
• Tps supplémentaire pour laccè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)

12
Les processus légers

• Principe
• Détacher flot dexécution et ressources
• Introduits dans divers langages systèmes
• Programmation concurrente
• Recouvrement des E/S
• Exploitation des architectures SMP

thread
ressources
13
Caractéristiques de base

• Thread pile contexte
• Partage de ressources
• Code, tas, espace dadressage
• Fichiers ouverts
• Etc.
• Opérations de base performantes
• Création, destruction
• Synchronisation, commutation de contextes
• Création dun processus léger
• Adresse de fonction à exécuter paramètres

14
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 dune activité (processus, thread)
  synchronisation (terminaison de lactivité)

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
15
Repères historiques

• Lancê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) -gt DecThread -gt PThread (90)
• Chorus, Solaris (87), winNT, IRIX, Linux, etc.
• Les threads dans les langages
• Ada (83), Java, etc.
• C //, Eiffel //, etc.

16
Multithreading
Premier contact
17
Linterface 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.

18
Exemple création

• Création dun nouveau thread
• Éventuels attributs dans la structure attr
• Exécution de start_func avec le paramètre arg
• pid est lidentificateur du thread créé

int pthread_create( pthread_t pid, pthread_att
r_t attr, void (start_func)(void
), void arg)
19
Attente de fin dexé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)
20
 Hello World! 

• include ltstdio.hgt
• include ltpthread.hgt
• 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

21
Attributs

• Ensemble fixé de caractéristiques
• Utilisé à linitialisation
• Threads, verrous, variables de condition, etc.
• Threads
• Priorité
• Pile taille, emplacement
• Détaché oui/non
• Type dordonnancement
• Verrous
• Inversion de priorités, récursivité

22
Attributs exemple

• include ltstdio.hgt
• include ltpthread.hgt
• 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)

23
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,
1281024) pthread_create(NULL, attr, func,
NULL)
24
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)

25
Multithreading
Partage mémoire efficace
26
Les threads et la mémoire

• Chaque thread possède sa propre pile
• Variables locales  privées  (? visibilité)
• Les threads partagent lespace dadressage
• Variables globales
• Tas (malloc)
• Variables locales (piles) également !
• Intérêt
• Communications par pointeurs !
• Parallélisation de programmes séquentiels aisée ?

27
Problèmes de réentrance

• Exemple simple

int glob 0 void inc(void arg) int
i for(i0 ilt100 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 ?
28
Explication

• glob nest pas forcément une opération atomique
• Scénario dexécution concurrente par 2 threads

Mov _at_glob, r1 charger Inc r1
incrémenter Mov r1, _at_glob enregistrer
Mov r1, _at_glob
29
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(i0
ilt100 i) pthread_mutex_lock(mutex) glob
pthread_mutex_unlock(mutex)
30
Code réentrant

• code demeurant correct lorsquil est exécuté
  simultanément par plusieurs threads
• Exemples typiques
• Fonction nutilisant que des variables locales
• Code protégé par un verrou
• Quid du code que lon écrit pas soi-même ?
• Malloc, free, , la bibliothéque standard
• Fonctions  MT-safe 
• Option D_REENTRANT
• Certains prototypes changent

31
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 lordre des écritures
• Primitives de synchronisation
• Agissent comme des  barrières mémoire 

32
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()
33
Variables spécifiques

• Principe
• Variable accessible à partir dune clé
• Allocation globale (souvent à linitialisation)
• pthread_setspecific(clé, valeur)
• pthread_getspecific(clé) -gt valeur
• Exemple la variable errno
• Fichier errno.h

ifdef _REENTRANT define errno
(__errno_location()) else extern int
errno endif
34
Multithreading
Quelques idées reçues ?
35
A propos defficacité

• 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

36
Exploitation efficacedes machines SMP
Quelle catégorie de threads ?
37
Multithreading utilisateur

• Deux ordonnanceurs indépendants

User Space
OS Kernel
38
Multithreading noyau

• Un seul ordonnanceur

User Space
OS Kernel
39
Multithreading mixte

• Deux ordonnanceurs coopérants

User Space
OS Kernel
Note Quid des appels systèmes bloquants ?
40
Performances

• Athlon 1.4GHz, DDR2100

Opération Unix (fork) pthread clone Marcel SMP Marcel 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 500MHz

Opération Unix (fork) pthread clone Marcel SMP Marcel 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
41
E/S et ordonnancement

• Threads noyaux OK
• Threads utilisateurs
• Appel bloquant -gt blocage du processus entier
• Threads mixtes
• Idem au bout dun certain nombre !
• Solutions ?
• Appels toujours non-bloquants (polling)
• Appels effectués par des threads dédiés
• Support système spécifique

42
Exploitation efficacedes machines SMP
Scheduler Activations
43
Recouvrement des E/S

• Au lieu de

Espace utilisateur
Espace noyau
Matériel
44
Scheduler Activations

• Introduit par Anderson et al. 91
• Idée la coopération entre les deux
  ordonnanceurs est bidirectionnelle
• Lordonnanceur utilisateur utilise des appels
  systèmes
• Lordonnanceur noyau utilise des upcalls!
• Upcalls
• Informe lapplication des événements noyaux
• Activations
• Autant dactivations en exécution que de
  processeurs
• Contrôlées par le noyau
• Principe mis en œuvre dans Solaris

45
Illustration du principe
Process
User scheduler
46
Illustration du principe
Process
47
Illustration du principe
Process
48
Illustration du principe

• Déroulement dun appel bloquant

Process
49
Illustration du principe

• Déroulement dun appel bloquant

Process
50
Illustration du principe

• Déroulement dun appel bloquant

Process
51
Illustration du principe

• Déroulement dun appel bloquant

Process
52
Illustration du principe

• Déroulement dun appel bloquant

Process
53
Difficultés de mise en œuvre

• Retour dun 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
• Lordonnanceur de niveau utilisateur doit se
  prémunir contre ces interruptions intempestives
• Le coût est prohibitif !

54
Coût de la préemption

• Lorsquune activation est préemptée
• Lordonnanceur 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 nimporte quand
• Changements de contexte asynchrones
• Nécessité de protéger beaucoup de code e.g. la
  fonction thread_yield() ...

55
Coût des appels bloquants
thread
activation
56
Coût des appels bloquants
thread
activation
57
Coût des appels bloquants
thread
activation
58
Coût des appels bloquants
thread
59
Coût des appels bloquants
thread
60
Coût des appels bloquants
thread
61
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 dune pile par processeur
• Implantation
• Linux 2.2.x
• Bibliothèque de threads Marcel

62
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 dune 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

63
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

64
Performance (PC)
65
MultithreadingDistribué
Principe et Enjeux
66
Principe

• Introduire les threads dans les applications
  distribuées

réseau
67
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

68
Intérêts

• Apports des threads
• Virtualisation de larchitecture
• 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 lapplication
  (plug-ins) !

69
MultithreadingDistribué
Quel modèle de programmation ?
70
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 dintégration spécifique -gt non
  réutilisable

71
Approche intégrée

• Threads communicants
• A0, Chant
• Pthreads extensions
• Rthreads
• Pthreads
• DSM-threads
• Appels de procédure à distance  threadés 
• A0, Nexus, PM2

72
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)

73
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)

74
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)

75
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

76
MultithreadingDistribué
Lenvironnement PM2
77
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

78
Appel de procédure à distance
PM2
PM2

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

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

79
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

80
MultithreadingDistribué
Communications dans un environnement multithreads
81
Communications performantes

• Comment exploiter les réseaux rapides ?
• Faible latence
• Quelques microsecondes
• Bande passante élevée
• De lordre 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

82
Ethernet

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

Memory
TX-ring
DMA
TX reg RX reg
Network
PCI Bus
PCI Bridge
Packet Interface
NIC
83
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 dinterruptions

DMA
SRAM
Network
Packet Interface
PCI Bus
PCI Bridge
RISC
LANai
NIC
84
Interface efficace pour Myrinet

• BIP Basic Interface for Parallelism
• Loic Prylli (ReMaP) en 1997
• Performances
• Latence ? 5 ?s, bande passante gt 125 Mo/s
• Fonctionnalités réduites au minimum
• Messages courts recopiés à larrivée
• Messages longs mode zéro-copie (RDV)
• Contrôle de flux minimal
• Matériel (msgs évaporés au dela de 50ms)

85
SCI Scalable Coherent Interface

• Réseau à capacité dadressage
• 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 !)

86
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 nest pas (forcément)
  interrompu

87
Ce quil 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é ???

88
Contexte et motivations
Concilier efficacité et portabilité
89
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 ?

90
Transmissions zéro-copie
Processus A
Processus B
Réseau
91
Et la réactivité alors ?

• Problèmes
• Assurer la progression des communications
  asynchrones
• Réagir rapidement aux sollicitations extérieures

réseau
92
Envois asynchrones

• Parvient-on vraiment à assurer du recouvrement ?

MPI_Isend
MPI_recv
MPI_test
Processus A
Processus B
93
Linterface Madeleine
Principe
94
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 doptimisation
• Transferts immédiats possibles
• Statut
• Disponible sur BIP, SISCI, TCP et MPI.
• Portage en cours sur VIA

95
Interface

• Construction des messages
• Gestion des canaux ( communicators)
• Choix explicite du dispositif physique

mad_begin_packing
mad_pack
mad_end_packing
mad_begin_unpacking
mad_unpack
mad_end_unpacking
96
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
97
RPC efficaces avec Madeleine
LRPC, Migration
Madeleine
Gestion générique de tampons
Gestion des transmissions
BIP, SISCI, VIA, TCP, MPI
98
Emission modes dempaquetage
Send_SAFER
Send_LATER
Send_CHEAPER
Pack
Modification
?
End_packing
Version transmise
99
Réception mode de déballage (1)

• RECV_EXPRESS

Unpack
Tampon
Après Unpack
Données disponibles
End_packing
100
Réception mode de déballage (2)

• RECV_CHEAPER

Unpack
Tampon
Après Unpack
Données disponibles ???
End_packing
Données disponibles
101
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
102
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
103
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
104
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
105
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
106
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
107
Exemple
Sending side
Receiving side
int n
int n
char s NULL
char s "Hello, World !"
p_mad_connection_t cnx
p_mad_connection_t cnx
cnx mad_begin_unpacking(channel)
cnx mad_begin_packing(channel, dest)
n strlen(s) 1
mad_unpack(cnx, n, sizeof(int),
mad_pack(cnx, n, sizeof(int),
send_CHEAPER,receive_EXPRESS)
send_CHEAPER, receive_EXPRESS)
s malloc(n)
mad_unpack(cnx, s, n,
mad_pack(cnx, s, n,
send_CHEAPER,receive_CHEAPER)
send_CHEAPER, receive_CHEAPER)
mad_end_unpacking(cnx)
mad_end_packing(cnx)
108
Madeleine structure
Application
Application
Generic BufferManagementModules
Switch
Switch
BMM1
BMMn
BMM1
BMMm
Specific Transmission Modules
Selection
Selection
TM1
TMn
TM1
TMn
Network
109
Adaptativité

• Sélection du mode de transmission adéquat

Interface
Pack
Gestion des tampons
?
Gestion de protocole
110
Implementation

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

111
BIP/Myrinet
112
BIP/Myrinet
113
SISCI/SCI
114
SISCI/SCI
115
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

116
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

117
MPICH/Madeleine II
MPI API
Generic part (collective operations,
context/group management, ...)
ADI
Generic ADI code, datatype management, request
queues management
ProtocolInterface
CH_MAD device inter-node communication polling
loops eager protocol rendez-vous-protocol
SMP_PLUG device intra-node communication
CH_SELF device self communication
Madeleine II multi-protocol management
TCP
SISCI
BIP
Fast-Ethernet
SCI
Myrinet
118
Latency
119
Bandwidth
120
MultithreadingDistribué
Vers des communicationssur grappes de grappes
121
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 !

Réseau rapide
PC/Myrinet
122
PACX-MPI

• 2 nœuds sacrifiés pour les communications
• Transparence pour lapplication
• Protocole TCP/IP entre les grappes

MPI
MPI
TCP
123
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 lutilisateur
• Pas de gestion explicite des grappes de grappes
• Pas adapté au problème

124
Madeleine II

• Bibliothèque de communication
• Multiprotocole
• Canaux de communication indépendants
• Un canal correspond à un adaptateur réseau

Canal SCI
Canal TCP
Canal TCP
125
Structure interne

• Couche générique de gestion de tampons
• Couche de portabilité avec les protocoles

Application
Réseau
126
Structure interne
Application
Application
Couche de gestion de tampons
Aiguillage
Aiguillage
MGT1
MGTn
MGT1
MGTn
Sélection
Sélection
Couche de portabilité
MT1
MTn
MT1
MTn
Réseau
Réseau
127
Structure (suite)

• Organisation des données
• Madeleine données globales
• Driver spécifique à un protocole
• Adapter virtualisation dune carte réseau
• Channel isolation des communications
• Connection connexion point à point
• Link virtualisation dune méthode de transfert

128
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

Myrinet
SCI
129
Intégration dans Madeleine

• MTs pas portable
• MGTs problèmes de conversion
• Au-dessus perte defficacité

Application
MGT1
MGT2
MGTn
MT1
MT2
Réseau
130
Solution retenue

• MT générique entre les MTs et les MGTs
• Pas de MGT au niveau de la passerelle

Application
MGT1
MGT2
MGTn
MT générique
MT1
MT2
Réseau
131
Canaux virtuels

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

Canal virtuel
Canaux SCI
Canaux Myrinet
1
2
3
4
Canal spécial
Canal normal
132
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 dinformations à priori sur la provenance
• Threads de scrutation

133
Principe de la passerelle
Application
Thread de scrutation
Threads de retransmission
Myrinet
SCI
134
Tests de performances

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

3
2
1
Myrinet
SCI
135
Évaluation
136
MultithreadingDistribué
Intégration des threadset des communications
137
Progression des communications

• Problème
• Comment assurer la progression des communications
  ?

réseau
138
Scrutation et interruptions

• La scrutation est nécessaire
• API réseau ne fournissant pas dappels bloquants
• OS ne fournissant pas dactivations
• 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 ?

139
Support de lordonnanceur

• Ordonnanceur serveur de scrutation
• Choix de la méthode daccè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 

140
Scrutation par lordonnanceur
? Création dune catégoriede polling (ex MPI),
assignation dune fréquence et enregistrement de
callbacks.
Polling jobsqueue
? Régulièrement, lordonnanceur appelle la
fonction de scrutation définie par
lutilisateur...
Ordonnanceur
des threads
141
MultithreadingDistribué
Lenvironnement PM2
142
PM2 architecture logicielle
Applications
HPF, C
Régulation
C//, Java
Interface de programmation (RPC, migration,
allocation iso-adresse)
Marcel PM2
Madeleine
Unix (10 versions)
Architecture (grappes, machines parallèles)

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

143
Structure de PM2

• Structure

API MICRO PM2 PM2 Intrinsics
API LRPC avec stubs, migration iso-adresse, DSM
Console
Migration
LRPC ancien style
DSM-PM2
API non-threaded RPC (packs Madeleine),
thread create, API Marcel
Iso-addr
144
MultithreadingDistribué
Conclusion
145
Conclusion

• Multithreading
• Exploitation efficace des architectures SMP
• Contrôle fin de lordonnancement
• 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