La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Supports dexécution pour grappes de machines SMP Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon.

Présentations similaires


Présentation au sujet: "Supports dexécution pour grappes de machines SMP Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon."— Transcription de la présentation:

1 Supports dexécution pour grappes de machines SMP Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon

2 Plan u Multithreading Introduction et rappels u Exploitation efficace des machines SMP Ordonnancement mixte, activations u Multithreading distribué Modèles de programmation Intégration des threads et des communications u Conclusion Pas si simple…

3 Multithreading Introduction et rappels

4 Rappel : les processus lourds u Caractéristiques Entité active directement supportée par lOS Ù Flot dexécution Ù Espace dadressage privé Ù Ressources systèmes Exécution séquentielle u Coût de gestion élevé Allocation des ressources Appels systèmes

5 Processus lourds u Ressources noyau + données utilisateur processeur Noyau Processus Ordonnanceur Espace utilisateur Processus

6 Threads : Motivations u Difficulté de programmation Fil dexécution unique une seule chose à la fois ! Partage de données laborieux Réactivité aux sollicitations externes u Performances Opérations de base coûteuses Recouvrement des opérations dE/S difficiles

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

8 Structure dun OS monolytique u Exemple Séquence infinie dopérations courtes Ordre et fréquence des scrutations ? for (;;) { if(networkMsgIn()) getNetworkMsg(); if(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 network msg; getNetworkMsg(); } for (;;) { wait for key stroke; getKey(); } for (;;) { wait for disk block; handleDiskBlock(); }

10 Processus serveur classique u Sérialisation des requêtes Pas de recouvrement des E/S Exploitation SMP délicate Prise en compte de priorités ? OS clientserveur

11 Sur lefficacité des E/S u 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) u Débit sans/avec recouvrement des E/S Sans recouvrement Ù 25 requêtes/seconde Avec recouvrement Ù requêtes/seconde (+33%)

12 Les processus légers u Principe Détacher flot dexécution et ressources u Introduits dans divers langages & systèmes Programmation concurrente Recouvrement des E/S Exploitation des architectures SMP thread ressources

13 Caractéristiques de base u Thread = pile + contexte u Partage de ressources Ù Code, tas, … : espace dadressage Ù Fichiers ouverts Ù Etc. u Opérations de base performantes Ù Création, destruction Ù Synchronisation, commutation de contextes u Création dun processus léger Adresse de fonction à exécuter + paramètres

14 Performance des threads u Opérations critiques Création/destruction (gestion mémoire) Changement de contexte (temps-partagé) Synchronisation (mode utilisateur) u Programme dévaluation Création dune activité (processus, thread) + synchronisation (terminaison de lactivité) OS/ProcesseurProcessusThread noyauThread utilisateurPM2 Linux 2.2/PII Solaris 2.7/PII

15 Repères historiques u Lancêtre : les coroutines Entrelacement explicite des exécutions Langages : Simula (67), Modula2 (82) Primitives clés : create + resume u Les threads dans les systèmes Ù Cthread (Mach) -> DecThread -> PThread (~90) Ù Chorus, Solaris (87), winNT, IRIX, Linux, etc. u Les threads dans les langages Ù Ada (83), Java, etc. Ù C++ //, Eiffel //, etc.

16 Multithreading Premier contact

17 Linterface POSIX-Threads u Interface de programmation standard pour Unix Portabilité des applications Solaris, IRIX, HP-UX, Linux, etc. u 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_attr_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 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 u Ensemble fixé de caractéristiques Utilisé à linitialisation Threads, verrous, variables de condition, etc. u Threads Ù Priorité Ù Pile : taille, emplacement Ù Détaché : oui/non Ù Type dordonnancement u Verrous Ù Inversion de priorités, récursivité

22 Attributs : exemple #include 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, 128*1024 ); pthread_create( NULL, &attr, func, NULL );

24 Le standard OpenMP u Interface pour écrire des applications multithreads portables (sur SMP) Directives de compilation (C, C++, Fortran) + routines Objectif = simplicité + portabilité Constructeurs + fabricants de logiciels + etc. u 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 u Chaque thread possède sa propre pile Variables locales « privées » ( visibilité) u Les threads partagent lespace dadressage Variables globales Tas (malloc) Variables locales (piles) également ! u Intérêt Communications par pointeurs ! Parallélisation de programmes séquentiels aisée ?

27 Problèmes de réentrance u 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 ?

28 Explication glob++ nest pas forcément une opération atomique Scénario dexécution concurrente par 2 threads : $r1; charger Inc r1; incrémenter Mov enregistrer $r1 Inc r1 $r1 Inc r1 Mov … Mov $r1 Inc r1 $r1 Inc r1 Mov … Mov

29 Outils pour la synchronisation u Exclusion mutuelle : les verrous u 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); }

30 Code réentrant u «code demeurant correct lorsquil est exécuté simultanément par plusieurs threads » u Exemples typiques Fonction nutilisant que des variables locales Code protégé par un verrou u 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. u 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 u Primitives de synchronisation Agissent comme des « barrières mémoire »

32 Variables spécifiques u 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 u Principe Variable accessible à partir dune clé Allocation globale (souvent à linitialisation) Ù pthread_setspecific(clé, valeur) Ù pthread_getspecific(clé) -> valeur u 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é… u Les threads sont-ils toujours meilleurs que MPI sur architectures SMP ? u Approche « processus communicants » Communications pénalisantes (copies) Surcoût en utilisation de ressources Recouvrement plus difficile u Approche « processus légers » Synchronisations additionnelles Accès aux variables spécifiques coûteux

36 Exploitation efficace des machines SMP Quelle catégorie de threads ?

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

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

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

40 Performances u Athlon 1.4GHz, DDR2100 OpérationUnix (fork) pthreadcloneMarcel SMP Marcel mono Chgt contexte600 ns370 ns350 ns180 ns65 ns Création80 us35 us14 us1.7 us0.82 us u Alpha 500MHz OpérationUnix (fork) pthreadcloneMarcel SMP Marcel mono Chgt contexte1.750 us1.740 us1.7 us815 ns560 ns Création640 us190 us90 us8 us4 us

41 E/S et ordonnancement u Threads noyaux : OK u Threads utilisateurs Appel bloquant -> blocage du processus entier u Threads mixtes Idem au bout dun certain nombre ! u Solutions ? Appels toujours non-bloquants (polling) Appels effectués par des threads dédiés Support système spécifique

42 Exploitation efficace des machines SMP Scheduler Activations

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

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

45 Illustration du principe Process User scheduler

46 Illustration du principe Process new

47 Illustration du principe Process new

48 Illustration du principe u Déroulement dun appel bloquant… Process Appel système bloquant

49 Illustration du principe u Déroulement dun appel bloquant… Process New + blocked

50 Illustration du principe u Déroulement dun appel bloquant… Process Appel terminé

51 Illustration du principe u Déroulement dun appel bloquant… Process Unblocked

52 Illustration du principe u Déroulement dun appel bloquant… Process

53 Difficultés de mise en œuvre u Retour dun appel bloquant Un « unblock upcall » nécessite deux appels systèmes supplémentaires… La généricité coûte cher !! u 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 u 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 u 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 blocking syscall sp registers sp activation

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

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

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

59 Coût des appels bloquants thread sp thread activation jbsp registers sys_restart

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

61 Un modèle revisité u Contexte = calcul haute performance Une application // à la fois sur la grappe Optimisations pour ce cas de figure Ù Les activations perdent rarement le processeur u Propositions Suppression des évènements « preempt » Utilisation dune pile par processeur u Implantation Linux 2.2.x Bibliothèque de threads Marcel

62 A propos de réactivité… u Problèmes liés aux évènements « unblock » Coût important, réactivité non-garantie u 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 u Parties du noyau modifiées schedule(), do_fork() and do_exit() Ù Implantation des transitions task_struct structure Ù Nouveaux champs (état des activations, etc.) u 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 Multithreading Distribué Principe et Enjeux

66 Principe u Introduire les threads dans les applications distribuées proc réseau

67 Enjeux u 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 u 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 Multithreading Distribué Quel modèle de programmation ?

70 Approche par juxtaposition u Principe : pas de modèle ! Simplement utiliser conjointement Ù Une bibliothèque de communication (ex: MPI) Ù Une bibliothèque de multithreading u Problèmes Conceptuels Ù Pas de visibilité globale des threads Ù Sémantique des communications ? Techniques Ù Compatibilité entre les bibliothèques Ù Travail dintégration spécifique -> non réutilisable

71 Approche intégrée u Threads communicants A0, Chant u Pthreads + extensions Rthreads u Pthreads DSM-threads u Appels de procédure à distance « threadés » A0, Nexus, PM2

72 Threads communicants u Principe Envoi de message entre threads Ù Modèle « MPI-like » Ù Modèle « Acteurs » Nommage Ù Nommage global des threads Ù Ports de communication u Exemples Chant (M. Haines, ICASE) Athapascan-0b (J. Briat, INRIA Grenoble)

73 Modèle Pthreads étendu u Principe Threads + primitives étendues Ù Create/Join à distance Ù Synchronisations distribuées Particularités Ù Nommage global des threads Ù Restriction du modèle Pthreads u Exemples Chant (M.Haines, ICASE), Rthreads (M. Zahn, Allemagne)

74 Modèle Pthreads distribué u 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 u Exemple DSM-Threads (F. Mueller, Berlin)

75 Modèle dérivé des RPC u 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 u Exemples Nexus (I. Foster, Argonne), PM2

76 Multithreading Distribué Lenvironnement PM2

77 Projet PM2 (95-xx) uObjectif 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 uPropositions 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 uDifférentes déclinaisons Synchrone Attente différée Asynchrone PM 2 LRPC uNos concurrents... Nexus : RSR Athapascan : appels de service

79 Mobilité des activités uMigration de processus légers PM 2 uPourquoi ? Régulation de charge Localité des données uComment ? Transfert du contexte Programmes SPMD

80 Multithreading Distribué Communications dans un environnement multithreads

81 Communications performantes u Comment exploiter les réseaux rapides ? Faible latence Ù Quelques microsecondes Bande passante élevée Ù De lordre du Gb/s u 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 u Cartes passives (sauf Giga-Ethernet) Interfaces : TCP, SBP, GAMMA, VIA, … Network TX reg RX reg Packet Interface PCI Bridge PCI Bridge PCI Bus DMA Memory TX-ring NIC

83 Myrinet u Produit Myricom (C. Seitz) Réseau commuté, routage wormhole u Carte programmable Protocoles de transmission « intelligents » Ù Stratégie adaptée à la taille des messages Ù Déclenchement dinterruptions Network RISC Packet Interface DMA PCI Bridge PCI Bridge PCI Bus LANai SRAM NIC

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

85 SCI : Scalable Coherent Interface u Réseau à capacité dadressage Normalisé par IEEE en 1993 Principal constructeur : Dolphin ICS u Principe Accés mémoire distants Ù Implicites (après projection) Ù Explicites (remote DMA) Support matériel pour une MVP (?) u Performances Ecriture 2 s, lecture 4 s Bande passante 85 Mo/s (difficilement !)

86 Adressage à distance u Projections effectués par le pilote (SISCI) Zones de mémoire physiques souvent spécifiques u Accès mémoire effectués par le processeur Le processeur distant nest pas (forcément) interrompu

87 Ce quil faut retenir u 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… u Implantations efficaces existantes Ù MPICH/BIP, MPICH/SISCI, etc. u 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 BRéseau Préparation mémoire Acquittement Message Entête Données DMA

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

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

93 Linterface Madeleine Principe

94 Madeleine u Interface de communication Efficace et portable u Double objectif Support de multiples paradigmes/modes Support de multiples réseaux simultanément u Proposition Programmation par « contrat » Ù Contrôle du niveau doptimisation Ù Transferts immédiats possibles u Statut Disponible sur BIP, SISCI, TCP et MPI. Portage en cours sur VIA

95 u Construction des messages u 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

96 Packing et Unpacking u Commandes : mad_pack (cnx, buffer, len, pack_mode, unpack_mode) mad_unpack (cnx, buffer, len, pack_mode, unpack_mode) u 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 Version transmise Pack Modification End_packing Send_SAFERSend_LATERSend_CHEAPER

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

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

101 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 sideReceiving side

102 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 sideReceiving side

103 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 sideReceiving side

104 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 sideReceiving side

105 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 sideReceiving side

106 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 sideReceiving side

107 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 sideReceiving side

108 Madeleine – structure BMM 1 BMM n TM 1 TM n Network Application Generic Buffer Management Modules Switch Selection BMM 1 BMM m TM 1 TM n Application Switch Selection Specific Transmission Modules

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

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

111 BIP/Myrinet

112

113 SISCI/SCI

114

115 Quelques résultats u Latence 7 µs sur BIP/Myrinet 4 µs sur SISCI/SCI u Bande passante 125 Mo/s sur BIP/Myrinet 80 Mo/s sur SISCI/SCI u Migration (PM2) 24 µs sur SISCI/SCI 52 µs sur BIP/Myrinet

116 MPICH/Madeleine II uMPICH: general-purpose portable MPI implementation well-defined protocol interface Abstract Device uMadeleine: cluster-specific high-performance communication generic structure available on Gigabit networks highly optimized implementation uThe best of both worlds! Madeleine as a MPICH device

117 MPICH/Madeleine II MPI API ADI Protocol Interface 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 loops eager protocol rendez-vous-protocol Madeleine II multi-protocol management Fast-EthernetSCIMyrinet TCPSISCIBIP

118 Latency

119 Bandwidth

120 Multithreading Distribué Vers des communications sur grappes de grappes…

121 Objectifs u 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/Myrinet PC/SCI Réseau rapide

122 PACX-MPI u2 nœuds sacrifiés pour les communications uTransparence pour lapplication uProtocole TCP/IP entre les grappes MPI TCP

123 Globus uPrincipe : Appel de Procédure à Distance uLibrairie de communication : Nexus Multiprotocole Multithreading non nécessairement préemptif La passerelle est sacrifiée uTout est à faire par lutilisateur Pas de gestion explicite des grappes de grappes uPas adapté au problème

124 Madeleine II uBibliothèque de communication Multiprotocole Canaux de communication indépendants Un canal correspond à un adaptateur réseau Canal TCP Canal SCI

125 Structure interne uCouche générique de gestion de tampons uCouche de portabilité avec les protocoles Réseau Application MGT 1 MGT n MGT 2 MT 1 MT n MT 2

126 Structure interne MGT 1 MGT n MT 1 MT n Réseau Application Couche de gestion de tampons Couche de portabilité Aiguillage Sélection MGT 1 MGT n MT 1 MT n Réseau Application Aiguillage Sélection

127 Structure (suite) uOrganisation 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 u Utilisation de réseaux qui ne sont pas présents sur tous les nœuds u Envoi de messages entre des machines non directement reliées SCI Myrinet

129 Intégration dans Madeleine u MTs : pas portable u MGTs : problèmes de conversion u Au-dessus : perte defficacité Application MGT 1 MGT 2 MGT n MT 1 MT 2 Réseau

130 Solution retenue u MT générique entre les MTs et les MGTs u Pas de MGT au niveau de la passerelle MT générique MGT 1 MGT 2 MGT n MT 1 MT 2 Réseau Application

131 Canaux virtuels uContiennent plusieurs canaux réels uPermettent de séparer les messages à retransmettre des messages normaux (canaux réels différents) 1234 Canaux SCI Canaux Myrinet Canal spécial Canal normal Canal virtuel

132 Réactivité et parallélisme uRetransmission des messages par des threads dédiés Une paire de threads par réseau physique Mécanisme de pipeline uRéception des messages normaux sur la passerelle Pas dinformations à priori sur la provenance Threads de scrutation

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

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

135 Évaluation

136 Multithreading Distribué Intégration des threads et des communications

137 Progression des communications u Problème Comment assurer la progression des communications ? proc réseau

138 Scrutation et interruptions u 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 u Les interruptions sont nécessaires Ù Réactivité Problème Ù Outils de synchronisation interrupt safe ?

139 Support de lordonnanceur u Ordonnanceur = serveur de scrutation Choix de la méthode daccès (scrutation/intr.) u Support pour la scrutation Fréquence contrôlée Factorisation des scrutations multiples u Support pour les interruptions Utilisation possible des activations Verrous spécifiques « interrupt-safe »

140 Scrutation par lordonnanceur Ordonnanceur des threads Création dune catégorie de polling (ex: MPI), assignation dune fréquence et enregistrement de callbacks. Polling jobs queue MPI MPI_Isend Marcel_poll Chaque thread candidat à une opération de polling adresse une requête à lordonnanceur et se bloque. MPI_Irecv Marcel_poll callback Régulièrement, lordonnanceur appelle la fonction de scrutation définie par lutilisateur... Polling( )

141 Multithreading Distribué Lenvironnement PM2

142 PM2 : architecture logicielle uLé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

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

144 Multithreading Distribué Conclusion

145 u Multithreading Exploitation efficace des architectures SMP Contrôle fin de lordonnancement Ù Conditionné par les fonctionnalités du système u 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


Télécharger ppt "Supports dexécution pour grappes de machines SMP Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon."

Présentations similaires


Annonces Google