1 / 57

Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives

Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives. Raymond Namyst Projet LaBRI-INRIA RUNTIME. Environnements de programmation parallèle, bibliothèques spécialisées. Support exécutif. Système d’exploitation. Supercalculateurs, grappes, grilles.

bevan
Télécharger la présentation

Supports exécutifs pour grappes de machines NUMA Travaux récents et perspectives

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Supports exécutifspour grappes de machines NUMATravaux récents et perspectives Raymond NamystProjet LaBRI-INRIA RUNTIME

  2. Environnements de programmation parallèle, bibliothèques spécialisées Support exécutif Système d’exploitation Supercalculateurs, grappes, grilles À 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)

  3. MARCEL Multithreading MADELEINE Communications IA32 IA64 PPC Sparc Myrinet SCI QD MPI La suite logicielledéveloppée par l’équipe • Diffusion de la suite logicielle complète sur INRIA GForge • http://gforge.inria.fr/projects/pm2/ • http://gforge.inria.fr/projects/padico/ • http://gforge.inria.fr/projects/mpich-mad/ POSIX Thread Couche deportabilité PadicoTM Gestion desgrilles MPICH MPIMulti-protocoles µPM2

  4. Optimisation des communicationssur 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. L’interface de communication Madeleine • Caractéristiques • « Envoi de messages » avec construction incrémentale • Bibliothèque multi-protocoles • Coopération avec l’ordonnanceur 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 d’expressivité de l’interface • Fast Messages : transferts explicites

  7. Comment ordonnancer les paquets ? • Ca dépend des caractéristiques du réseau sous-jacent ! • Les pilotes n’offent 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 d’E/S

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

  9. Méthodes de transfert Mémoire centrale -> carte

  10. Considerations supplémentaires • Le récepteur joue un rôle particulier • Contrôle de flux obligatoire • Transferts zéro-copie • Que faire lorsqu’une 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 PIO + copy DMA + RdV DMA + copy Message size

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

  13. Implémentation efficace des transferts Transfer time Exemple avec un message non contigü t2 t3 t1 Chunk 1 Message size Chunk 2 Chunk 3

  14. Implémentation efficace des transferts Transfer time La seconde strategie est meilleure si t1+t3> t4 + k.(sizeof(chunk 1)+sizeof(chunk3)) t4 t3 t1 Chunk 1+3 Message size Chunk 2

  15. NewMadeleine - Objectifs Une nouvelle interface de communication pour : • Améliorer l’ordonnancement des communications • S’adapter à l’activité des cartes réseaux • Carte occupée • Accroissement de la portée des optimisations • Sinon • Formation d’un nouveau paquet à émettre • Équilibrer les transferts entre plusieurs cartes

  16. Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert NewMadeleine - Architecture • Architecture en 3 couches Application Réseau

  17. Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert Couche de Collecte des Données • La « fenêtre de travail » Application Réseau

  18. Couche de Collecte des Données • Encapsule les données • Informations nécessaires au traitement propre du transfert • Introduction d’entêtes : • Inversions au sein d’un même flux de communication • Multiplexage de différents flux de communication • Décorrèle l’activité de l’application de celle des cartes réseau • Communications non bloquantes • Augmentation des opportunités d’optimisation • Accumulation des paquets • Possibilités de permutation • Agrégation anticipée

  19. Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert Couche de transfert Application Réseau

  20. Couche de transfert • Appels quasi directs aux routines du pilote sous-jacent • Interface de pilotage minimale • Fonctions d’initialisation, de fermeture, d’envoi, de réception et de scrutation • Ensemble d’informations 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 de collecte des données Couche d’ordonnancement-optimisation Couche de transfert Couche d’Ordonnancement-Optimisation • Stratégies, tactiques et sélection d’optimisation Application Réseau

  22. Couche d’Ordonnancement-Optimisation • 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

  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 d’expérimentation • Grappes de Bi-Xeon 2,6 GHz sous Linux 2.6 • Cartes Myrinet 2000 • Pilote MX/Myrinet version 1.1.1 • Cartes Quadrics QM500 • Pilote Elan/Quadrics

  26. Stratégies d’optimisation Actuellement, deux stratégies : • Une stratégie « par défaut » • Projection directe • Une stratégie d’agré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 Temps de transfert (µs) Débit(Mo/s) Taille de paquets (octets) Taille de paquets (octets) • Latence : 4, 46µs • Moins de 1µs de surcoût • Coût des entêtes ajoutés • Coût de l’optimiseur sur une seule requête Débit : 238 Mo/s Moins de 5% de perte Latence :

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

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

  30. Simulation d’une Mémoire Virtuellement Partagée Côté client : Côté serveur : 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 } } 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)); } }

  31. MVP - évaluations Temps de transfert pour la demande et la réception de 3 zones mémoire :

  32. Support des architectures multi-rails • Fonctionnalité apportée « gratuitement » par l’architecture

  33. MPICH/Madeleine : une implémentation multi-protocoles de MPI API MPI Interface générique: communication point à point et collectives, … Abstract Device Interface (ADI) Interface générique : gestion des types de données et des requêtes Module de communication local 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) d’opérations collectives • Pas (encore) d’interface Fortran

  35. Multithreading sur machines multiprocesseurs Former des bulles pour guider l’ordonnancement…

  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 d’E/S • Implantation dans Linux/x86 (LinuxActivations) • Support de l’ordonnanceur pour la scrutation des E/S • Factorisation des scrutations, contrôle du surcoût • Outils de génération et d’analyse 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. SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT SMT MEM MEM Chip Chip Chip Chip Chip Chip Chip Chip Vers des architectures hiérarchiques complexes • Puces multicores formées de processeurs « SMT », regroupées en blocs au sein d’une architecture « NUMA »

  38. Nouveaux enjeux • Maximiser l’occupation des processeurs… • Minimiser la contention sur les structures manipulées par l’ordonnanceur • Renoncer à capturer une vision globale de l’ordonnancement • 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 l’architecture sous-jacente • Mettre en oeuvre et comparer différentes stratégies d’ordonnancement

  39. Proposition :laisser l’applicationguider l’ordonnanceur Une approche à la fois prédéterminée, opportuniste et négociée

  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. Notion de bulle pourexprimer 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. Modélisation desmachines hiérarchisées Une hiérarchie de listes de tâches M M M M P P P P P P P P P0 P1 P2 P3 P4 P5 P6 P7

  43. Exemples de répartitions possiblesde bulles et threads

  44. Différentes applications nécessitentdiffé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. É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. Boîte à outils pour répartirthreads et bulles • Basé sur un ordonnanceur générique • Points d'appels • Idle • Timeslice « par bulle » • ... • Thread à part entière • « démon »

  47. Boîte à outils pour répartirthreads 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. 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. 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. 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<rq->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; }

More Related