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 exécutifs pour grappes de machines NUMA Travaux récents et perspectives Raymond Namyst Projet LaBRI-INRIA RUNTIME.

Présentations similaires


Présentation au sujet: "Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives Raymond Namyst Projet LaBRI-INRIA RUNTIME."— Transcription de la présentation:

1 Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives Raymond Namyst Projet LaBRI-INRIA RUNTIME

2 À la recherche du temps perdu dans les supports d'exécution Problématique de recherche du projet Runtime – Fournir des abstractions et des techniques permettant de garantir la « portabilité des performances » des applications Démarche – Comprendre les interactions entre les couches logicielles – Intégrer ordonnancement des processus et ordonnancement des communications – Diffuser les logiciels et assurer le support (INRIA Gforge) Environnements de programmation parallèle, bibliothèques spécialisées Support exécutif Système dexploitation Supercalculateurs, grappes, grilles

3 La suite logicielle développée par léquipe MARCELMultithreadingMADELEINECommunications POSIX Thread Couche de portabilité MPICH MPI Multi-protocoles PadicoTM Gestion des grilles IA32IA64PPCSparcMyrinetSCIQDMPI µPM2 Diffusion de la suite logicielle complète sur INRIA GForge

4 Optimisation des communications sur réseaux rapides La bibliothèque NewMadeleine

5 Communications sur réseaux rapides Problèmes difficiles – Diversité des technologies/protocoles réseau Myrinet, SCI, Quadrics, Infiniband, etc. Méthodes de transfert des données radicalement différentes – Schémas de communication irréguliers Messages auto-décrits, réception non sélective Avec MPI, il faut agencer les communications différemment en fonction du protocole sous-jacent ! Objectifs – Interface portable – Faible surcoût par rapport aux protocoles bas-niveau Zéro copie, communication en mode utilisateur – Bonne cohabitation avec la multiprogrammation

6 Linterface de communication Madeleine Caractéristiques – « Envoi de messages » avec construction incrémentale – Bibliothèque multi-protocoles – Coopération avec lordonnanceur de threads Marcel Point clé – Programmation par contrat Cohérence mémoire décorrélée des transferts Optimisations sélectionnées dynamiquement portabilité des performances Travaux connexes – BIP, GAMMA, AM, SBP, VIA : portabilité ? – MPI : manque dexpressivité de linterface – Fast Messages : transferts explicites

7 Comment ordonnancer les paquets ? Ca dépend des caractéristiques du réseau sous-jacent ! – Les pilotes noffent pas tous les mêmes propriétés Latence Performance des transferts PIO & DMA Possibilités de Gather/Scatter Disponibilité du RDMA Etc. Pire : ça dépend aussi des caractéristiques de la machine – Performance des copies memoire – Performance du bus dE/S

8 Méthodes de transfert Mémoire centrale -> carte

9

10 Considerations supplémentaires Le récepteur joue un rôle particulier – Contrôle de flux obligatoire – Transferts zéro-copie Que faire lorsquune carte réseau reçoit un message inattendu ? A Rendezvous (REQ+ACK) can be used Les communications en mode utilisateur introduisent des difficultés supplémentaires – Accès direct à la carte réseau Nécessité de « punaiser » les pages mémoire Les pilotes réseau ont souvent des limitations

11 Implémentation efficace des transferts Transfer time Message size PIO + copy DMA + copy DMA + RdV

12 Implémentation efficace des transferts Transfer time Message size PIO + copy DMA + copy DMA + RdV

13 Implémentation efficace des transferts Transfer time Message size Chunk 1 Chunk 2 Chunk 3 t1t1 t3t3 t2t2 Exemple avec un message non contig ü

14 Implémentation efficace des transferts Transfer time Message size Chunk 1+3 Chunk 2 t1t1 t3t3 t4t4 La seconde strategie est meilleure si t 1 +t 3 > t 4 + k.(sizeof(chunk 1)+sizeof(chunk3))

15 NewMadeleine - Objectifs Une nouvelle interface de communication pour : Améliorer lordonnancement des communications Sadapter à lactivité des cartes réseaux – Carte occupée Accroissement de la portée des optimisations – Sinon Formation dun nouveau paquet à émettre Équilibrer les transferts entre plusieurs cartes

16 NewMadeleine - Architecture Architecture en 3 couches Couche de collecte des données Couche dordonnancement-optimisation Couche de transfert Application Réseau

17 La « fenêtre de travail » Couche de collecte des données Couche dordonnancement-optimisation Couche de transfert Application Réseau Couche de Collecte des Données

18 Encapsule les données – Informations nécessaires au traitement propre du transfert – Introduction dentêtes : Inversions au sein dun même flux de communication Multiplexage de différents flux de communication Décorrèle lactivité de lapplication de celle des cartes réseau – Communications non bloquantes Augmentation des opportunités doptimisation – Accumulation des paquets – Possibilités de permutation – Agrégation anticipée Couche de Collecte des Données

19 Couche de transfert Couche de collecte des données Couche dordonnancement-optimisation Couche de transfert Application Réseau

20 Couche de transfert Appels quasi directs aux routines du pilote sous-jacent Interface de pilotage minimale – Fonctions dinitialisation, de fermeture, denvoi, de réception et de scrutation – Ensemble dinformations sur les capacités du réseau Ports dédiés à une méthode de transfert Portage sur : – MX/Myrinet – GM/Myrinet – Elan/Quadrics – SiSCI/SCI – TCP/Ethernet

21 Couche dOrdonnancement- Optimisation Stratégies, tactiques et sélection doptimisation Couche de collecte des données Couche dordonnancement-optimisation Couche de transfert Application Réseau

22 Fournit le prochain paquet à soumettre Tactique : opération élémentaire – Agrégation – Inversion – etc Stratégie : combinaison de tactiques A terme : Evalue et compare chaque stratégie Sélectionne la plus performante Couche dOrdonnancement- Optimisation

23 Fonctionnement global

24 Interfaces disponibles Interface « pack/unpack » Interface « isend/irecv » Émission: begin_send(dest) pack(len, sizeof(int), r_express) pack(data, len, r_cheaper) end_send() Réception : begin_recv() unpack(len, sizeof(int), r_express) data = malloc(len) unpack(data, len, r_cheaper) end_recv()

25 Plateforme dexpérimentation Grappes de Bi-Xeon 2,6 GHz sous Linux 2.6 Cartes Myrinet 2000 Pilote MX/Myrinet version Cartes Quadrics QM500 Pilote Elan/Quadrics

26 Stratégies doptimisation Actuellement, deux stratégies : Une stratégie « par défaut » – Projection directe Une stratégie dagrégation – Agrégation des données ne nécessitant pas de rendez-vous – Agrégation des messages de contrôle

27 Ping-pong Nmad/MX Latence : Taille de paquets (octets) Temps de transfert (µs) Débit(Mo/s) Latence : 4, 46µs Moins de 1µs de surcoût Coût des entêtes ajoutés Coût de loptimiseur sur une seule requête Débit : 238 Mo/s Moins de 5% de perte

28 Ping-pong Nmad/Elan Taille de paquets (octets) Temps de transfert (µs) Débit(Mo/s) Latence : 3,43µs Moins de 1µs de surcoût Coût des entêtes ajoutés Coût de loptimiseur sur une seule requête Débit : 635 Mo/s Moins de 5% de perte

29 Apport de la stratégie dagrégation Nmad/MX Nmad/Elan Ping-pong multi-paquets : envoi dune taille fixe de 16Ko découpée en un certain nombre de paquets de même taille Gain à lagglomération des paquets Nombre de paquets Différence de temps de transfert (µs) Différence de temps de transfert (µs)

30 Simulation dune Mémoire Virtuellement Partagée for(int i = 0; i < nb_pages_a_demander; i++){ numero_page = random(); (1) pack(destination, mon_id, sizeof(int)); (2) pack(destination, numero_page, sizeof(int)); (3) pack(destination, envoi_diff, sizeof(bool)); (4) pack(destination, type_acces, sizeof(int)); (5) unpack(&numero_page, sizeof(int)); (6) unpack(&trouve, sizeof(bool)); if(trouve){ (7) unpack(&page, taille_page); } else { // recherche de page sur un autre noeud } Côté client : while(1){ (1) unpack(&source, sizeof(int)); (2) unpack(&numero_page, sizeof(int)); (3) unpack(&envoi_diff, sizeof(bool)); (4) unpack(&type_acces, sizeof(int)); page = recherche_page(numero_page, type_acces); (5) pack(source, numero_page, sizeof(int)); if(page){ (6) pack(source, touve, sizeof(bool)); (7) pack(source, page, taille_page); } else { (6) pack(source, pas_trouve, sizeof(bool)); } Côté serveur :

31 MVP - évaluations Temps de transfert pour la demande et la réception de 3 zones mémoire : Taille de la zone Sans agrégation Avec agrégation Gain Nmad/MX8Ko89,16µs64,59µs27% 65Ko352,39µs331,95µs6% Nmad/Elan8Ko82,28µs44,84µs45% 65Ko185,79µs143,17µs23%

32 Support des architectures multi-rails Fonctionnalité apportée « gratuitement » par larchitecture

33 MPICH/Madeleine : une implémentation multi-protocoles de MPI Module de communication local Abstract Device Interface (ADI) Interface générique : gestion des types de données et des requêtes Interface générique: communication point à point et collectives, … API MPI Module Madeleine Communications et protocoles internes de MPICH Madeleine Protocoles de communication (MX, Qsnet, SISCI, …)

34 MadMPI: une émulation « light » de MPI au-dessus de NewMad Projection directe des primitives MPI_??? sur les primitives nmad_??? Performances similaires à celles de NewMad – Latence très faible (2,8 µs sur MX/Myri-10G, 1,7 µs sur Qsnet/Quadrics) – Gains important avec les types dérivés non contigus – Agrégation des isend consécutifs ou simultanés (communicateurs différents) Implémentation incomplète – Pas (encore) dopérations collectives – Pas (encore) dinterface Fortran

35 Multithreading sur machines multiprocesseurs Former des bulles pour guider lordonnancement…

36 La bibliothèque de threads « Marcel » Contributions – Ordonnanceur caméléon Hybride dans le cas général Spécialisable à la compilation Performant – Extensions du modèle des Scheduler Activations Réactivité aux événements dE/S Implantation dans Linux/x86 (LinuxActivations) – Support de lordonnanceur pour la scrutation des E/S Factorisation des scrutations, contrôle du surcoût – Outils de génération et danalyse de traces Mise en corrélation de traces noyau + utilisateur Utilisation du visualisateur Pajé (projet INRIA Apache) Travaux connexes – Scheduler Activations, LinuxThreads, FSU Pthreads, OpenThreads, GnuPth, NPTL, NGPT, Panda, etc.

37 Vers des architectures hiérarchiques complexes Puces multicores formées de processeurs « SMT », regroupées en blocs au sein dune architecture « NUMA » SMTSMT Chip SMTSMT Chip SMTSMT Chip SMTSMT Chip MEM SMTSMT Chip SMTSMT Chip SMTSMT Chip SMTSMT Chip MEM

38 Nouveaux enjeux Maximiser loccupation des processeurs… – Minimiser la contention sur les structures manipulées par lordonnanceur – Renoncer à capturer une vision globale de lordonnancement Et la localité des accès – Enrichir la spécification des contraintes de placement/ordonnancement Comment exprimer les affinités threads/mémoire ? Comment décrire le comportement des threads (calcul, E/S) ? Assurer la portabilité des performances – Raisonner indépendamment de larchitecture sous-jacente Mettre en oeuvre et comparer différentes stratégies dordonnancement

39 Proposition : laisser lapplication guider lordonnanceur Une approche à la fois prédéterminée, opportuniste et négociée

40 40 Des applications irrégulières Maillages adaptatifs Codes multi-échelles Ordonnanceurs classiques inadaptés – Pas de prise en compte de la structure inhérente Comment les ordonnancer efficacement sur machine hiérarchique?

41 41 Notion de bulle pour exprimer des affinités Mémorisation de la structure des applications – Partage de données – Opérations collectives –... bubble_insert_thread(bubble, thread); bubble_insert_bubble(bubble, subbubble);

42 42 Modélisation des machines hiérarchisées Une hiérarchie de listes de tâches PP P0P1P2P3P4P5P6P7 M PP M PP M PP M

43 43 Exemples de répartitions possibles de bulles et threads

44 44 Différentes applications nécessitent différents ordonnancement Des comportements variés – Barrière de synchronisation répartir sur différents processeurs – Affinités mémoire regrouper sur un même noeud NUMA ou une même puce – Débit mémoire répartir sur différentes puces Des compromis à trouver Les ordonnanceurs génériques ne peuvent pas être complètement adaptés

45 45 Écrire son propre ordonnanceur ? Savoir-faire technique – Organisation générale d'un ordonnanceur – Efficacité de l'implémentation – Détails sordides (errno,...) – Portabilité – Outils d'évaluation de performances Une plate-forme de développement d'ordonnanceurs en mode utilisateur

46 46 Boîte à outils pour répartir threads et bulles Basé sur un ordonnanceur générique Points d'appels – Idle – Timeslice « par bulle » –... Thread à part entière – « démon »

47 47 Boîte à outils pour répartir threads et bulles Parcourir la machine – rq->father, rq->sons[] Consulter – for_each_entry Verrouiller – rq_lock, rq_unlock – all_lock, all_unlock Manipuler – get_entity, put_entity

48 48 Des ordonnanceurs variés Vol de travail Éclatement – Répartition simple automatique Gang scheduling... Combinaison d'ordonnanceurs – Dans l'espace – Dans le temps – Par niveaux

49 49 Un gang scheduler runqueue_t nosched_rq; while(1) { runqueue_lock(&main_rq); runqueue_lock(&nosched_rq); runqueue_for_each_entry(&main_rq, &e) { get_entity(e, &main_rq); put_entity(e, &nosched_rq); } if (!runqueue_empty(&nosched_rq)) { e = runqueue_entry(&nosched_rq); get_entity(e, &nosched_rq); put_entity(e, &main_rq); } runqueue_unlock(&main_rq); runqueue_unlock(&nosched_rq); delay(1); }

50 50 Vol de travail idle() { look_up(self_rq); } look_up(rq) { if (look_down(rq->father, rq)) return; look_up(rq->rather); } look_down(rq, maxrq) { if (look(rq, maxrq)) return; for (i=0; i arity; i++) look_down(rq->sons[i], maxrq); } look(rq) { b = find_interesting_ bubble(rq))); if (!b) return 0; rq_lock(rq); get_entity(b); rq_unlock(rq); rq_lock(self_rq); put_entity(b, self_rq); rq_unlock(self_rq); return 1; }

51 51 Implémentation au sein de Marcel Librairie de threads utilisateurs du projet PM2 – Performante, flexible et portable Compatible POSIX API + ABI Nul besoin de changer de noyau Ordonnanceur de base simple

52 52 Un exemple d'expérimentations avec une application Un besoin irrégulier de jobs: factorisations LU Une routine de factorisation parallèle performante (SuperLU) Machine de test – dual-dual-core Opteron 4 processeurs – Linux , NPTL

53 53 Parallélisation d'un seul job Linux Marcel-shared Performant tant que l'on ne surcharge pas

54 54 Paralléliser les jobs en 4 voies ? Speedup Nombre de jobs Bubble-gang Marcel-shared Linux

55 55 Paralléliser les jobs en 2 voies ? Speedup Nombre de jobs Linux Bubble-gang2 Marcel-shared

56 56 Conclusion sur Marcel Une boîte à outils pour: Implémenter des stratégies d'ordonnancement pour machines hiérarchiques – Beaucoup de travail est épargné Tester rapidement des stratégies existantes ou des combinaisons de stratégies – Y compris sur des applications pthread (conformité POSIX binaire) – Évaluation graphique Démo ? – Courtesy of Samuel Thibault ;-)

57 Travaux restant à faire Multithreading – Intégrer gestion mémoire & ordonnancement à bulles Mouvements de données lors des ré-équilibrages Statistiques sur les « points dancrages » des bulles – Bancs mémoire – Caches – Intégrer Marcel et les bulles au sein de MPC Communications – Finaliser linterface légère MadMPI – Évaluer les gains obtenus au sein dapplications de NUMASIS – Porter MPC sur MadMPI Les deux – Rendre lensemble « component-compliant » pour autoriser des reconfigurations à chaud, etc.


Télécharger ppt "Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives Raymond Namyst Projet LaBRI-INRIA RUNTIME."

Présentations similaires


Annonces Google