supports exécutifs pour grappes de machines numa travaux récents et perspectives
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Supports exécutifspour grappes de machines NUMA
Travaux récents et perspectives
Raymond Namyst
Projet LaBRI-INRIA RUNTIME
À 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
La suite logicielledéveloppée par l’équipe
MARCELMARCELMultithreadingMultithreading
MADELEINEMADELEINECommunicationsCommunications
POSIX ThreadPOSIX ThreadCouche deCouche deportabilitéportabilité
MPICHMPICHMPIMPI
Multi-protocolesMulti-protocoles
PadicoTMPadicoTMGestion desGestion des
grillesgrilles
IA32IA32 IA64IA64 PPCPPC SparcSparc MyrinetMyrinet SCISCI QDQD MPIMPI
µPM2µPM2
• 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/
Optimisation des communicationssur réseaux rapides
La bibliothèque NewMadeleine
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
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
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
Méthodes de transfert Mémoire centrale -> carte
Méthodes de transfert Mémoire centrale -> carte
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
Implémentation efficace des transferts
Transfer time
Message size
PIO + copy
DMA + copyDMA + RdV
Implémentation efficace des transferts
Transfer time
Message size
PIO + copy
DMA + copyDMA + RdV
Implémentation efficace des transferts
Transfer time
Message sizeChunk 1Chunk 2Chunk 3
t1
t3
t2
Exemple avec un message non contigü
Implémentation efficace des transferts
Transfer time
Message sizeChunk 1+3Chunk 2
t1
t3
t4
La seconde strategie est meilleure si
t1+t3 > t4 + k.(sizeof(chunk 1)+sizeof(chunk3))
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
NewMadeleine - Architecture
• Architecture en 3 couches
Couche de collecte des données
Couche d’ordonnancement-optimisation
Couche de transfert
Application
Réseau
• La « fenêtre de travail »
Couche de collecte des données
Couche d’ordonnancement-optimisation
Couche de transfert
Application
Réseau
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
Couche de Collecte des Données
Couche de transfert
Couche de collecte des données
Couche d’ordonnancement-optimisation
Couche de transfert
Application
Réseau
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
Couche d’Ordonnancement-Optimisation
• Stratégies, tactiques et sélection d’optimisation
Couche de collecte des données
Couche d’ordonnancement-optimisation
Couche de transfert
Application
Réseau
• 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 d’Ordonnancement-Optimisation
Fonctionnement global
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()
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
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
Ping-pong Nmad/MX
0
10
20
30
40
50
60
70
80
90
100
4 16 64 256 1024 4096 16384
MX
Nmad/MX
Latence :
Taille de paquets (octets) 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 l’optimiseur sur une seule requête
Débit : 238 Mo/sMoins de 5% de perte
0
50
100
150
200
250
4 256 16384 1.04858e+06
MX
Nmad/MX
Ping-pong Nmad/Elan
Taille de paquets (octets) 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 l’optimiseur sur une seule requête
Débit : 635 Mo/sMoins de 5% de perte
0
20
40
4 16 64 256 1024 4096 16384
Elan
Nmad/Elan
0
100
200
300
400
500
600
4 256 16384 1.04858e+06
Elan
Nmad/Elan
Apport de la stratégie d’agrégation
Nmad/MX Nmad/Elan
● 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
0
10
20
30
40
1 2 4 8 16 320
20
40
60
80
1 2 4 8 16 32
Nombre de paquets Nombre de paquets Différence de temps de transfert
(µs)
Différence de temps de transfert
(µs)
Simulation d’une 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 :
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 8Ko 82,28µs 44,84µs 45%
65Ko 185,79µs 143,17µs 23%
Support des architectures multi-rails
• Fonctionnalité apportée « gratuitement » par l’architecture
MPICH/Madeleine : une implémentation multi-protocoles de MPI
Module de communicationlocal
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, …)
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
Multithreading sur machines multiprocesseurs
Former des bulles pour guider l’ordonnancement…
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.
Vers des architectures hiérarchiques complexes
• Puces multicores formées de processeurs « SMT », regroupées en blocs au sein d’une architecture « NUMA »
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
MEMMEM
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
SMTSMT SMTSMT
ChipChip
MEMMEM
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
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 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
PP
P0P0 P1P1 P2P2 P3P3 P4P4 P5P5 P6P6 P7P7
M
PP
M
PP
M
PP
M
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;}
51
Implémentation au sein de Marcel
• Librairie de threads utilisateurs du projet PM2– http://gforge.inria.fr/projects/pm2/
• Performante, flexible et portable
• Compatible POSIX API + ABI
• Nul besoin de changer de noyau
• Ordonnanceur de base simple
52
Un exemple d'expérimentationsavec 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 2.6.18, NPTL
53
Parallélisation d'un seul job
0
0.5
1
1.5
2
2.5
3
3.5
4
1 2 3 4 5 6
Speedup
N ombre de t hr eads
Linux
Marcel-shared
Performant tant que l'on ne surcharge pas
54
Paralléliser les jobs en 4 voies ?
0
1
2
3
4
1 2 3 4 5
Spe
edup
Nombre de jobs
Bubble-gang
Marcel-shared
Linux
55
Paralléliser les jobs en 2 voies ?
1
2
3
4
1 2 3 4 5
Spe
edup
Nombre de jobs
Linux
Bubble-gang2
Marcel-shared
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 ;-)
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.