Supports d’exécution pour grappes de machines SMP Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon

Plan Multithreading Exploitation efficace des machines SMP 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…

Introduction et rappels 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” Espace utilisateur Processus Processus Processus Ordonnanceur Noyau processeur

Threads : Motivations Difficulté de programmation Performances 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 key stroke; getKey(); } for (;;) { wait for network msg; getNetworkMsg(); } 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 ? client serveur OS OS

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 Threads Verrous 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)

Partage mémoire efficace 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 ; charger Inc r1 ; incrémenter Mov $r1, @glob ; enregistrer Mov @glob, $r1 Inc r1 Mov @glob, $r1 Inc r1 Mov $r1, @glob … Mov $r1, @glob Mov @glob, $r1 Inc r1 Mov @glob, $r1 Inc r1 Mov $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 est exé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()) #else extern 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 efficace des machines SMP Quelle catégorie de threads ?

Multithreading utilisateur Deux ordonnanceurs indépendants : User Space Process Scheduler Scheduler OS Kernel processor

Multithreading noyau Un seul ordonnanceur : User Space Process Scheduler OS Kernel processor

Multithreading mixte Deux ordonnanceurs coopérants User Space Process Scheduler Scheduler OS Kernel processor Note: Quid des appels systèmes bloquants ?

Performances Athlon 1.4GHz, DDR2100 Alpha 500MHz 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

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 efficace des machines SMP Scheduler Activations

Recouvrement des E/S Au lieu de …on voudrait : Temps CPU perdu CPU utilisé syscall Espace utilisateur I/O request interrupt Espace noyau Matériel …on voudrait : Espace noyau Espace utilisateur Matériel

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

Illustration du principe Process new

Illustration du principe Process new

Illustration du principe Déroulement d’un appel bloquant… Process Appel système bloquant

Illustration du principe Déroulement d’un appel bloquant… Process New + blocked

Illustration du principe Déroulement d’un appel bloquant… Process Appel terminé

Illustration du principe Déroulement d’un appel bloquant… Process Unblocked

Illustration du principe Déroulement d’un appel bloquant… 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… Problèmes 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 sp blocking syscall sp registers activation

Coût des appels bloquants thread sp thread activation sp Clock int. sp registers registers sp sp blocked activation

Coût des appels bloquants thread sp thread activation sp registers sp registers registers sp activation

Coût des appels bloquants thread sp thread activation sp registers registers registers sp

Coût des appels bloquants thread sp thread activation jb sp registers registers sys_restart

Coût des appels bloquants thread sp thread activation registers

Un modèle revisité Contexte = calcul haute performance Propositions 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)

Multithreading Distribué Principe et Enjeux

Principe Introduire les threads dans les applications distribuées proc proc 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) !

Multithreading Distribué 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 Pthreads + extensions Pthreads A0, Chant Pthreads + extensions Rthreads Pthreads DSM-threads Appels de procédure à distance « threadés » A0, Nexus, PM2

Threads communicants Principe Exemples 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 Exemples 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

Multithreading Distribué L’environnement PM2

Projet PM2 (95-xx) Objectif ambitieux : virtualisation Propositions 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 PM2 PM2 LRPC Différentes déclinaisons Synchrone Attente différée Asynchrone 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

Multithreading Distribué 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, … Memory TX-ring DMA TX reg RX reg PCI Bus Network PCI Bridge Packet Interface NIC

Myrinet Produit Myricom (C. Seitz) Carte programmable Réseau commuté, routage wormhole Carte programmable Protocoles de transmission « intelligents » Stratégie adaptée à la taille des messages Déclenchement d’interruptions DMA SRAM PCI Bus Packet Interface Network PCI Bridge RISC LANai 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

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 Réseau Processus B Message Entête Données Préparation mémoire Acquittement DMA

Et la réactivité alors ? Problèmes Assurer la progression des communications asynchrones Réagir rapidement aux sollicitations extérieures proc proc proc proc réseau

Envois asynchrones Parvient-on vraiment à assurer du recouvrement ? MPI_Isend MPI_recv Acquittement MPI_test Processus A Processus B

L’interface Madeleine Principe

Madeleine Interface de communication Double objectif Proposition 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

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

Packing et Unpacking Commandes : Modes : 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 Send_SAFER Send_LATER Send_CHEAPER Pack Modification End_packing ? Version transmise

Réception : mode de déballage (1) RECV_EXPRESS Unpack Tampon Après Unpack Données disponibles End_packing

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

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Exemple Sending side Receiving side int n; int n; char *s = "Hello, World !"; char *s = NULL; p_mad_connection_t cnx; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); cnx = mad_begin_unpacking(channel); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), mad_unpack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_pack(cnx, s, n, mad_unpack(cnx, s, n, send_CHEAPER, receive_CHEAPER); send_CHEAPER,receive_CHEAPER); mad_end_packing(cnx); mad_end_unpacking(cnx);

Generic Buffer Management Modules Madeleine – structure Application Application Generic Buffer Management Modules Switch Switch BMM1 BMMn BMM1 BMMm Specific Transmission Modules Selection Selection TM1 TMn TM1 TMn Network

? Adaptativité Sélection du mode de transmission adéquat Interface Pack Gestion des tampons ? Gestion de protocole

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

BIP/Myrinet

BIP/Myrinet

SISCI/SCI

SISCI/SCI

Quelques résultats Latence Bande passante Migration (PM2) 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

multi-protocol management MPICH/Madeleine II MPI API Generic part (collective operations, context/group management, ...) ADI Generic ADI code, datatype management, request queues management Protocol Interface 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

Latency

Bandwidth

Multithreading Distribué Vers des communications sur grappes de grappes…

Objectifs Support des grappes de grappes Réseau rapide 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/SCI PC/Myrinet

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 SCI Canal TCP Canal TCP

Structure interne Couche générique de gestion de tampons Couche de portabilité avec les protocoles Application MGT1 MGTn MGT2 MT1 MTn MT2 Réseau

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

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 Application MGT1 MGT2 MGTn MT générique MT1 MT2 Réseau

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

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 Thread de scrutation Threads de retransmission Myrinet SCI

Tests de performances Ping-pong entre 2 machines séparées par une passerelle 1 2 3 SCI Myrinet

Évaluation

Multithreading Distribué Intégration des threads et des communications

Progression des communications Problème Comment assurer la progression des communications ? proc proc 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é 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  Création d’une catégorie de polling (ex: MPI), assignation d’une fréquence et enregistrement de callbacks. Polling jobs queue  Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque. MPI_Isend Marcel_poll MPI_Irecv Marcel_poll MPI Polling( ) callback callback  Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur... Ordonnanceur des threads

Multithreading Distribué L’environnement PM2

PM2 : architecture logicielle Applications Régulation HPF, C* 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

Structure de PM2 Structure PM2 PM2 Intrinsics MICRO-PM2 MARCEL API : MICRO PM2 + PM2 Intrinsics PM2 API : LRPC avec stubs, migration iso-adresse, DSM PM2 Intrinsics Console Migration DSM-PM2 LRPC “ancien style” API : non-threaded RPC (“packs” Madeleine), thread create, API Marcel MICRO-PM2 MARCEL MADELEINE Iso-addr

Multithreading Distribué Conclusion

Conclusion Multithreading Multithreading distribué 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