Sortie du noyau Linux 2.6.23

La vingt-quatrième version stable de la branche 2.6.x du noyau Linux est maintenant téléchargeable sur les serveurs du site kernel.org.

• Cette version 2.6.23 a eu un cycle de développement assez long puisqu'il y a eu neuf versions de test. La version RC-1, première des release candidate, a été annoncée par Linus le 22 juillet soit quinze jours après l'ouverture de la fenêtre des modifications.
  (traduction libre):

  Il y a des *tonnes* de changement (..) beaucoup de mises à jour d'architectures (pour toutes - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc), beaucoup de mise à jour de pilotes (encore une fois pour tous les sous-systèmes - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, etc.).
  Les systèmes de fichiers, la mémoire virtuelle, le réseau, ACPI, tout est là. Et la virtualisation est présente partout (kvm, lguest, Xen). Une nouveauté notable est l'inclusion de l'ordonnanceur CFS, et aussi l'infrastructure de pilote UIO qui peut intéresser quelques personnes.
  Oh et personnellement j'aime le fait que "sendfile" soit totalement éliminé en interne et que le noyau fasse tout ce travail avec splice à la place. Bon débarras, même si évidemment nous allons devoir supporter la vieille interface en espace utilisateur pour un long moment.

  
  
• Comme d'habitude Linus a ensuite un peu grogné en constatant que les modifications soumises pour la RC-2 étaient plus invasives que prévu et ne se limitaient pas aux corrections de bugs.
  (traduction libre):

  Donc j'ai essayé de faire respecter la fenêtre des modifications et j'ai dit non à quelques demandes d'inclusion, mais cette nouvelle mode du "RC-2 est le nouveau RC-1" est une vraie plaie. En plus non seulement la seconde release candidate est en retard mais en plus elle est plus grosse que ce qu'elle devrait être. Bon, c'est comme ça.

  
  
• Le rappel à l'ordre a été entendu et le cycle a été plus calme par la suite. Linus l'a reconnu dans son annonce de la RC-3 le 12 août.
  (traduction libre):

  Soit les gens se calment vraiment et se rendent compte que nous sommes dans la phase de stabilisation, soit c'est juste que c'est le milieu du mois d'août et la plupart des gens, au moins en Europe, sont en vacances. Quoi qu'il en soit, la RC-3 est sortie et n'a pas les tonnes de changement qu'avait la RC-2.

  
  
• La version RC-4 (nom de code "Belette rose péteuse") est sortie deux semaines après la précédente du fait d'un oubli de Linus. (traduction libre):

  Le résultat c'est que RC-4 est un peu plus grosse qu'elle devrait être, mais j'ai bon espoir que tout baigne et nous avons corrigé la plupart des régressions.

  
  
• De moins en moins de problèmes étant rapportés, le flot des correctifs s'est ralenti par la suite pour la RC-5.
  (traduction libre):

  Je me prépare à partir pour le Kernel Summit (comme probablement beaucoup d'autres codeurs du noyau) et, à part ça, il y a une version RC-5 qui est sortie. Donc amusez-vous bien, testez-bien, et attendez-vous à une semaine tranquille.

  
  
• De retour du sommet Linus a annoncé le 10 septembre la sortie de la RC-6 qui corrige de nombreuses régressions. La saga s'est ensuite poursuivie avec la RC-7 et la RC-8 qui corrigent d'ultimes bugs.
  (traduction libre):

  Ok je pense que je suis proche de sortir le 2.6.23 et je suis content à propos de son état. Naturellement, ce sentiment de contentement est habituellement suivi immédiatement par l'irruption de nouveaux problèmes soulevés par certaines personnes désagréables...mais je vais juste ignorer cela et apprécier le sentiment aussi passager puisset-t-il être.

  
  
• Linus avait raison d'être prudent car il a finalement dû sortir une RC-9 (ce qui est très inhabituel dans un cycle normal). Constatant un grand nombre de corrections de bugs il a préféré ne prendre aucun risque et sortir cette ultime version de test.
  (traduction libre):

  Je ne pourrai vraiment pas supporter le fait d'annoncer la sortie du 2.6.23 en prenant le risque d'un bug idiot.

  
  

• Le noyau 2.6.23 incorpore l'ordonnanceur CFS créé par Ingo Molnar (et incorporant des idées de Kon Colivas). CFS remplace le précédent ordonnanceur des processus qui a bien servi puisqu'il était apparu dans le noyau 2.5.2-pre10 en janvier 2002. Ce dernier, bien que d'excellente qualité, était handicapé par l'incorporation d'un code spécifique devant estimer l'interactivité des processus. Cet estimateur (basé sur des statistiques donc pouvant se tromper) posait plus de problèmes qu'il n'en résolvait et, grâce à Kon Colivas, le nouvel ordonnanceur peut se passer de tout ce code spécifique. Maintenant tous les processus sont parfaitement égaux ce qui explique le nom de Completely Fair Scheduler ou "Ordonnanceur complètement équitable". Le design proposé par Ingo Molnar incorpore également une idée très novatrice qui est l'utilisation d'arbres de recherche triés en fonction du temps au lieu de l'ancien système des deux queues de tâches qui alternaient entre elles (en posant des problèmes lors de la transition). D'après les tests cet ordonnanceur tout neuf est beaucoup plus robuste que l'ancien (il n'est plus vulnérable aux "attaques" du type fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c) et il améliore sensiblement l'interactivité. Le seul problème qui reste est qu'actuellement CFS n'incorpore pas encore la fonction d'ordonnancement de groupe. Jonathan Corbet, du site LWN, explique parfaitement de quoi il est question. (traduction libre):

  Si cinquante processus essayent de tourner sur une machine alors CFS s'assurera que chacun aura 2% du temps de processeur. Il se peut néanmoins que l'un de ces processus soit le serveur X de l'utilisateur Alice alors que les quarante-neuf autres sont une compilation massive du noyau lancée par l'utilisateur Karl (...) Il est raisonnable de dire que ces 49 processus de compilation devraient être traités en tant que groupe et partagés avec le serveur X d'Alice. En d'autres termes le serveur X devrait avoir 50% du temps de processeur (si il en a besoin) tandis que tous les processus de Karl devraient se partager les 50% qui restent.

  Cette fonction d'ordonnancement de groupe est prête à être incluse et si elle n'a pas été incorporée tout de suite, c'est qu'elle dépend de l'existence de "containers" au sein du noyau qui permettent d'isoler les processus de façon efficace. Ce devrait être le cas dès le prochain noyau 2.6.24.
  
  
• L'appel système fallocate() a été implémenté dans ce nouveau noyau et, à l'heure actuelle, les systèmes de fichier ext4 et ocfs2 l'utilisent. Cet appel système permet de pré-allouer de l'espace sur le disque lors de l'enregistrement d'un fichier. Cela évite, en cas d'augmentation de taille du fichier dans le futur, de le fragmenter sur tout le disque dur puisqu'on peut utiliser l'espace contigu réservé dès le début. On améliore ainsi très largement les temps d'accès lors de la lecture. De plus, avantage annexe, le fait de réserver par avance de l'espace permet d'avoir l'assurance que le fichier pourra croitre, même si le système de fichier est plein. La pré-allocation d'espace est déjà disponible dans la bibliothèque glibc au travers de l'appel standardisé posix_fallocate(). Cependant celui-ci est extrêmement lent puisqu'il écrit des zéros dans tous les blocs de l'espace réservé. Le nouvel appel système fallocate() étant bien plus efficace, la glibc va être modifiée. Si un programme utilise l'appel posix_fallocate() c'est le nouveau fallocate() qui sera utilisé de façon transparente avec, bien entendu, un recours à l'ancien code seulement si le système de fichier ne supporte pas le nouvel appel.
  
  
• Le patch implémentant la fonction de lecture spéculative à la demande (On-demand readahead) a été incorporé. La lecture spéculative permet le chargement à l'avance dans la mémoire du contenu d'un fichier que le noyau est en train de lire. L'idée est de pouvoir fournir les données plus rapidement aux applications : par exemple si un fichier vidéo est en train d'être lu, il est raisonnable de précharger à l'avance la suite du fichier afin de diminuer les accès au disque. Actuellement, la logique déclenchant la lecture spéculative est très simple mais elle permet déjà une augmentation des performances comprise entre 0% et 8%. Maintenant que la fonction basique fait partie du noyau Linux, des améliorations futures sont à prévoir (plusieurs patchs sont déjà prêts) pour lancer la lecture spéculative de façon encore plus précise avec des critères plus fins.
  
  
• Une partie de la technologie de virtualisation Xen fait son entrée dans le noyau Linux 2.6.23. Bien qu'étant intégrée en tant que patch dans plusieurs noyaux de distributions, Xen ne faisait jusqu'à présent pas partie du noyau officiel (mainline). Maintenant il est possible de démarrer au sein d'un environnement paravirtualisé par dessus l'hyperviseur Xen (c'est donc juste le support du mode Guest qui fait son entrée). Le reste n'est pas considéré comme répondant pour l'instant aux standards de Linux et reste donc à l'extérieur.
  Aux cotés de Xen, une autre solution est intégrée dans le noyau : lguest. Cet outil a été écrit par Rusty Russell qui trouvait les autres virtualiseurs beaucoup trop complexes. C'est donc une tentative de créer un virtualiseur le plus simple et le plus propre possible. Avec juste 6000 lignes de code le but est atteint et l'intégration dans la branche principale du noyau va permettre d'avoir une solution de virtualisation ultra-basique pour attirer de nouveaux contributeurs désirant s'initier à ce genre d'outil et faire toutes sortes d'expérimentations techniques.
  Comme le virtualiseur déjà présent, KVM (qui peut maintenant accueillir des machines multiprocesseurs en mode Guest), les deux nouveaux entrants sont basés sur l'infrastructure commune d'abstraction paravirt_ops.
  
  
• L'environnement de support des pilotes en espace utilisateur UIO a été intégré au noyau. Il permet de créer des pilotes très simples qui n'ont pas vocation à fonctionner en espace noyau (au niveau noyau il ne reste plus qu'une toute petite couche qui s'occupe d'enregistrer les pilotes et de gérer les interruptions). Bien entendu UIO est un environnement qui ne permet pas de profiter de toute les fonctions du noyau puisque seul le mode caractère est supporté (pas de mode bloc ou de réseau) et pas d'accès direct à la mémoire. En dépit de ces limitations il peut être intéressant d'utiliser cette nouvelle infrastructure. Ainsi, selon Thomas Gleixner, le nouvel outil lui a permis de convertir un pilote noyau en pilote UIO avec pour résultat une grande simplification du code. On passe de 8539 lignes (5264 dans le kernel et 3275 en espace utilisateur) à 3126 lignes (156 dans le kernel et 2970 en espace utilisateur).
  Bien entendu, le risque engendré par UIO est d'inciter des entreprises à proposer des pilotes non-GPL en espace utilisateur. Andrew Morton s'en est inquiété : «J'ai la vague impression qu'il serait préférable d'encourager les gens à mettre plus de pilotes sous GPL dans le noyau plutôt que de les encourager à faire des implémentation binaires en espace utilisateur qui en plus seront probablement plus lentes, moins fiables et non disponibles sur certaines architectures.» Il lui a été répondu qu'UIO était réservé à des pilotes simples, principalement pour le monde de l'embarqué et qu'il valait mieux qu'il y ait une infrastructure propre et standardisé plutôt qu'une multitude anarchiques de solutions incompatibles.
  
  
• Comme évoqué plus haut dans le mail de Linus à l'occasion de la RC-1 on notera que la très importante fonction sendfile() est maintenant exécutée en interne par l'appel système splice(). Celui-ci a été introduit dans le noyau 2.6.17 afin de permettre aux applications en espace utilisateur d'utiliser un buffer de données (en fait un pipe) en espace noyau. Le gros avantage de splice() est qu'il n'y a plus de copies de données et pas d'allocation de mémoire virtuelle pour l'application en espace utilisateur. C'est donc un mécanisme très efficient et générique et Linus, dans un mail d'avril 2006, annonçait déjà le remplacement de sendfile() qui vient juste d'avoir lieu dans le noyau 2.6.23. (traduction libre):

  Splice() est vraiment un concept tellement puissant qu'avoir sendfile() n'a plus vraiment de sens à l'exception qu'en tant qu'ancienne couche de compatibilité autour du bien plus puissant splice().

  
  
  
• Bien entendu, de nombreuses autres nouveautés sont présentes et un grand nombre de pilotes font leur entrée dans cette version 2.6.23 du noyau. On peut citer en vrac le passage de SLUB (introduit dans le noyau précédent) comme allocateur de mémoire par défaut, le support complet de la carte son de la Playstation 3 ou du gamepad de la Xbox360, L'inclusion du patch anti-fragmentation de la mémoire vive ou des premiers pilotes utilisant la nouvelle pile Wi-Fi mac80211, la réécriture complète du code d'initialisation de l'architecture x86...etc etc.
  Comme d'habitude un résumé très complet de toutes ces nouveautés est disponible sur le site Kernel Newbies qui fait un travail extraordinaire pour centraliser tous les changements. Le site LWN propose également une analyse des contributions au noyau 2.6.23. L'employeur le plus important est Red Hat et le développeur ayant soumis le plus de patchs est Ingo Molnar.

Du coté des nouveautés prévues pour les prochaines versions, il faut tout d'abord noter la naissance d'une page spécifique qui fait le point sur les futures évolutions : Les prévisions météorologiques du noyau. Cette page est maintenue par Jonathan Corbet, le rédacteur de Linux Weekly News, et elle est très riche et informative.
Comme évoqué plus haut, l'ordonnancement de groupe (ou group scheduling) est sur le point de venir compléter CFS. On peut également s'attendre à ce que la compartimentalisation du noyau se poursuive (pas seulement sur les processus mais sur toute les ressources globales).
L'outil de tracing de nouvelle génération, utrace, continue sa maturation et devrait faire son entrée en mainline dès le noyau 2.6.24. La gestion dynamique des interruptions va être étendue à l'architecture x86_64, un outil amélioré de profilage mémoire est également attendu ainsi que l'introduction de points de sondage statiques (static probe points) dans le noyau pour permettre le traçage des performances.
Du côté des systèmes de fichier, le travail continue avec l'introduction des timestamps précis à la nanoseconde pour le futur système de fichier Ext4 ainsi que pour GFS2.

Aller plus loin

• Les nouveautés de Linux 2.6.23 (0 clic)
• Le bilan des ajouts - Partie 1 (0 clic)
• Le bilan des ajouts - Partie 2 (0 clic)
• La liste des régressions connues (0 clic)
• Les futurs ajouts au noyau (0 clic)
• Les contributeurs du noyau 2.6.23 (0 clic)