Brice Goglin a écrit 181 commentaires

Le peu que j'en sais:
* l'interconnect mémoire est très mauvais donc il est hyper important de ne pas faire d'accès aux mémoires distantes
* il n'y a pas de MMU, les process ont chacun un bout de la memoire physique, et ca permet notamment des optimisations cracra pour les comms MPI intra-noeud

Y a au moins AIX, Darwin, HP-UX, Linux, OSF, Solaris, et Windows qui ont une connaissance des noeuds NUMA. Pour les autres, y a pas encore le support dans hwloc, donc je sais pas :)

On peut faire du parallélisme avec de la concurrence sans cohérence de cache. Faut juste faire de la synchronisation explicite. On a fait ça pendant des années dans les machine non-CC NUMA.

Les Altix UV seront limitées à 256 sockets Nehalem EX en cache-cohérent, soit 2048 coeurs (4096 threads). On peut mettre plus de sockets (jusqu'à 4096 je crois) mais on perd la cohérence de cache.

Le loi de moore, c'est le nombre de transistors par unité de surface, pas la puissance ni le nombre de coeurs.

En français je ne sais pas (à part s/core/coeurs/) mais en américain AMD ne dit pas "hexacore" (dixit cpuid):

model name : Six-Core AMD Opteron(tm) Processor 8431

"XtreemOS était présent au salon."

C'est bizarre de parler au passé alors que ça ouvre cet après-midi :)

Cell NUMA ? tu confonds les problèmes là...

Cell c'est surtout non-cache cohérent, on s'en fout que ca soit NUMA. L'aspect NCC est ce qui rend le Cell compliqué à programmer vu qu'il faut déplacer les données manuellement entre la RAM et le SPU (y a des problèmes similaires entre RAM et GPU d'ailleurs).

Le "problème" avec les machines NUMA, c'est juste que c'est dur à exploiter *à fond* (il faut faire attention à placer les taches a coté des données qu'elles utilisent). Mais si on ne fait pas l'effort, ca marchera quand même (mais moins vite).

Il y a plein de machines du Top500 qui sont NUMA, rien de spécifique au Cell. Notamment toutes celles à base d'Opteron (et donc Jaguar) et les nouvelles à base des Xeon Nehalem (et donc à terme l'extrême majorité du Top500).

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.

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.

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?

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à.

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

Si, ca va être automatique. Sur les prochains Nehalems, il y a des MCE spéciales pour signaler des problèmes mémoire. Linux marquera ces pages comme "poisoned" pour ne plus essayer de les utiliser.

http://lkml.org/lkml/2009/9/16/240

HWPOISON c'est seulement dans 2.6.32. Et seuls les Nehalem-EX (prévus début 2010) le supportent. Donc peu de chance que ca s'applique au cas ci-dessus :)

Le truc dingue, c'est que des agents INRIA bossant pour le libre ne sont pas tenus au courant par l'INRIA de ce genre d'initiative...

Oui, dans les publis parlant de débit des réseaux haute performance par exemple. Les gens du marketing ont tellement triché sur les débits en mélangeant 1Go et 1Gio (7% de différence) que les gens honnêtes se mettent à utiliser explicitement Gio/s pour qu'on sache de quoi ils parlent.

Ca sent la confusion entre mémoire user et noyau là. kmemcheck c'est pour la mémoire noyau. Il n'y a jamais de demand-paging pour la mémoire du noyau Linux, tout est faulté dès l'allocation, que ce soit kmalloc ou vmalloc. Donc (sans kmemcheck), il n'y a jamais de "crash", qu'on ait de la chance ou pas. Pour le cas avec kmemcheck, Geoffroy a bien expliqué ci-dessus.

"Or avec la mode des grilles de calcul"

Ah ah, très bon ! Sérieusement, la mode c'est le cloud, pas la grille. Ton argument ne s'y applique pas.

"Vu que de nos jours le CPU ne coute plus rien je me demande vraiement si c'est pas plus simple et efficace d'ajouter des CPU que des GPU ?"

Toujours pareil, ca dépend du problème que tu veux résoudre. Y a des cas où les GPU apportent un speedup de 100 donc il vaudra mieux ajouter un GPU par noeud. Et y a des cas où le GPU n'aide pas vraiment. Avant l'introduction des GPUs, on était déjà censés regarder les applis cibles avant d'acheter une machine: vaut-il mieux un cluster, une constellation ou un MPP à la Bluegene? Ben maintenant faut prendre en compte les GPU/accélérateurs avant de décider quoi acheter.

"Intel produit des processeurs et a l'intention de coller des traitements graphiques dans ces processeurs; dans ce cas fini le problème d'accès mémoire ;"

Il ne faut pas aller trop vite là. Tu as beau être dans le processeur, l'accès à la mémoire n'est pas gratuit, et ca va ne faire qu'empirer dans le futur.

A terme, on devrait avoir une fusion entre bus mémoire (QPI ou hypertransport actuel) et le bus I/O (PCIe actuel). Quand ce sera le cas, les périphériques seront grosso-modo connectés comme les processeurs, et donc l'accès à la mémoire pourrait être similaire.

En pratique, ca existe déjà avec les slots HTX qui permettent de brancher des cartes réseau ou des accélérateurs sur le bus hypertransport des machines opterons. Ca réduit effectivement la latence d'accès à la mémoire centrale. Dans ces machines NUMA, tu as un peu de RAM à coté de chaque processeur, et un peu de RAM dans le périphérique. Chacun à accès rapidement à sa mémoire locale et un peu moins rapidement au reste de la mémoire (de l'ordre de 100ns de différence).

Bref, que le GPU soit un périphérique connecté au futur bus mémoire+I/O fusionné (ce que nVidia pourra faire facilement), ou un core spécialisé dans les futurs processeurs hybrides à la Cell (ce que AMD et Intel feront surement), l'accès à la mémoire sera grosso-modo du même genre à terme.

Mettre l'itanium dans la même phrase que l'avenir, ca ne fait pas très sérieux...

C'est moi qui ai écrit l'article que tu cites :) Je maintains un pilote qui n'avait pas eu le droit d'intégrer son LRO proprio, donc effectivement j'avais un peu gueulé :)

La situation n'était pas rose avant 2.6.23. Depuis 2.6.23, ca va.

> "LRO (Large receive offload) de faire son entrée dans le noyau."
> [...]
> L'implémentation retenue pour le noyau 2.6.29 est très générique
> afin que les divers pilotes réseau possédant cette fonction puissent
> utiliser le code générique au bénéfice de la mutualisation du code.

C'est complètement faux...

LRO est dans le noyau depuis très longtemps. Il a été standardisé dans 2.6.23 justement pour mutualiser du code que certains drivers avaient écrit de manière proprio. Depuis, il y a plein de drivers modernes qui l'utilisent (myri10ge, pasemi, igb, benet, sfc, enic, cxgb3, mlx4 et ehea). D'ailleurs le lien LWN date de 2007.

2.6.29 ne fait qu'ajouter une nouvelle implémentation plus propre et plus facile à appliquer aux drivers basiques (le vieux LRO était plutôt conçu pour les drivers récents). D'ailleurs ca s'appelle GRO et plus LRO maintenant.

> L'idée consiste en gros a agréger les paquets reçus dans un tampon
> afin de moins solliciter la pile réseau de la machine.

En moins gros: On n'agrège pas les paquets dans un tampon (sinon ca ferait une copie mémoire très chère), on ne fait que chaîner des socket buffers pour les passer tous d'un coup à la pile TCP/IP.

> Comme Xorg a été séparé (depuis la version 7.0), les drivers peuvent être mis à jour sans
> avoir à recompiler entièrement le serveur X.

Il faut tempérer un peu ça, les interfaces entre modules évoluent de temps en temps. Et donc par exemple certains drivers ne compilent plus sur le vieux Xserver 1.1 et Etch (qui n'a pas été mis à jour ici).

Je suis pas assez réveillé, -intel est un nouveau paquet, il ne vient pas à l'upgrade de -i810 (qui n'a pas été changé).