Brice Goglin a écrit 181 commentaires

Le système n'est pas le noyau, hein (Linux != GNU/Linux). malloc est dans la libc, les processus utilisent la libc... (btw, malloc utilise souvent mmap au lieu de brk)

Accessoirement, utiliser des hugepage, ca veut aussi dire que tu pagines à la granularité de 2Mo, et donc tu lis/écris 2Mo sur le disque au lieu de 4ko quand tu charges les données et quand tu les swappes. C'est plus lent. On peut toujours fragmenter au moment du swap, mais ca réduit beaucoup l'intérêt du bazar.

Bref, arretez de fantasmer à vouloir mettre des hugepages partout. Y a des moments où c'est clairement utile (gros malloc de 1Go, et c'est ce qui est géré par le THP du 2.6.38). Mais dans le cas général (pile, code, libs, mémoire noyau quelconque, ...), c'est souvent pas une si bonne idée.

Je pensais juste à la théorie générale du bidule: les applis demandent des quantités quelconque de mémoire, et le système utilisant la pagination doit allouer des pages entières pour les satisfaire. Plus la taille des pages est grande, plus il y a de fragmentation interne, et possiblement du gachi.

Et malloc(1) alors... Tu fais alignes toujours tes mallocs sur la taille des pages toi ?
Ton processus n'a pas besoin de savoir comment est gérée la mémoire, si elle est paginée ou pas. C'est le noyau (et la libc) qui se débrouillent.
Et même si on considère que le processus finit par demander 4ko au noyau via la libc, l'argument reste valable: pourquoi allouer une hugepage entière si le processus ne veut que 4ko. Gachi idem.

La structure qui s'occupe de ça se nomme un « dentry » (pour directory entry) et, outre l'inode du répertoire, elle contient le nom du répertoire parent et les noms des répertoires enfants.

Ouh la non. Le dentry n'est pas le répertoire entier (sinon ca augmenterait les risques d'accès concurrents, et donc diminuerait les chances de pouvoir utiliser le code RCU), le répertoire contient plein de dentry, un dentry par fils en fait (d'où le nom "directory-entry").

Un dentry contient en fait le nom du fils (ou un pointeur vers un nom alloué à coté s'il est très long), un pointeur vers l'inoeud de ce fils, et un pointeur vers le dentry du répertoire parent.

http://lxr.linux.no/#linux+v2.6.38/include/linux/dcache.h#L116

Allouer une hugepage dès qu'un processus demande une allocation d'un octet, ca serait du gachi (encore plus du gachi que d'allouer 4ko comme on le fait actuellement).

"verrouillage fin" ferait plutot reférence à la durée du verrouillage, pas à la portée de chaque verrouillage. "verrouillage à grain fin", c'est plutot plein de verrous qui protège des petites sections independantes. Le second implique souvent le premier, mais pas réciproquement.

On dit bien "verrouillage à grain fin" dans la vraie vie, mais on le garde au singulier par contre.

Il doit y avoir une confusion entre ligne et caractère là...

Sinon, dans mes arbres qui trainent, je trouve:
2.6.35: drivers=320k reste=770k
2.6.30: drivers=400k reste=560k
2.6.25: drivers=650k reste=355k
2.6.20: drivers=1700k reste=470k
2.6.15: drivers=1580k reste=589k

Difficile de voir des tendances claires. Faudrait surement inclure sound dans drivers. Et que faire de arch/ et fs/ qui recoivent souvent de nouveaux sous-repertoires... Un truc surement plus représentatif du vrai coeur du noyau:

2.6.35: kernel=164k mm=75k
2.6.30: kernel=130k mm=60k
2.6.25: kernel=92k mm=49k
2.6.20: kernel=68k mm=38k
2.6.15: kernel=46k mm=31k

> Le benchmark Linpack n'est pas représentatif et que les ordinateurs américains
> sont bien plus efficaces sur les vrais calculs scientifiques. C'est peut-être vrai
> mais nous n'avons pas eu l'occasion de lire cet argumentaire critique sur Linpack
> quand ces mêmes ordinateurs américains occupaient le sommet du classement.

Euhhhh tout le monde dans la communauté est d'accord pour dire que Linpack n'est pas représentatif. Ca fait des années qu'on le sait. Mais comme d'hab, on a pas mieux. Cet argument ressort tout le temps entre nous quand on compare la ""vraie"" puissance des machines. Et pour des machines hybrides avec GPUs, l'argument est encore plus valable.

C'est Dave Miller, pas Damien (David en fait mais personne ne l'appelle ainsi).

Oui l'INRIA encourage vivement à tout mettre sur HAL.

Le DDX initialise le DRM, il ne fait rien pour l'OpenGL, la 3D et tout le tralala. La 3D (Mesa) parle directement au DRM une fois que le DDX l'a initialisé.

Y a un diagramme qui décrit un peu les interactions à
http://www.phoronix.net/image.php?id=fosdem_2010_unification(...)

Je pense pas non, bonne remarque.

> Amélioration de "Zaphod" (configuration en double-écrans indépendants)

Etonnant ça, Zaphod est censé etre un hack pour les gens qui veulent garder des configs obsolètes. Les écrans indépendants, c'est peut-etre utile dans certains cas mais ca a des inconvénients (notamment que c'est pu vraiment supporté et qu'on peut pas passer une fenêtre de l'un à l'autre).

Avec RandR 1.2 et un window manager pas trop nul, on peut placer les fenêtres sur deux écrans non-indépendants tout en gardant un comportement similaire à Zaphod sans ses inconvénient, donc bon...

> Accélération 3D pour les R600/R700

C'est pas dans le driver DDX ça, c'est dans Mesa (7.7.1 et 7.8 sont prévus pour fin mars).

> Changement de mode en espace utilisateur pour les R600/R700

Euh, c'est quoi ça ? Une traduction erronée de fast user switching ?

> Je ne lui demande rien, en fait. J'admire juste son travail.
> Je m'étonne que tu ne l'aies pas perçu ainsi.

Bah fallait dire ça au lieu de faire des envolées lyrique sur l'existence d'un lecteur quelle que soit la longueur d'un ouvrage...

> Une telle énergie mise dans une dépêche comme celle-ci mérite qu'on y passe du
> temps, ne fût-ce que pour apprécier celui que les auteurs ont passé à l'écrire.

Je vois pas en quoi ça empêche Patrick de changer ce qu'il mettra dans sa prochaine dépêche s'il juge qu'il y a du temps de traduction qui est peu utile.

> Et puis, quelle que soit la longueur d'un ouvrage littéraire, il y aura toujours
> des lecteurs pour apprécier.

Avec des raisonnements comme ça, tu vas finir par demander à Patrick de
traduire le git log complet à chaque release (194k lignes dans 2.6.33).

Pour préciser un peu pourquoi les RC servent à rien: Les annonces des RC contiennent essentiellement des features importantes (que Patrick va de toute façon détailler plus bas), et des stats sur où sont les changement dans cette RC (si ces stats sont vraiment pertinentes, autant les synthétiser sur le release cycle complet comme LWN le fait, pas besoin de stats pour chaque RC). Bref, il reste quelques broutilles, pas besoin de 200 lignes :)

Oui c'est trop long. Il faut virer la partie sur les RC et juste eventuellement garder quelques phrases importantes s'il y en a.

Pour le reste, essayer de résumer un peu sans aller trop dans les détails, quitte à mettre plus de liens pour les gens qui veulent des détails techniques.

Je vois que Frédéric n'a commencé à contribuer que dans 2.6.28, il n'a peut-être pas assez de recul sur tout ça...

> Essayez de travailler sur l'ordonnanceur de tâches, par exemple. Je pense que c'est
> difficile parce que CFS (l'ordonnanceur actuel) a été mergé il y a quelques cycles déjà.
> C'est un gros morceau qui a eu le temps de se stabiliser et de mûrir.

Ahah la bonne blague ! L'ordonnanceur change en profondeur toutes les 3 ou 4 releases. C'est le parfait exemple du sous-système qui aurait dû être stable (on pouvait l'espérer après tout le flan qu'on a fait autour du O(1)-scheduler quand 2.6.0 est sorti), et pourtant non, il continue à être complètement changé régulièrement, bien avant d'être stable ou mûr.

Un vrai exemple de sous-système stable et mûr, c'est la pile réseau (au moins la partie basse qui touche aux drivers Ethernet, je sais pas pour les protocoles au dessus). Les drivers Ethernet ont eu très peu de modifications majeures depuis des lustres (je sais de quoi je parle...).

Que Frédéric Weisbecker se rassure, on recoit assez facilement des offres d'emploi quand a une activité régulière sur LKML et en terme de patchs. Y a au moins Google et VMWare qui s'intéressent à ce genre de contributeurs...

> La technique du Read-Copy update est utilisée dans Linux afin de synchroniser
> de multiples threads pour leur permettre de lire simultanément une donnée
> sans poser dessus un verrou coûteux.

Mouaif... Tant qu'on ne fait que lire une donnée, y a jamais besoin de verrou, c'est quand quelqu'un la modifie qu'on est embetté.

L'intérêt de RCU, c'est que ces multiples tâches peuvent lire une donnée alors que d'autres sont en train de la modifier. La modification est faite de manière à ce que les lecteurs aient toujours une vue cohérente de la donnée (typiquement une liste doublement chaînée) et qu'on ne libère pas la mémoire alors qu'ils y accèdent.