Ce sommet est réservé aux développeurs du noyau (ils viennent sur invitation) et il doit permettre de faire le point sur les travaux en cours afin de décider les futures orientations de Linux. Parmi les 80 développeurs présents, Jonathan Corbet a assisté aux diverses sessions de ce sommet annuel et il publie des articles succints sur chaque présentation ayant eu lieu lors de ces deux jours. Cela permet aux utilisateurs de Linux de se faire une idée de l'orientation générale du développement de leur noyau préféré.
On peut noter que la traditionnelle photo des développeurs montre une spectaculaire augmentation du nombre de filles présentes au sommet 2007 (+200%) : on passe de une à trois par rapport à l'an dernier ! Journée du 5 septembre
La session d'ouverture a été consacrée aux problèmes que rencontrent les mainteneurs des noyaux des diverses distributions. Tous les sujets ont été évoqués lors de cette discussion : Le long délai qui s'écoule entre la sortie d'une fonctionnalité en mainline et son intégration dans les noyaux des distributions d'entreprises, les rétroportages massifs rendus inévitables du fait du maintien par les distributions d'entreprise d'une interface binaire stable, etc. etc. Il a été rapporté que de plus en plus d'entreprises conduisent en interne des tests de non régression sur la branche principale du noyau afin de s'assurer une transition facile quand elles décideront de changer de version. Il serait souhaitable que ces tests s'effectuent également sur la branche expérimentale -mm. Le dernier sujet évoqué a été celui des pilotes de périphériques qui ne font pas partie de la branche principale. Peut-être que les exigences de qualité de Linux sont trop hautes ce qui provoque une perte de motivation de certaines entreprises qui renoncent à pousser leur pilote en mainline ? Quelle que soit l'explication, Linus Torvalds a exprimé l'idée que chaque fois qu'une entreprise distribue un pilote qui n'est pas intégré en mainline c'est un signe d'échec.
La session consacrée à la qualité du noyau a débuté avec les remarques acides d'Andrew Morton qui s'est demandé si le nombre de bugs augmentait ou diminuait avec chaque nouvelle version. Un développeur spécialement chargé de trier et router les rapports de bugs a été engagé par Google pour aider Andrew. Natalie Protasevich est donc en train de passer en revue les 1500 bugs ouverts qui existent dans le bugzilla du noyau. Le problème principal est que de nombreux rapports de bugs ne sont pas traités par les responsables des sous-systèmes concernés. Ted Ts'o a indiqué qu'il y a dix ans les développeurs du noyau prenaient beaucoup plus au sérieux les rapports de bugs et travaillaient vraiment pour aider les utilisateurs. Il lui a été répondu qu'il y a dix ans les utilisateurs de Linux possédaient un bagage technique plus important que maintenant et que les rapports de bugs étaient meilleurs (Alan Cox : Il y a dix ans chaque utilisateur avait un tournevis et la plupart d'entre eux n'avait pas de boitier entourant leur ordinateur).
La solution qui a été adoptée par les développeurs est d'augmenter la relecture du code avant qu'il n'intègre la branche principale. Un nouveau tag "relu par :" sera maintenant obligatoire pour avoir l'assurance qu'une relecture critique du code aura été effectuée avant intégration.
Une session spéciale a été dédiée aux divers sous-systèmes du noyau afin de présenter les conclusions de plusieurs mini-sommets. Len Brown a parlé de la mise en veille (suspend-to-RAM) pour conclure que la situation s'améliore mais qu'il manque des contributeurs et que quelqu'un doit prendre la responsabilité d'investir des ressources dans ce domaine. Parlant ensuite de l'hibernation (suspend-to-disk) Len a évoqué le projet TuxOnIce (anciennement Suspend2) qui n'est pas actuellement en mainline mais qui semble de meilleure qualité que le code actuel du noyau. Le mini-sommet sur la virtualisation s'est prudemment consacré à la question du support en mode invité (Guest mode) afin d'éviter les controverses entre les acteurs concurrents (VMware, Xen...) qui participaient à la discussion. Il a également été question du support des disques implémentant un système de fichier directement en matériel (object-based storage) et d'une technique permettant d'améliorer les allocations de mémoire.
L'écosystème général du noyau a été évoqué lors d'une session spécifique. Cela concerne tous les logiciels tournant en espace utilisateur mais indispensables au fonctionnement moderne de nos ordinateurs (udev, HAL, X, etc.). La difficulté d'utilisation et les fréquentes incompatibilités du système de fichier virtuel Sysfs ont été reconnues. Il est conseillé d'utiliser la couche d'abstraction HAL à la place. En ce qui concerne X, il est prévu d'intégrer les modes vidéos directement dans le noyau. Keith Packard a posté un texte expliquant les avantages de cette solution sur son blog. Enfin, l'ajout de nouveaux appels systèmes va être contrôlé encore plus sévèrement qu'avant et une partie des cas de tests du Linux Test Project va faire son entrée dans le noyau afin d'augmenter encore la robustesse du code.
La dernière session du 5 septembre a été consacrée au support matériel. Chris Schlaeger, le directeur du Operating System Research Center d'AMD, a annoncé l'ouverture des spécifications des cartes graphiques Radeon (R500 et suivantes). Cette annonce est liée au fait que les futurs processeurs d'AMD vont fusionner le c½ur graphique (GPU) avec le c½ur généraliste (CPU). Il serait donc absurde d'avoir un support du libre pour une partie et de maintenir le secret sur l'autre partie du processeur et cela condamnerait cette technologie. AMD va donc travailler avec la communauté pour développer un pilote 3D libre et va ainsi rejoindre Intel dans le camp des vendeurs de matériel aux spécifications ouvertes.
Journée du 6 septembre
La session des clients de Linux a vu l'intervention de trois orateurs qui ont expliqué l'utilisation qu'ils faisaient du noyau et les problèmes qu'ils rencontraient.
- L'intervenant de Dreamworks a indiqué que le rendu des films d'animation du studio se faisait la nuit avec des batchs automatiques mais qu'il y avait souvent des problèmes de saturation de la mémoire. Quand l'espace de swap est lui aussi saturé alors certaines applications sont "tués" par le gestionnaire mémoire pour libérer de la place. Diverses solutions ont été évoquées lors de la discussion qui a suivi (notamment d'usage de containers pour isoler les processus).
- Le représentant du Crédit Suisse a indiqué l'importance cruciale de l'ordonnanceur des processus et des fonctions de temps réel dans le noyau. Les performances de la pile TCP/IP impactent également beaucoup l'efficacité des applications du Crédit Suisse (à titre d'exemple, il a été indiqué qu'une simple congestion réseau de 40 millisecondes peut anéantir les profits d'un trader lors d'une transaction).
- Enfin Marcus Rex, au nom de la fondation Linux, a évoqué plusieurs fonctionnalités qu'il serait souhaitable, selon lui, d'inclure dans le noyau. Ainsi le sujet du tracing (avec l'outil SystemTap) est une fois de plus revenu sur le tapis mais la résistance des développeurs du noyau demeure vive et son intégration demeure incertaine.
Les problèmes de montée en charge (scalability) ont été évoqués lors d'une session très technique. Les performances des entrées/sorties d'un système multiprocesseur seraient grandement améliorées si le processeur initiant l'opération était également celui gérant sa conclusion. Diverses solutions ont été envisagées mais le problème semble difficile à résoudre. De même les performances d'un système devant gérer 20 000 disques durs ne sont pas actuellement optimales et il a été déterminé qu'une procédure de scannage asynchrone pourra accélérer le boot.
Une session sur le temps réel a été organisée afin de faire le point sur les pièces du puzzle qui restent à intégrer en mainline. En effet de nombreuses parties de la branche RT sont déjà présentes et, selon Ingo Molnar, la plus importante s'est révélée être l'outil de validation des verrous (kernel lock validator) qui a permis la détection de nombreux bugs. Il reste toutefois certaines fontions RT qui attendent encore l'inclusion. Par exemple la gestion des interruptions dans des threads séparés permettra au noyau de survivre à des bugs qui auparavant auraient provoqués des crashs du système.
La saga de l'inclusion d'un mécanisme d'entrées/sorties asynchrones s'est poursuivie lors de cette session. Depuis le début de l'année on assiste à une frénésie de propositions concurrentes pour implémenter cette fonction et cette réunion annuelle était l'occasion de faire le point. Cela avait commencé en début d'année avec l'idée de fibrils (lancée par Zach Brown) qui a été critiquée techniquement par Ingo Molnar et a provoquée de nombreux débats sur la LKML. Ensuite Linus a proposé un patch minimaliste en tant que concept et Ingo s'est investi dans le mécanisme des syslets (qui a été raffiné ensuite). Lors du sommet l'opinion majoritaire qui s'est dégagée est que cette fonction n'est pas encore assez mature. De nombreuses parties du noyau doivent êtres modifiées et la phase de test des performances n'a pas encore vraiment débuté. L'implémentation en mainline de ce mécanisme d'entrées/sorties asynchrones n'est donc pas pour tout de suite.
La session sur la gestion de la mémoire s'est consacrée principalement au problème de la gestion des tables de pagination de grande taille. Pour comprendre de quoi il s'agit, il faut savoir qu'un microprocesseur garde dans un cache la table de correspondance entre la mémoire réelle et la mémoire virtuelle. Utiliser un petit nombre de grandes pages dans cette table améliore les performances par rapport à un grand nombre de petites pages. L'ennui, c'est que le noyau actuel ne permet pas de gérer plusieurs tailles alors que certains processeurs modernes le peuvent (avec des tailles de page pouvant atteindre 1 Go). Une interface générique a été discutée avant d'être finalement écartée par Linus au profit d'implémentations différentes selon chaque architecture.
La question des containers a fait l'objet d'une session spécifique qui a fait le tour de tous les problèmes. La gestion des processus dans des containers est considérée comme presque mature et va rejoindre la mainline à brève échéance. En revanche la mise en container de toutes les ressources globales du noyau (en particulier de l'espace de noms) est un projet de plus longue haleine. Quand ce sera terminé Linux aura un système plus générique et plus puissant qu'OpenVZ ou les Zones de Solaris.
Le processus de développement du noyau a été examiné soigneusement et il a été relevé qu'étant donné le rythme de développement actuel, Linux a besoin d'encore plus de codeurs et de testeurs. Pour le noyau 2.6.22 il y avait pourtant eu plus de 900 contributeurs différents mais cela ne suffit pas. Pour éviter de décourager les nouvelles vocations, il faut que les listes de diffusion soient plus accueillantes et il a été demandé d'éviter de critiquer trop sévèrement (flaming) le patch d'un contributeur. De plus dans certaines parties du monde une critique technique acerbe est mal ressentie et peut même entrainer des conséquences professionnelles graves. Une invitation à adopter un ton plus poli a donc été lancée. En ce qui concerne le processus des releases candidates, Linus a renouvelé ses récriminations envers ceux qui soumettent des patchs invasifs en dehors de la fenêtre autorisée.
La session finale du sommet Linux 2007 portait sur le sommet lui-même. Le fait qu'il se déroule uniquement sur invitation est considéré comme une bonne chose car cela permet des discussions techniques plus approfondies. Le lieu du prochain sommet a été discuté et il existe une volonté d'aller en Chine ou en Inde afin de montrer que la communauté Linux est sérieuse quant à son désir d'accueillir plus de développeurs de ces régions. La sur-représentation des USA et de l'Europe est vue comme une anomalie à corriger. Bien entendu le problème est que le coût du transport sera plus élevé si le sommet se déplace en Asie et cette question doit donc être étudiée soigneusement.
Aller plus loin
- Le résumé des sessions sur LWN (0 clic)
- Les articles de Gerrit Huizenga sur le sommet (1 clic)
- Photo des développeurs du noyau (1 clic)
# Une belle entreprise
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
On peut donc se rendre compte que le projet Linux est maintenant devenu pleinement mature et que son modèle de développement est non seulement viable mais excellent.
Lorsque je fais des conférences sur les logiciels libres, j'insiste sur le fait que Linus Torvalds a su gérer le premier grand projet sur Internet et que cela est encore plus à mettre à son crédit que d'avoir créé l'embryon de Linux.
[^] # Re: Une belle entreprise
Posté par Alain Ternet . Évalué à 6.
C'est clair que c'est un exploit d'arriver à maintenir tout ce petit monde (900 personnes aujourd'hui) impliqué dans cette belle aventure. Tout ces gens viennent d'horizon différent, et n'ont pas forcément des objectifs commun. Et pourtant, ça tourne.
Comme j'aimerais avoir le niveau et le talent en programmation pour y participer.
[^] # Re: Une belle entreprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pour ce qui est du test ou des drivers, c'est facile une fois que l'on a compris quelques trucs (comme la réentrance).
Il ne lise pas trop leur bug track mais si ton rapport de bug est assez détaillé, c'est forcément utile.
"La première sécurité est la liberté"
[^] # Re: Une belle entreprise
Posté par Nicolas Schoonbroodt . Évalué à 3.
# Calcul
Posté par flyer . Évalué à -5.
de 1 à 3 ça fait 300% d'augmentation et non 200.
[^] # Re: Calcul
Posté par Zorro (site web personnel) . Évalué à 9.
[^] # Re: Calcul
Posté par Yth (Mastodon) . Évalué à 8.
T'as des trucs, tu les augmente de 100%, ben t'en as le double non ?
Tu les augmente de 200% t'en as le triple...
Yth.
[^] # Re: Calcul
Posté par glattering . Évalué à 2.
100% de 1 c'est 1
200% de 1 c'est 2
1 -> 3, ca fait plus 2, donc plus 200%
[^] # Re: Calcul
Posté par jmelyn . Évalué à 2.
+100% est une augmentation de 100%: 100% initial + 100% ajoutés = 200% comme nouveau total. C'est donc x2.
+200% est une augmentation de 200%: 100% initial + 200% ajoutés = 300% comme nouveau total. C'est donc x3.
La nuance vient du fait que "+...%" est un ajout (en plus de la valeur initiale) alors que "x..." est une mutiplication qui prend déjà en compte cette valeur initiale.
[^] # Re: Calcul
Posté par Padishah . Évalué à 4.
+100% = x2
+200% = x3
En terme d'augmentation, pas de proportion.
[^] # Re: Calcul
Posté par Matthieu Moy (site web personnel) . Évalué à 8.
Et quand tu passes de 1 à 0, c'est une augmentation de 0% !
# Diificile à croire...
Posté par Anonyme . Évalué à 3.
Franchement j'ai peine à croire que cela ait été codée de la sorte et poutant...c'est la vérité.
Donc en gros si je lance un petit process qui sature la mémoire alors qu'un super gros calcul tournait avant, ce dernier a des chances d'être tué ?
Si quelqu'un pouvait expliquer le prquoi un tel comportement du gestionnaire de mémoire? ET en fonction de quoi le GM tue telle ou telle application ?
[^] # Re: Diificile à croire...
Posté par blaz . Évalué à 9.
Le choix fait dans Linux est de tuer les processus les plus gourmands en mémoire. Cela a deux avantages :
- On libère plus de mémoire d'un coup
- Si un processus devient "fou" et alloue énormément de mémoire c'est lui qui sera tué
[^] # Re: Diificile à croire...
Posté par blaz . Évalué à 5.
http://linux-mm.org/OOM_Killer
[^] # Re: Diificile à croire...
Posté par Guinns . Évalué à 6.
BOGUES
Par défaut, Linux suit une stratégie d’allocation optimiste. Ceci signifie que lorsque malloc() renvoie une valeur
non NULL, il n’y a aucune garantie que la mémoire soit véritablement disponible. C’est vraiment un bogue ennuyeux.
Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l’infâme « OOM killer »
(gestionnaire de mémoire) . Si Linux est utilisé dans des circonstances où il n’est pas souhaitable de perdre
soudainement des processus lancés aléatoirement, et si de plus la version du noyau est suffisamment récente, il
est possible de désactiver ce comportement avec une commande comme :
# echo 2 > /proc/sys/vm/overcommit_memory
Voir également les fichiers vm/overcommit-accounting et sysctl/vm.txt dans le répertoire de la documentation du
noyau.
[^] # Re: Diificile à croire...
Posté par - - . Évalué à 5.
cette situation ne doit donc jamais arriver.
[^] # Re: Diificile à croire...
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
Il n'y a aucune trace dans les log du processus killer et si le processus est lancé en ligne de commande, il disparait tout simplement sans laisser de trace. C'est cela qui est génant, le fait de n'avoir aucune trace.
Donc on ne sais pas à quelle heure le processus et mort et pourquoi.
De nos jours, un PC ne marche pas non plus si /var est plein et c'est pas pour cela que lorsque /var est plein que le noyau tue le processus qui écrit le plus dans /var !
Je ne dis pas que le problème /var est identique au problème de la mémoire mais les deux sont fondamentaux et lé réponse actuelle du système Linux n'est pas réellement satisfaisante dans lorsque ces sous parties sont saturées.
[^] # Re: Diificile à croire...
Posté par reno . Évalué à 3.
Si c'est vrai, c'est très génant, mais j'imagine que effectivement c'est difficile pour le noyeau de faire des traces..
Pour ce qui est du /var, cela me parait different: si un processus n'écrit pas dans le /var pourquoi serait-il géné par un /var plein? Donc le /var plein n'est pas un probleme global.
Pour l'OOM, il faudrait mettre des traces ok, mais tu proposerais comme quoi mécanisme pour le /var plein?
Critiquer c'est facile, mais proposer des solutions c'est plus difficile.
[^] # Re: Diificile à croire...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> c'est difficile pour le noyeau de faire des traces..
Le daemon klogd, il est pas fait pour cela ?
Pour ce qui est de /var, le problème est que lorqu'il est plein, tu ne peux plus faire grand chose car tu n'arrives plus à te logguer sur la machine. Par exemple, ssh ne marche plus...
En général, tu doit plus ou moins faire un reboot pour en reprendre le controle. C'est très pénible.
Alors OK, un /var plein est signe d'une mauvaise gestion mais cela m'est déjà malheureusement arrivé.
Je ne dis pas qu'il faille forcément supprimer des fichiers sur /var au premier exécutable qui cherche à écrire mais j'ai pris cet exemple car c'est un peu ce que fait le noyau pour la mémoire.
Le noyau pourrait peut être aussi tuer un processus qui essaye d'écrire sur une partition pleine ? Je n'essaye pas ici de faire un critique à 100% négative du développement du noyau mais simplement de montrer le parallèle entre deux situations bloquantes et profiter de cela pour lancer le débat.
# Bravo!
Posté par Mathias Bavay (site web personnel) . Évalué à 10.
Mathias
[^] # Re: Bravo!
Posté par Okki (site web personnel, Mastodon) . Évalué à 4.
# People Linux
Posté par Thomas Douillard . Évalué à 5.
* Les linuxiens d'aujourd'hui sont de 1,8 à 5.11 fois plus people que techniques.
* Au vu de la photo, les stars de Linux ne sont tout de même pas prêtes à faire la une des magazines people.
[^] # Re: People Linux
Posté par jbar (site web personnel) . Évalué à 2.
(Merci d'avoir incrusté les noms sur la photo).
Quand à ce qu'ils se sont dit réellement... Lorsque j'aurais du nouveau hard non supporté sur mes bécanes actuelles, et/ou que je devrais refaire mon noyau, ben j'irai voir directement les changelog et les TODO.
Je moinsse, tu moinsses, il moinsse, nos bots moinssent ...
# Intel n'a pas de specs ouvertes
Posté par benoar . Évalué à 3.
Précision importante, Intel ne fournit pas les specs de leurs chips graphique ! Certes, ils fournissent des drivers sous GPL (ou une autre licence libre, je ne sais plus exactement), mais si des personnes souhaitent réimplémenter un drivers pour leur carte, ils ne peuvent pas ...
Bref, une fois qu'on aura des drivers pour les cartes ATI, ils deviendront les plus "libriste friendly", mieux qu'Intel.
[^] # Re: Intel n'a pas de specs ouvertes
Posté par Meku (site web personnel) . Évalué à 2.
Mais bon c'est vrai que ça ne vaut pas la doc complète disponible à quiconque.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.