Articles précédents : Logiciel
- [4] Sortie de MailNG 0.7
- [23] Sortie de Val(a)IDE 0.6
- [16] Les 10 ans de Scenari
- [9] Nouvelle version de Mozilla Lightning et SOGo
- [0] Version 1.5 pour w.c.s. et ses téléformulaires
- [10] SeaMonkey 2.0 la suite Internet
- [17] Appel à contribution pour la traduction du manuel d'Audacity
- [6] Sparse repasse à l'attaque
- [9] Présentation du projet LDAP Tool Box
- [2] Sortie de Tryton 1.4
Liens connexes
- Site de hwloc (520 clics)
- Téléchargement (95 clics)
- Exemples (605 clics)
- Ancien site de libtopology (64 clics)
- Ancien site de PLPA (51 clics)
Dépêche modérée par
Dépêche éditée par
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…
Site de hwloc (520 clics)
Téléchargement (95 clics)
Exemples (605 clics)
Ancien site de libtopology (64 clics)
Ancien site de PLPA (51 clics)
> Lire la suite (17 commentaires, moyenne: 3). [dépêche : 2096 caractères]
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).
Interessant
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)
Milite pour un about:black sur les navigateurs ! ( シ Sauvons la planète ツ )
-
[^]Re: Interessant
Posté par Brice Goglin () le 06/11/2009 à 12:06. (lien). É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 Nicolas Boulay () le 06/11/2009 à 12:17. (lien). É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) ?
--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Interessant
Posté par ribwund () le 06/11/2009 à 12:20. (lien). É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 Samuel Thibault (page perso, ) le 06/11/2009 à 12:25. (lien). É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 Nicolas Boulay () le 06/11/2009 à 12:28. (lien). É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.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Interessant
Posté par Samuel Thibault (page perso, ) le 06/11/2009 à 12:31. (lien). É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 Nicolas Boulay () le 06/11/2009 à 12:40. (lien). É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.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
-
-
-
-
[^]Re: Interessant
Posté par Samuel Thibault (page perso, ) le 06/11/2009 à 12:33. (lien). É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 Pierre Jarillon (page perso, ) le 07/11/2009 à 01:02. (lien). É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 Brice Goglin () le 07/11/2009 à 09:12. (lien). É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
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]
Th. Thomas.
-
[^]Re: Flattened Device Tree
Posté par Brice Goglin () le 06/11/2009 à 14:06. (lien). É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
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 Brice Goglin () le 07/11/2009 à 09:39. (lien). É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 ?
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 Brice Goglin () le 09/11/2009 à 21:01. (lien). É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.



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.