1 / 26

Équipe INRIA RUNTIME

Équipe INRIA RUNTIME. Permanents Raymond Namyst, Prof. Univ. Bdx 1 (responsable scientifique) Olivier Aumage, CR INRIA Pierre-André Wacrenier, MdC Univ. Bdx 1 Doctorants Vincent Danjean Guillaume Mercier Marc Perache (co-tutelle avec CEA/DAM) Collaborateurs extérieurs

darius
Download Presentation

Équipe INRIA RUNTIME

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. Équipe INRIA RUNTIME • Permanents • Raymond Namyst, Prof. Univ. Bdx 1 (responsable scientifique) • Olivier Aumage, CR INRIA • Pierre-André Wacrenier, MdC Univ. Bdx 1 • Doctorants • Vincent Danjean • Guillaume Mercier • Marc Perache (co-tutelle avec CEA/DAM) • Collaborateurs extérieurs • Marie-Christine Counilh, MdC Univ. Bdx 1

  2. RUNTIME :supports exécutifs pour grappes Techniques d’optimisation des communications sur grappes… qui pourraient être utiles à un émulateur

  3. Thématique de rechercheet compétences Environnements et supports exécutifs pour architectures parallèles

  4. CPU CPU CPU CPU CPU Réseau rapide Architectures parallèles visées • Grappes de SMP (Symmetrical Multi-Processors) • Nœuds multiprocesseurs • Réseaux rapides (Myrinet, SCI, GigaEthernet, etc.) • Systèmes d’exploitation évolutifs (GNU/Linux, Win2K)

  5. Problématique de recherche • Concevoir des supports exécutifs performants… • Exhibant des performances proches de celles du matériel … préservant la portabilité des applications • Assurer la « portabilité des performances » •  portabilité !

  6. Notre démarche • Pour y parvenir, il faut : • Proposer de nouvelles fonctionnalités • Augmenter l’expressivité des interfaces • Revisiter les standards… • Étudier finement les interactions entre composants • Établir de nouveaux schémas de coopération • Étendre les systèmes d’exploitation • Adopter une approche « exo-kernel » • Utiliser des critères pertinents d’évaluation des performances • Réactivité, transferts complexes, etc.

  7. Cadre d’étude • Environnements de programmation pour applications parallèles irrégulières • PM2 (LIFL, ReMaP), Athapascan (Apache) • Contraintes de performance • Feedback applicatif important • Définition d’un support exécutif minimal • µPM2 • Communications • Multithreading • Gestion mémoire distribuée

  8. Communications sur réseaux rapides • Objectif • Interface portable et efficace • Contraintes • Faible surcoût par rapport aux protocoles bas-niveau • Zéro-copie, communication en mode utilisateur • Problèmes difficiles • Diversité des technologies/protocoles réseau • Myrinet, SCI, GigaEthernet, 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

  9. Communications sur réseaux rapides • Travaux connexes • BIP, GAMMA, AM, SBP, VIA : portabilité ? • MPI : manque d’expressivité de l’interface • Fast Messages : transferts explicites • Contribution : l’interface Madeleine • Point clé : programmation par contrat • Cohérence mémoire décorrélée des transferts • Contrôle transparent du niveau d’optimisation •  portabilité des performances

  10. Bilan • Bibliothèque Madeleine • Implantée sur BIP, SISCI, VIA, TCP, MPI • Performances excellentes • Utilisée au sein de plusieurs projets externes • Portée des résultats étendue à d’autres contextes • Thèse d’Olivier Aumage • Quels acquis ? • Grande expertise technologique • Approche originale et pertinente de l’optimisation des communications

  11. Multithreading sur machines multiprocesseurs symétriques • Objectifs • Noyau de multithreading très performant • Fonctionnalités non-standard • Ordonnancement contrôlable (CEA/DAM, Scalapplix) • Interactions avec la gestion des Entrées/Sorties • Points clés • Coopération performante noyau/application • Réaction rapide aux interruptions • Évaluation et compréhension des performances

  12. User Space Process Process Process Scheduler Scheduler Scheduler OS Kernel processor processor processor Multithreading sur machines multiprocesseurs symétriques • Quel niveau d’ordonnancement ? • Noyau/utilisateur/hybride

  13. Multithreading sur machines multiprocesseurs symétriques • Travaux connexes • Scheduler Activations, LinuxThreads, FSU Pthreads, OpenThreads, GnuPth, NPTL, NGPT, Panda, etc. • Contributions • Ordonnanceur caméléon • Hybride dans le cas général • Spécialisable à la compilation • 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

  14. Bilan • Que sait-on faire ? • Ordonnanceurs très efficaces dans le cas général • Contrôle de l’ordonnancement au niveau applicatif • Thèse de Vincent Danjean • Problèmes difficiles • Spécifier l’ordonnancement de manière portable • Gestion des communications (dépend de la technologie réseau !) • Rem: approche « au tournevis » OK… • Comprendre les interactions avec les entrées/sorties • Évaluer les implications des scrutations/interruptions sur le déroulement des E/S • Ex: Scrutations actives en compétition avec les DMAs…

  15. Simulation Code Coupling C3D Plants growing ProActivePDC PaCO++ OpenCCM Do! GK MPI DSM Mome Java VM CORBA PadicoTM Madeleine Marcel Myrinet VTHD VTHD SCI … GRID-RMI

  16. Quels sont les défis auxquels nous sommes confrontés ? • Les architectures évoluent rapidement • Nouvelles technologies • Processeurs, réseaux • Quelles implications sur les modèles actuels ? • Expansion des configurations • Grappes de grande taille, hétérogènes • Comment réaliser des communications performantes ? • Les contraintes applicatives augmentent • Applications distribuées, couplage de code, Grid Computing • Dynamicité, tolérance aux pannes • Quel impact sur les performances ?

  17. Quelques pistes • Communications • Savoir optimiser suivant différents critères • Temps de transfert • Perturbation moindre du processeur (recouvrement) • Qualité de service • Augmenter la généricité de l’architecture logicielle • Comment automatiser davantage le « portage » ? • Continuer la veille technologique • Technologie Infiniband • Demain : entrées/sorties = communications ? • Étudier l’impact de fonctionnalités nouvelles • Tolérance aux pannes, dynamicité

  18. Évolution des architectures • Grappes de grande taille • Plusieurs milliers de nœuds • Problèmes • Passage à l’échelle des communications • Nombre de connexions point à point limitées • Gestion des ressources délicate • Multiplexage • Hiérarchisation virtuelle • Travaux avec Alcatel • Déploiement rapide • Travaux d’Apache

  19. Myrinet SCI Évolution des architectures • Grappes de grappes • Grappes reliées par un réseau rapide • Réseau hétérogène • Problèmes • Communications performantes • Utilisation des liens rapides • Déploiement • Etablissement des connexions • Connaissance de la topologie • Dynamicité des configurations (ex: couplage)

  20. Contribution Communications performantes au sein d’un émulateur de systèmes à grande échelle

  21. Contexte • Fonctionnalités « système » pour des émulateurs d’infrastructures à grande échelle Applications Emulateurs RUNTIME Système d’exploitation Matériel

  22. Besoins • Exploitation efficace d’architectures matérielles de grande taille • Grappe de 1000 PC • Grid5000 (?) • Support d’un grand nombre de communications/connexions simultanées • Plusieurs milliers de flux • Progression des comms/ordonnancement pilotés par l’émulateur • Ralentissement volontaire des communications (?) • Étude de la frontière support exécutif/émulateur • Outils de mesure et de prise de traces • Précision des relevés • Temps virtuel

  23. Multiplexage des communications • Problème • Chaque canal consomme des ressources réseau • Tags BIP, descripteurs SCI, descripteurs TCP • Le nombre de ressources peut dépendre du nombre de nœuds • Segments de mémoire partagée SCI • Virtualiser les ressources • Idéalement : disposer de canaux virtuels • Utilisables comme des canaux physiques • Disponibles en quantité arbitraire • Maximiser les performances • Trouver le bon niveau d’abstraction • Conserver les canaux réels

  24. Communications multiplexées • Rôle de l’émulateur • Communication directe des processus ? • Communications supervisées par l’émulateur ? • Gestion du temps • Gestion des ressources

  25. Outils pour l’analyse de performances • Problème • Reconstruire une séquence d’évènements récoltés à différents niveaux • Contexte multithread hybride (threads noyau/utilisateur) • Outils peu intrusifs • FKT (Robert Russell, UNH) • Fast Kernel Trace • Patch Linux • FUT (ReMaP) • Fast User Trace • Exploitation des résultats • Génération d’une « super-trace » • Unification des données FKT/FUT • Mise en corrélation des événements • Filtrage des informations • Extraction des informations pertinentes

  26. Support multiprocessus • Problème • Support exécutif actuel = multithreads, monoprocessus • Extension possible • Exécution au sein d’un seul processus • Chargement dynamique d’applications • Compilation sous forme de codes relogeables • Perte de la protection entre espaces d’adressage • Approche adoptée par PadicoTM

More Related