Matériel Hardware Locality (hwloc)

Posté par . Modéré par patrick_g.
23
6
nov.
2009
Matériel
Hardware Locality (hwloc) est une bibliothèque détectant le matériel et l'exposant de manière portable et générique aux utilisateurs et applications. Cela permet notamment aux applications d'adapter leur comportement à la complexité interne croissante des machines modernes, avec une hiérarchie sophistiquée de processeurs, cœurs, caches partagés, threads, nœuds NUMA…

Connaître les besoins précis des applications est difficile. Mais connaître l'organisation des cœurs, caches partagés, et autres ressources matérielles, l'est tout autant, en particulier si on souhaite rester portable. Réécrire une application à chaque fois qu'on l'utilise sur une nouvelle machine est inenvisageable. hwloc est là pour se charger de détecter le matériel et de l'exposer de manière abstraite et portable sous la forme d'un arbre, soit par son interface de programmation en C, soit par des outils en ligne de commande. L'outil lstopo fournit par exemple une vue graphique de la hiérarchie de processeurs, caches, cœurs… exportable dans de nombreux formats via Cairo (voir le lien vers les exemples ci-dessous). D'autres outils permettent notamment de verrouiller des tâches à certains processeurs, cœurs… La cible principale d'hwloc est les applications de calcul haute performance (HPC) qui ont besoin d'une connaissance fine du matériel pour déployer des threads (par exemple avec OpenMP) et/ou des processus MPI. L'exploitation optimale des performances du matériel impose en effet de prendre en compte les besoins et affinités entre ces tâches et les caractéristiques du matériel. Par exemple, deux tâches se synchronisant régulièrement ou échangeant beaucoup de données doivent de préférence être placées sur des cœurs partageant un cache, ou au moins dans le même processeur. Par contre, des tâches nécessitant beaucoup de bande passante mémoire doivent de préférence être réparties sur l'ensemble de la machine. D'où l'intérêt de bien connaître la hiérarchie matériel en dessous.

Développé dans l'équipe-projet INRIA Runtime à Bordeaux initialement sous le nom de libtopology, le logiciel a récemment fusionné avec PLPA (Portable Linux Portable Affinity), un sous-projet d'Open MPI. libtopology a apporté une connaissance beaucoup plus fine du matériel, une interface de programmation beaucoup plus flexible, et une plus grande portabilité. De son côté, PLPA apporte un vaste public grâce à son intégration dans Open MPI et MPICH2, très utilisés dans le domaine du calcul scientifique haute performance.

hwloc 0.9.1 est la première version officielle de hwloc, libtopology s'étant arrêté à 0.9. Le logiciel est diffusé sous licence BSD. Il fonctionne sous de nombreux systèmes d'exploitation, même si sa connaissance du matériel est la plus avancée sous Linux. Parmi les futures évolutions de hwloc, on trouve notamment la connaissance des périphériques d'entrées-sorties, qui permettra de placer les tâches près des périphériques qu'elles utilisent (notamment les cartes réseau et les disques).
(17 commentaires).

  • # Interessant

    Posté par (page perso, jabber id) . Évalué à 6.

    Beau projet, qui a de nombreuses utilités.
    J'ai compilé, ça fonctionne sans soucis. Juste dommage que dans les exemples, on vois juste les processeurs et les mémoires. J'aurai aimé voir ce que ça donne sur une détection complète du matériel (cartes PCI & compagnies)

    • [^] # Re: Interessant

      Posté par . Évalué à 6.

      Le support des périphériques PCI n'est pas encore prêt. On est capable de les découvrir et ajouter à la topologie, mais il manque encore pas mal de choses autour pour que ça soit vraiment exploitable. Le code actuel est dispo dans une branche:

      svn co https://svn.open-mpi.org/svn/hwloc/branches/libpci
      ./autogen.sh

      puis configure/make comme d'habiture. Il faut avoir les headers de développement de pciutils (libpci-dev, pciutils-devel, ... selon la distrib). Ensuite lstopo (avec --whole-pci pour tous les détails) peut te montrer des trucs du genre http://pics.livejournal.com/bgoglin/pic/00002zb7

      • [^] # Re: Interessant

        Posté par . Évalué à 3.

        Est-ce que cela va chercher des informations comme la taille des lignes de caches, les jeux d'instructions supportés et leur version, la taille de la DRAM (non confondu avec le swap) ?

        • [^] # Re: Interessant

          Posté par . Évalué à 4.

          Si j'ai bien compris c'est plus axé sur la topologie, y'a d'autres bibliothèques pour découvrir ce genre de chose.

          • [^] # Re: Interessant

            Posté par (page perso) . Évalué à 3.

            Oui, exactement. L'objectif est essentiellement la localisation (d'où le nom). Les tailles de ligne de cache par exemple sont en général homogène, ce n'est donc pas forcément très utile (et rares sont les OS/processeurs qui le rapporte). Les types de processeur par contre on voudra sans doute le rajouter pour le Cell ou le Larrabee.

            • [^] # Re: Interessant

              Posté par . Évalué à 1.

              Les tailles de ligne de cache par exemple sont en général homogène

              cad ?

              Les tailles vont de 32 à 128 octets. Cela peut changer pas mal de choses. J'imagine que l'on peut trouver des valeurs plus extrêmes encore.

              • [^] # Re: Interessant

                Posté par (page perso) . Évalué à 2.

                Oui mais c'est en général homogène, i.e. la même pour tous les processeurs de la machines (pour un type donné, du moins).

                Au besoin on pourra rajouter le champ, au pire, la question, c'est où s'arrêter: mettre l'associativité, la taille de la TLB, etc?

                • [^] # Re: Interessant

                  Posté par . Évalué à 4.

                  Quittes à faire une lib portable dynamique de gestion hardware, je dis oui !

                  L'associativité peut être mortel quand elle est trop simple. Ce qui est le cas de tout ce qui n'est pas un monstre x86.

                  Sinon cote x86, il doit exister 32 64 et 128 comme taille de ligne de cache.

      • [^] # Re: Interessant

        Posté par (page perso) . Évalué à 4.

        Note: quand j'aurai le temps, j'ajouterai aussi les périphériques eux-même (eth0, hda, etc.)

        • [^] # Re: Interessant

          Posté par (page perso) . Évalué à 1.

          J'essaie de comprendre la complémentarité de hwloc avec ce qui existe déjà : dmidecode, hdparm, lspci, hwreport, etc.
          Est-ce que c'est cohérent ? Redondant ? Est-ce que ça pourrait être regroupé ?

          • [^] # Re: Interessant

            Posté par . Évalué à 4.

            hdparm, dmidecode et lspci sont tous des outils détaillés spécifiques à certains périphériques. on pourrait rajouter ifconfig et lsusb par exemple. hwloc s'appuie sur des informations (voire même des bibliothèques) de ce type mais uniquement pour montrer l'organisation de l'ensemble des périphériques, quel qu'en soit le type. Par exemple, dans DMI hwloc prend juste le modèle et la marque de la machine, dans PCI on prend juste la hiérarchie et les types de périphériques. On laisse les détails sordides à ces outils avancés, les applications cibles d'hwloc n'en ont pas besoin. Elles veulent juste savoir comment on organisés les resources dans la machine.

            hwreport semble essentiellement lister le matériel et dire si un driver linux et lequel le supporte. Aucun rapport avec hwloc a priori donc?

  • # Flattened Device Tree

    Posté par (page perso, jabber id) . Évalué à 2.

    Et comment ça se positionne par rapport au Flattened Device Tree ?

    Cf. [http://fdt.secretlab.ca/Main_Page]
    ou encore [http://wiki.freebsd.org/FlattenedDeviceTree]

    • [^] # Re: Flattened Device Tree

      Posté par . Évalué à 2.

      D'après ce que je lis dans ton 2nd lien, le problème visé et le contexte ont l'air très différent. hwloc vise plutôt des machines relativement normales et le HPC, alors que FDT semble plutôt viser l'embedded (et les power). J'ai un peu de mal à voir que FDT fait concrètement mais ca a l'air bien bas niveau. Il est peu probable qu'on mette des infos sur le routages des interruptions dans hwloc à court terme par exemple :) Ceci-dit, une personne nous a dit vouloir utiliser le device-tree pour récupérer des infos de topology sur power dans hwloc, on en saura peut-etre plus à ce moment là.

  • # Lien avec OAR

    Posté par (page perso) . Évalué à 3.

    OAR est un batch scheduler développé en partie par l'INRIA. Quel est ou quel pourrait être les liens entre hwloc et oar ?

    http://oar.imag.fr/

    • [^] # Re: Lien avec OAR

      Posté par . Évalué à 1.

      Il y a déjà eu des discussions avec la communauté Grid5000 à propos de l'utilité de hwloc pour les batch schedulers comme OAR. Par exemple, ca permet au batch scheduler d'attribuer facilement 2 coeurs à un utilisateur en étant certain que ces coeurs sont proches l'un de l'autre.

  • # Quelques questions ?

    Posté par (page perso) . Évalué à 3.

    Je ne sais pas si linuxfr est le meilleur endroit pour les poser mais comme cela peut intéresser du monde, je le fais ici.

    Si je comprends correctement, le but actuel est d'avoir une représentation des capacités de calculs et de mémoire d'une machine, potentiellement multi-noeuds, sous forme d'un arbre. Donc en quelques sortes, seuls les noeuds de l'arbre sont renseignés. Est-il ou sera-t-il possible dans le futur de connaître les liaisons entre ces noeuds ? genre latence et bande passante ?
    Avoir ces informations nécessitera peut être de passer à une représentation en graphe, mais cela pourrait être extrêmement utile pour distribuer efficacement les données sur la machine.
    En attendant je vais tester un peu et faire un peu de pub autour de moi ;).

    • [^] # Re: Quelques questions ?

      Posté par . Évalué à 2.

      Oui c'est effectivement un axe de travail intéressant, et il y a déjà des réflexions avec tes collègues de Scotch sur cette notion de distance, que ce soit quantitativement ou qualitativement. On peut en causer par mail si tu veux.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.