Exploitation efficace des grappes de PC Raymond Namyst Projet INRIA ReMaP LIP, ENS Lyon JTE Cluster Computing Octobre 2001, Besançon

Plan u Contexte et motivations Grappes, réseaux rapides, asynchronisme, … u Communications efficaces sur grappes Madeleine : principe, architecture, performances, … u Vers une meilleure réactivité… Multithreading, interruptions, scrutation u Bilan et perspectives Vers les grappes de grappes…

Contexte et motivations Grappes « hautes performances »

Contexte technologique Myrinet u Grappes  Architecture homogène ou presque Noeuds : PC ou stations de travail, mono/multiprocesseurs Réseau : Ethernet, Myrinet, SCI, Giganet, …

Communications performantes u Comment exploiter les réseaux rapides ?  Faible latence Quelques microsecondes  Bande passante élevée De l’ordre 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

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

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 d’interruptions Network RISC Packet Interface DMA PCI Bridge PCI Bridge PCI Bus LANai SRAM NIC

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 à l’arrivée Messages longs : mode zéro-copie (RDV) u Contrôle de flux minimal  Matériel (msgs “évaporés” au dela de 50ms)

SCI : Scalable Coherent Interface u Réseau à “capacité d’adressage”  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 !)

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 n’est pas (forcément) interrompu

Ce qu’il 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é ???

Contexte et motivations Concilier efficacité et portabilité

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 ?

Transmissions zéro-copie Processus A Processus BRéseau Préparation mémoire Acquittement Message Entête Données DMA

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

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

Communications efficaces sur grappes L’interface Madeleine

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 d’optimisation Transferts immédiats possibles u Statut  Disponible sur BIP, SISCI, TCP et MPI.  Portage en cours sur VIA

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

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

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; ÉmissionRéception

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; ÉmissionRéception

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; ÉmissionRéception

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; ÉmissionRéception

L’interface Madeleine Architecture

Architecture générale PM2, MPI, ORB, … Madeleine Gestion générique de tampons Gestion des transmissions BIP, SISCI, VIA, TCP, MPI

Adaptativité Application MGT m MT 1 Orientation Sélection MGT 1 MGT m MT n MT 1 MGT 1 MT n Orientation Sélection MT n MGT 1 MT n MGT 1 Réseau Couche de gestion de tampons Couche réseau

L’interface Madeleine Performances

Quelques résultats u Latence  8 µs sur BIP/Myrinet  6 µ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

L’interface Madeleine Exemple d’application

ORB sur Madeleine u Projet PARIS (IRISA)  Alexandre Denis, Christian Perez Talon IDL Invocation de l ’objet Courtier d’objets (ORB) BOA/POA Squelette IDL Implémentatio n de l ’objet IIOP Madeleine TCP/IP SCI, Myrinet, VIA, etc.

Performances u Débit  SCI : 86Mo/s  Myrinet : 91Mo/s  92 à 99% du débit Madeleine exploité u Latence  CORBA/IIOP (standard) 150 µs  CORBA/SCI ou Myrinet 50 µs CORBA sur SISCI/SCI, BIP/Myrinet et TCP/Ethernet-100

CORBA et MPI u Comparaison entre CORBA et MPI  omniORB/Madeleine - MPI/Madeleine  performances du même ordre de grandeur CORBA et MPI sur SCI

Vers une meilleure réactivité… Où l’on reparle du multithreading

Rappel u Le problème des envois asynchrones Processus AProcessus B Acquittement MPI_Isend MPI_recv MPI_test

Vers un MPI réactif ? u Notification des évènements par signaux  Inutilisable en pratique Indisponible dans la majorité des interfaces Réentrance du code u Utilisation du multithreading 1 thread prend en charge 1 opération asynchrone Les threads de niveau noyau semblent appropriés -Appels systèmes bloquants Mais -Ordonnancement non garanti -Mise en œuvre coûteuse

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

Appels bloquants 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é

Scheduler Activations u Introduit par [Anderson et al. 91] u Principe : la coopération entre les deux ordonnanceurs est bidirectionnelle L’ordonnanceur utilisateur utilise des appels systèmes L’ordonnanceur noyau utilise des upcalls u Upcalls  Informe l’application des événements noyaux u Activations  Autant d’activations en exécution que de processeurs  Contrôlées par le noyau u Idée : revisiter le modèle et l’intégrer à Linux

Illustration du principe Process User scheduler

Illustration du principe Process new

Illustration du principe Process new

Illustration du principe u Déroulement d’un appel bloquant… Process Appel système bloquant

Illustration du principe u Déroulement d’un appel bloquant… Process New + blocked

Illustration du principe u Déroulement d’un appel bloquant… Process Appel terminé

Illustration du principe u Déroulement d’un appel bloquant… Process Unblocked

Illustration du principe u Déroulement d’un appel bloquant… Process

Difficultés de mise en œuvre u Retour d’un 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 L’ordonnanceur de niveau utilisateur doit se prémunir contre ces interruptions intempestives Le coût est prohibitif !

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 » Activations redémarrées au plus vite -Lors du retour mode noyau -> mode utilisateur -Lors du relâchement d’une section critique -Temps de réponse garanti ! u Implantation Linux 2.4.x Bibliothèque de threads Marcel

Performances

Vers une meilleure réactivité… Un mot sur la scrutation active…

Scrutation et multithreading u La scrutation est nécessaire API réseau ne fournissant pas d’appels bloquants  Problème Fréquence difficile à assurer Coûteux en présence de multiples « scruteurs » u Proposition  Délégation à l’ordonnanceur de threads Fréquence contrôlée Factorisation des scrutations multiples  Mécanisme unificateur Utilisation conjointe des activations

Scrutation par l’ordonnanceur Ordonnanceur des threads  Création d’une catégorie de polling (ex: MPI), assignation d’une 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 à l’ordonnanceur et se bloque. MPI_Irecv Marcel_poll callback  Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur... Polling( )

Bilan et perspectives Les grappes… et après ?

Bilan u Les communications sur grappes semblent assez bien maîtrisées  Latence, bande passante  Certains points restent difficiles Le « ping-pong » ne reflète pas les applications réelles La réactivité des nœuds est une propriété importante u De nombreuses réalisations s’appuient sur le tandem Madeleine-Marcel Hyperion : machine virtuelle Java pour grappes MPICH-Mad : MPI multi-protocoles Global Arrays : distribution des données OmniORB Athapascan ? u

Collaborations u Partenariats Projet Hyperion (P. Hatcher, UNH, USA) Projet INRIA PARIS (T. Priol, IRISA) Equipe de J. Roman (Labri) RNRT VTHD ACI GRID u Contrats ReMaP + PARIS + Alcatel -Bus logiciel haute performance pour CORBA ReMaP + APACHE + SIRAC + Microsoft -Portage des environnements sous Windows2000

Travaux en cours u Support des grappes de grappes Communications hétérogènes  Routage efficace sur les « passerelles » Maintien d’une bande passante élevée Réseau à haut débit Réseau haute performance

Travaux en cours u Techniques employées Minimisation des copies entre les cartes Maintien du débit par pipeline logiciel Utilisation du multithreading u Résultats préliminaires  SCI vers Myrinet Bande passante > 48 Mo/s (limite théorique = 66 Mo/s)  Myrinet vers SCI Bande passante = 36 Mo/s seulement Apparition de conflits sur le bus PCI -DMA Myrinet vs PIO SCI -Le pipeline n’en est plus un !