Raymond Namyst Projet LaBRI-INRIA RUNTIME

Présentation au sujet: "Raymond Namyst Projet LaBRI-INRIA RUNTIME"— Transcription de la présentation:

1 Raymond Namyst Projet LaBRI-INRIA RUNTIME
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 d’exploitation Supercalculateurs, grappes, grilles

3 La suite logicielle développée par l’équipe
POSIX Thread Couche de portabilité PadicoTM Gestion des grilles MPICH MPI Multi-protocoles µPM2 MARCEL Multithreading MADELEINE Communications IA32 IA64 PPC Sparc Myrinet SCI QD MPI 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 Ces thèses sont co-encadrées avec Luc Bougé

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 Ces thèses sont co-encadrées avec Luc Bougé

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 In fact, there are multiple ways to organize the transfer of the data in our small example… The best solution depends on the underlying network, the host machine and event the OS

8 Méthodes de transfert Mémoire centrale -> carte
To illustrate this fact Let’s have a look on the low level mechanisms we can use to transfer data from memory to the Network Interface Card on the sending side

9 Méthodes de transfert Mémoire centrale -> carte
To illustrate this fact Let’s have a look on the low level mechanisms we can use to transfer data from memory to the Network Interface Card on the sending side

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 Obviously, there are many other parameters that one have to take into account In particular, flow-control is often mandatory for large messages If you send a large message to a machine where the system is not ready to receive data, there’s no way for a NIC to allocate memory, so your message will just vanish!

11 Implémentation efficace des transferts
Transfer time PIO + copy DMA + RdV DMA + copy So, to implement data transfers efficiently, we usually have to deal with more than two strategies… Here is an example featuring 3 different strategies Message size

12 Implémentation efficace des transferts
Transfer time PIO + copy DMA + RdV DMA + copy And obviously, you should select the strategy according to the size of your message… But things are not so simple… Message size

13 Implémentation efficace des transferts
Transfer time Exemple avec un message non contigü t2 t3 t1 So, coming back to our example where I proposed two ways to implement the remote procedure call, The question was : is it best to send the 3 chunks separately ?… 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 These details should obviously be hidden by the runtime system. And because a simple “send/recv” API is not rich enough to describe complex communication schemes, We have designed a new communication interface to solve the problem. 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 NewMadeleine - Architecture
Architecture en 3 couches Application Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert Réseau

17 Couche de Collecte des Données
La « fenêtre de travail » Application Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert 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 transfert Application Couche de collecte des données
Couche d’ordonnancement-optimisation Couche de transfert 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 d’Ordonnancement-Optimisation
Stratégies, tactiques et sélection d’optimisation Application Couche de collecte des données Couche d’ordonnancement-optimisation Couche de transfert 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 Latence : 4, 46µs Débit : 238 Mo/s Latence :
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 Taille de paquets (octets) Taille de paquets (octets)
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/MX Nmad/Elan 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 : Taille de la zone Sans agrégation Avec agrégation Gain Nmad/MX 8Ko 89,16µs 64,59µs 27% 65Ko 352,39µs 331,95µs 6% Nmad/Elan 82,28µs 44,84µs 45% 185,79µs 143,17µs 23%

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 Vers des architectures hiérarchiques complexes
Puces multicores formées de processeurs « SMT », regroupées en blocs au sein d’une architecture « NUMA » SMT Chip MEM

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’application guider 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 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 Modélisation des machines 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 possibles de bulles et threads

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 É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é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 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 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 look(rq) { b = find_interesting_ bubble(rq))); if (!b)
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)) 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; }

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 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 Parallélisation d'un seul job
Marcel-shared Linux Performant tant que l'on ne surcharge pas

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

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

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 d’ancrages » des bulles Bancs mémoire Caches Intégrer Marcel et les bulles au sein de MPC Communications Finaliser l’interface légère MadMPI Évaluer les gains obtenus au sein d’applications de NUMASIS Porter MPC sur MadMPI Les deux Rendre l’ensemble « component-compliant » pour autoriser des reconfigurations à chaud, etc.