Sortie du noyau Linux 2.6.39

La sortie de la version stable 2.6.39 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

PS : merci aux contributeurs qui ont participé à la rédaction collaborative de la dépêche en aidant à traduire les annonces de RC de Linus.

Sommaire

• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • Threaded interrupts
  • IP sets
  • Media-controller
  • Block device plugging
• En bref
  • • Transcendent memory
    • User namespaces
    • Système de fichiers pstore
    • Open by handle
    • Améliorations de LIO
    • Device mapper
    • Swap MTD
    • Systèmes de fichiers
    • Appel système syncfs
    • Unicore32
    • Perf
    • Pilotes graphiques
    • Xen
    • KVM
    • DMI
    • Fenêtre de congestion TCP
    • Algorithmes CHOKe et SFB
    • BKL: That's all folks
• Le bilan en chiffres
• Pour la suite
  • ARM : une solution en vue

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 29 mars :

« Le 2.6.39-rc1 est dispo et la période d’intégration est terminée. J’ai encore à regarder le patch cleancache (je l’ai reçu largement dans les temps, mais j’ai décidé que j’allais le passer en revue une fois que la folie de la période merge serait terminée) mais à part ça tout est OK.
Que dire à propos de cette phase d’intégration ? À première vue, on pourrait dire qu’il n’y en a que pour les pilotes, les systèmes de fichiers et le nettoyage des interruptions. Le diff confirme ce sentiment sur les pilotes (65 % des patches), mais il montre qu’il y a largement plus de mises à jour sur les architectures que sur les systèmes de fichiers (le gros du boulot est sur ARM ; il y a quelques modifications des interruptions, mais la majorité des patches ARM se font sur les diverses cartes).
Toujours à propos des architectures, nous avons le début de l’unification de m68k avec m68knommu, ce qui est sympa ; nous verrons bien ce que ça va donner sur le long terme. Oh, et il y a aussi la nouvelle architecture unicore32.
Peut‐être un peu plus intéressant pour la majorité des gens de la communauté du noyau, est le nouveau modèle de branchement des périphériques en mode bloc. Ce branchement se fait maintenant par processus léger (thread), ce qui a permis de nettoyer considérablement le code. Cela permet aussi d’éviter pas mal de verrouillages sur le chemin critique, et ça devrait donc généralement être une bonne idée.
Rien d’autre ? Je suis sûr d’avoir oublié quelque chose de vraiment excitant. Mais en gros, je pense que ce devrait être une de ces versions “solides et sans surprises”.
Je touche du bois. J’aime quand c’est ennuyeux. »

RC-2

La version RC-2 a été annoncée le 6 avril, et Linus s’est félicité de l’absence de gros problèmes :

« Ça a été une -rc2 étrangement calme, ce qui devrait me rendre vraiment heureux, mais très honnêtement, ça me rend juste carrément méfiant. Vous me préparez un sale coup les gars, c’est ça ?
Bref, 35 % archi (ARM et gestion de l’énergie, quelques nettoyages sur unicore32), 35 % sur les pilotes (réseau, les entrées et quelques DRM), et 30 % divers (mises à jour de documentation, perf, réseau, btrfs).
Au final, pas tant de problèmes que ça. Ce qui, je l’espère sincèrement, est un signe que le 2.6.39 va être une version simple.
Touchons du bois. Allez‐y, testez ! »

RC-3

La version RC-3 est sortie le 12 avril :

« Encore une semaine d’un calme presque effrayant. D’habitude ce genre de tranquillité n’arrive que bien plus tard dans le cycle (vers la RC-7 ou la RC-8), mais bon, je ne vais pas me plaindre. Je suis juste en train d’attendre la mauvaise nouvelle.
Et puis, il est possible que ce cycle reste tranquille jusqu’au bout. Nous n’avons certainement pas eu les changements révolutionnaires du cycle précédent, comme la résolution de chemin. Donc, je suis relativement confiant sur le fait que tout va bien se passer.
Bref, non seulement ça a été calme, mais c’est aussi parfaitement dans la norme. Deux tiers des changements sont dans les pilotes et le reste est globalement réparti un peu partout. Espérons que le cycle continue comme ça. J’aime quand les gens semblent vraiment appliquer la règle des “gros changements uniquement pendant la fenêtre de merge”.
Merci les gars. »

RC-4

Bien entendu, ce calme idyllique était trop beau pour durer, et Linus, dans son e‐mail d’annonce de la version RC-4 du 19 avril, a expliqué les problèmes qui étaient apparus :

« Hélas, les choses n’ont pas continué à se stabiliser davantage. Nous avons eu plus de commits dans la RC-4 que dans la RC-3 et j’espère sincèrement que cette tendance à la hausse ne va pas continuer.
Ceci dit, jusqu’à présent, le seul truc qui a vraiment causé des problèmes dans ce cycle, c’est le changement dans la couche de branchement des périphériques en mode bloc. Dans cette RC-4, les soucis que nous avons eus avec MD devraient être derrière nous. Donc, nous progressons dans ce domaine.
Le code de branchement semble provoquer un bogue qui se manifeste pour les CD-ROM par un flux infini de notifications de changements sur le disque. Nous espérons que Jens va résoudre le problème bientôt. Dans l’intervalle, vous pouvez éviter le problème en étant en mode SMP ou en activant la préemption.
Quoi d’autre ? Certes, on a eu un peu plus de commits que dans la RC-3, mais rien de vraiment dramatique. À part les corrections sur les blocs et MD, nous avons eu les mises à jour des systèmes de fichiers (Btrfs, CIFS et Ubifs) et des pilotes (la plus grosse partie étant la suppression de duplicata). De l’USB, un peu de KMS, rien de révolutionnaire. »

RC-5

La version RC-5 du 27 avril a été l’occasion pour Linus de faire part des ses hésitations lorsqu’il s’agit d’accepter des patches importants :

« Nouvelle semaine, nouveau clavier détruit en reversant du café dessus… C’est la vie.
Nous avons moins de changements que pour la RC-4, ce qui est bien. D’un autre côté, je dois réprimander quelques personnes pour avoir intégré des corrections de régressions assez invasives. Malheureusement, ces “personnes” que je dois engueuler, c’est essentiellement moi. La RC-5 contient ce qui est techniquement une régression, mais qui améliore aussi les performances. C’est donc un peu effrayant d’intégrer ça.
Il s’agit des correctifs d’Andi (avec quelques changements par Eric) qui permettent la résolution de chemin par RCU même si SELinux est activé.
Je me suis successivement botté les fesses pour l’avoir accepté et m’être réjoui que la résolution de chemin RCU fonctionne aussi en dehors des domaines non sécurisés… Je ne sais pas ce qui est le mieux.
Les corrections sont toutes assez simples (il y a aussi un peu de nettoyage concernant les dentries que j’ai effectué après avoir analysé le profilage et le code généré), et elles améliorent vraiment les performances de façon importante. En même temps, j’aurais hurlé si quelqu’un d’autre avait tenté de me faire intégrer ce truc si tard. Donc, je vais me considérer comme dûment réprimandé.
À part ça ? Nous devrions avoir corrigé tous les problèmes de branchement dans la couche bloc maintenant, et Tejun a corrigé le truc de notification infinie pour les CD-ROM. Donc, avec un peu de chance, c’est tout bon, et on n’en parle plus.
Et puis, il y a tout le bruit de fond habituel dans les pilotes, quelques mises à jour de ecryptfs et ext2, et juste quelques petites corrections ici et là. Le diffstat a une bonne gueule, et il y a surtout des correctifs d’une ligne et des trucs comme de nouveaux identifiants de périphériques, etc..
Allez‐y, testez. »

RC-6

La version RC-6 du 4 mai a marqué le retour au calme et la stabilisation grandissante du noyau :

« La plupart des correctifs intégrés sont des trucs que l’utilisateur normal ne remarquera jamais vraiment (comme la série des patches sur les kprobes d’ARM) et le reste ce sont les habituels correctifs mono‐lignes sur les pilotes.
Mais nous avons quand même eu un bogue vraiment intéressant. Cela apparaissait comme une erreur RCU en mode mono‐processeur ; erreur qui s’est avérée être un problème lié à l’ordonnanceur, ce problème lui‐même étant en fait un souci d’initialisation de timer. C’était intéressant et plutôt obscur.
Mais la plupart des changements sont juste des petits correctifs un peu partout. Quelques mises à jour de média, un peu de travail sur NFS, quelques corrections sur DRM, la documentation, etc.. Vraiment des petites corrections, et les bogues ont été véritablement obscurs dans l’ensemble. On est encore en train de chercher à résoudre quelques problèmes, mais je pense qu’on est bon pour cette RC-6. Ce ne sera pas la RC finale, mais elle ne semble pas être en mauvaise condition. Les gens qui ont envoyé des rapports de régression sont priés de vérifier à nouveau, et les gens qui n’ont pas envoyé de rapports sont priés de tester aussi. »

RC-7

Enfin, la septième et dernière RC a été annoncée par Linus le 10 mai :

« Bon, les choses ont été plutôt calmes, et à moins qu’un problème majeur surgisse, je pense que ceci sera la dernière RC.
Il y a seulement une petite centaine de changements cette fois‐ci, et le gros des changements est dans “fs/hpfs”, qui est marqué BROKEN depuis le début de la fenêtre de merge, à cause du retrait définitif du verrou global. Donc, c’est la correction d’une régression. Ceci dit, je confesse avoir songé à simplement laisser HPFS cassé pour cette version 39, et repousser cette série de correctifs pour la prochaine fenêtre de merge. Qu’importe. Autant l’appliquer maintenant, puisqu’elle n’a pas d’impact en dehors de HPFS et donc qu’elle ne pouvait pas aggraver les choses.
En dehors de ces patches HPFS, il n’y a pas eu grand‐chose d’intéressant. Quelques problèmes sur les points de traçage ptrace, quelques mises à jour CIFS et tous les minuscules correctifs habituels, surtout dans les pilotes. Rien qui ne sorte du lot, tout a été très calme.
Mais testez s’il vous plaît, juste pour s’assurer que le 39 final sera vraiment bon. »

Les nouveautés

Threaded interrupts

Le noyau 2.6.39 permet de forcer les interruptions à tourner dans des threads noyau. Cette fonction est utile, entre autres, pour obtenir de meilleures données de débogage en cas de crash du gestionnaire des interruptions.

Tout d’abord, un peu de contexte. Quand votre ordinateur a besoin d’une action urgente de la part du système, alors il génère une interruption, ce qui, comme son nom l’indique, interrompt le processeur dans son travail courant. Cela peut se produire dans le cas d’une opération d’entrée‐sortie, de l’avancement d’une horloge, d’une commutation entre deux tâches, d’un défaut matériel, etc..
Ce système des interruptions est extrêmement intéressant, car cela permet au processeur de faire son travail normal d’exécution d’une tâche sans s’occuper de tout le reste. Si un évènement requiert son attention, alors il sera automatiquement prévenu par une interruption. Cela lui évite de devoir vérifier en permanence l’état des périphériques (s’il faisait ça, ce serait du polling, et c’est un comportement bloquant et consommateur de ressources). Quand l’interruption est émise, alors la tâche en cours d’exécution est automatiquement suspendue et la main passe au gestionnaire d’interruptions (interrupt handler). Ce gestionnaire s’occupe de la tâche qui a été demandée par le périphérique et, une fois le travail terminé, il redonne la main à la tâche qui était suspendue.

Nous avons vu quels étaient les avantages du système des interruptions… mais il faut reconnaître que ce mode de fonctionnement n’est pas sans défauts. Le plus important est la latence que cela induit dans l’exécution d’une tâche donnée. Imaginez que vous lanciez une tâche d’encodage qui nécessite une minute de temps CPU. Si cette tâche peut se faire interrompre en permanence à des moments non prévisibles, et si ces satanées interruptions s’emparent de vos précieuses ressources processeur, alors vous ne pouvez plus prévoir le moment ou votre encodage sera terminé. De plus, les interruptions peuvent elle‐mêmes se faire interrompre par d’autres, ce qui rajoute encore de la latence.
En temps normal, ce comportement ne pose pas de gros problèmes, mais dans le cas d’un besoin de temps réel, il faut absolument trouver un palliatif. Un système temps réel cherche à être le plus déterministe possible, et ce système des interruptions qui ajoute des latences imprévisibles est intolérable.
Depuis plusieurs années, une version du noyau Linux adapté au temps réel est développée dans une branche à part. Dans cette version « -RT », les interruptions sont intégrées à des threads du noyau. L’interrupt handler va juste s’assurer de l’origine de l’interruption (opération nommée « quick check handler ») et va ensuite informer le noyau qu’il faut invoquer un thread spécifique pour traiter cette opération (IRQ_WAKE_THREAD).

L’interruption est donc minimale, puisqu’après la vérification de l’origine, on repasse tout de suite la main au noyau. Ce thread noyau peut ainsi être géré comme n’importe quelle tâche par l’ordonnanceur, et le code est plus simple et contient moins de verrous qu’une interruption classique. À cette réduction des latences s’ajoute un bénéfice annexe, puisque le plantage du gestionnaire des interruptions dans un thread ne provoquera qu’un oops au lieu d’aboutir à un crash total du système. Ce oops est bien plus intéressant quand on veut déboguer, puisqu’il permet d’avoir des données précises sur l’origine du problème.

Thomas Gleixner a donc pris le code de threading des interruptions qui existait dans la branche -RT et il a soumis plusieurs patches pour la branche principale du noyau. Évidemment, pour ne pas s’exposer à l’ire de ses collègues, il s’est assuré que son mécanisme était paramétrable. Il indique également que ce code sert surtout à déboguer les problèmes en empêchant un crash total de la machine, et il ne met pas l’accent sur la réduction des latences et le meilleur déterminisme des temps d’exécution des processus.
Pour activer cette fonction, il faut passer « threadirqs » en paramètre au noyau au moment du démarrage (et que le noyau soit compilé avec CONFIG_IRQ_FORCED_THREADING). De plus, même si l’option est activée, il est toujours possible de forcer certaines interruptions à ne pas tourner dans un thread. Pour cela, il suffit de les marquer avec IRQF_NO_THREAD et elles se comporteront comme avant.

Comme il faut souvent choisir entre débit maximum et latences réduites, Thomas a indiqué que ce threading forcé des interruptions avait un certain impact sur le débit brut. Il a effectué des tests sur une machine à base de Core 2 Duo en lançant la commande « time git grep irq_desc ». Le résultat obtenu est rassurant :

• Avant (sans thread) : 1 min 18,741 s ;
• Après (avec thread) : 1 min 19,061 s.

On voit que l’impact, au moins dans ce cas de figure, est minimal. Comme le dit Thomas Gleixner dans son message de commit :

C’est une pénalité raisonnable pour permettre de résoudre des problèmes dans le code des interruptions, puisque ça permet de ne pas planter complètement en cas de bogue.

En plus de cette nouveauté importante que constitue le threading des interruptions, on peut noter que Thomas a largement nettoyé toute la couche générique des interruptions. Parmi ces nombreux patches, on peut noter la petite gueulante qu’il pousse contre les développeurs qui essayent de traficoter la structure « irq_desc ». Selon lui, les statuts présents dans cette structure sont des informations internes qui ne devraient pas être modifiées.
Pour résoudre ce problème irritant, il a opté pour un nom particulièrement explicite :

Le nom « core_internal_state__do_not_mess_with_it » est suffisamment clair, suffisamment embêtant à taper, et il est facile à retrouver avec grep. Les contrevenants seront traqués et fouettés avec des truites puantes.

IP sets

Le patch réseau IP sets, qui existait depuis longtemps en dehors de la branche principale, a été officiellement incorporé au noyau Linux 2.6.39.

Quand il s’agit d’établir un pare‐feu, les systèmes GNU/Linux utilisent normalement le couple Netfilter / Iptables. Netfilter est une infrastructure générale de manipulation des paquets réseau, tandis qu’Iptables est une application qui permet de configurer Netfilter.
La simplicité d’utilisation n’est pas la caractéristique principale du couple Netfilter / Iptables, et l’objectif d’IP sets est de faciliter un peu la vie des administrateurs de pare‐feux. David Miller, le responsable de la couche réseau de Linux, a même qualifié le projet de « totalement génial » dans son message sur la LKML.

Pour paramétrer IP sets, on définit des « ensembles » (des sets) qui peuvent regrouper des données très diverses, comme par exemple des adresses IP, des numéros de ports, des adresses MAC, etc.. Au moment de la création du set, on spécifie son type selon les besoins. Par exemple, ipmap pour des plages d’adresses IP, iphash pour des tables de hachage d’adresses IP, ou encore nethash pour des tables de hachage de taille d’adresse réseau, etc.. La liste des types disponibles est présente sur le site du projet, et on voit qu’un large choix est mis à la disposition des utilisateurs.
Cette définition précise des types est extrêmement utile, puisqu’elle permet d’utiliser des algorithmes de stockage des structures de données en mémoire qui sont spécialement optimisés pour chacun des types de fichiers.

Ces sets sont gardés en mémoire vive et ils sont administrés grâce à l’outil en ligne de commande « ipset ». On positionne ensuite une règle iptables unique qui fait référence à ce set, et hop, c’est fini !
Si on est vraiment vicieux astucieux, on peut aussi assembler des sets en positionnant des références qui s’enchaînent les unes les autres. La page du manuel est très bien faite et explique parfaitement la syntaxe à utiliser pour créer ces sets de types variés.

Les avantages de ce système sont nombreux : par exemple, quand on veut changer les adresses IP ou les ports filtrés par le pare‐feu, on n’a pas besoin de toucher à la règle Iptables, puisque tout se fait dans le set. La modification est donc dynamique.
On peut aussi citer un gros avantage en termes de performances, puisqu’une liste de plusieurs milliers d’adresses IP sera représentée par une seule ligne ipset et que tout est gardé en mémoire vive. Le passage en revue des règles par le noyau (matching) sera donc extrêmement rapide. Bien entendu, la contrepartie est une occupation mémoire plus grande qu’avec des règles classiques.

Comme le patch IP sets existe depuis déjà un certain temps, on le trouve intégré dans plusieurs distributions spécialisées dans les fonctions de pare‐feux. Il était également possible de « patcher » son noyau et d’installer le paquet d’administration ipset pour l’utiliser dans une distribution généraliste.
L’inclusion d’IP sets dans la branche principale du noyau Linux, via l’option IP_SET lors de la compilation, va donc faciliter son utilisation et accroître son audience auprès des administrateurs réseau ayant besoin de contrôler facilement les règles de filtrage de leurs pare‐feux.

Media-controller

Le sous‐système « media controller », qui constitue un complément de l’API classique Video4Linux, a été ajouté dans le noyau 2.6.39.

Écrit par Laurent Pinchart, ce nouveau sous‐système ambitionne de simplifier le travail des applications qui utilisent les périphériques audio ou vidéo de la machine.
En effet, il a été constaté ces dernières années que les puces devenaient de plus en plus complexes et qu’elles intégraient de plus en plus de fonctions. Ce sont maintenant de véritables SoC (Systems-on-a-Chip) qui sont embarqués dans les webcams ou dans les cartes d’acquisition et de sortie vidéo. L’API spécialisée Video4Linux (V4L) a déjà été réécrite au moment de la série des noyaux 2.5.x, afin de permettre de gérer — entre autres — la compression matérielle. Cette interface de programmation de seconde génération (V4L2) a fidèlement servi les auteurs de pilotes, mais elle commence — elle aussi — à montrer ses limites. L’article de LWN dédié au sous‐système « media controller » cite l’exemple de la puce OMAP 3430 qui est utilisée dans les téléphones Nokia N900. Cette puce est en effet représentative de la complexité ahurissante qui caractérise les périphériques vidéo modernes.
Outre le classique processeur ARM et les blocs spécialisés dans le codage / décodage matériel de divers formats, on y trouve également un ISP (image signal processor) très sophistiqué. Divers formats vidéo sont acceptés en entrée, et la compression JPEG, ainsi que la balance des blancs, se font à la volée directement dans la puce. Pour pallier les défauts des lentilles, qui sont souvent minuscules, un processeur spécialisé corrige les distorsions géométriques de l’image, etc..

Chacun de ces composants spécialisés constitue pour le noyau un périphérique qui doit être géré spécifiquement. De plus, la gestion de ces périphériques doit souvent être partagée avec d’autres sous‐systèmes (pensons à ALSA pour le son d’une webcam, par exemple) ce qui ajoute de la complexité. Toutes ces fonctions présentes sur les SoC devraient pouvoir être facilement accessibles par les applications résidant en espace utilisateur. Pour cela, le noyau doit être capable de présenter simplement les caractéristiques de tous les périphériques média… Mais cette contrainte devient de plus en plus difficile à tenir par l’API V4L2 qui n’a pas vraiment été conçue pour ça.

Le sous‐système « media controller » va donc permettre aux applications en espace utilisateur de découvrir et de contrôler les divers périphériques spécialisés présents sur la machine.
Pour cela, ces périphériques sont représentés dans un graphe orienté de tous les blocs média (nommés « entities ») et qui sont connectés par des relations (nommées « pads »).
La nouvelle structure « media_device » accueille les diverses descriptions des « entities » qui peuvent prendre la forme de périphériques audio, de processeurs de mise au point pour les images, de blocs vidéo, de capteurs CCD ou CMOS, de blocs DMA, etc..
Ces « entities » vont être connectées entre elles par des relations « pads », et le flot de données transite simplement depuis un pad de type « source » vers un pad de type « sink ». On voit bien que cette architecture générale fait penser aux pipelines de GStreamer qui utilisent, eux aussi, ces notions de sources, pads et sink.
La phase de découverte et de caractérisation de la topologie des périphériques se fait dynamiquement à chaud, et il est possible d’assigner un numéro de groupe à certaines des entités afin d’indiquer qu’elles fonctionnent ensemble. Par exemple, on peut indiquer que le capteur CMOS, la puce intégrée de correction d’image, ainsi que le microphone, qui sont tous les trois présents dans une webcam font partie d’un même groupe.
Laurent Pinchart a indiqué dans ses e‐mails sur la LKML que les versions successives de ses patches avaient été scrutées de près par les divers responsables du noyau :

Le code a été passé en revue en profondeur par la communauté V4L. Cette nouvelle version est la première à incorporer des commentaires issus de la communauté ALSA.

Il n’y a pas de concurrence, puisque « media controller » est complémentaire d’ALSA et de V4L2, et n’a pas du tout l’ambition de les remplacer. Pour l’instant — comme souvent avec l’introduction d’une nouvelle API — l’option de configuration « MEDIA_CONTROLLER » est encore marquée comme expérimentale. La documentation détaillée est au format Docbook et se trouve dans « documentation/DocBook/v4l/media-controller.xml ». On trouve quand même une brève présentation dans « media-framework.txt ».

Du côté des applications, il est bien sûr possible d’interroger finement le sous‐système « media controller » pour se renseigner sur les capacités matérielles de la machine. Cela se fait via des appels ioctl aux noms explicites comme « MEDIA_IOC_DEVICE_INFO » ou « MEDIA_IOC_ENUM_ENTITIES » ou encore « MEDIA_IOC_ENUM_LINKS ». Les applications peuvent changer les liens entre les « entities », via un appel à « MEDIA_IOC_SETUP_LINK ».
Le premier pilote à utiliser ce sous‐système « media controller » est l’ISP OMAP3, mais il ne fait aucun doute que de nombreux pilotes vont bientôt utiliser cette nouvelle infrastructure moderne présente dans le noyau Linux.

Block device plugging

La grosse nouveauté du noyau 2.6.39, c’est l’intégration du patch « block device plugging » écrit par Jens Axboe, qui change considérablement le mode d’écriture des entrées‐sorties en mode bloc du noyau.

Auparavant, à l’ère des dinosaures, tout était relativement simple dans le mode d’envoi des blocs de données vers les périphériques. Quand un processus avait des opérations d’entrées‐sorties à effectuer, le noyau mettait le périphérique cible dans un état dit « branché » (plugged). Ainsi, au lieu d’envoyer directement les données vers le pilote du périphérique pour lancer l’écriture, on peut accumuler les requêtes dans le « tuyau de branchement » (plugged queue). Quand le processus se met à attendre que les données soient écrites, alors il est temps de « débrancher » le périphérique (device unplug) et d’écrire effectivement les données.
Cette méthode permet de fusionner des opérations d’écritures en une seule commande globale et elle améliore donc les performances.

Malheureusement, ce code antédiluvien ne tenait aucun compte des machines multiprocesseurs, et l’opération de branchement impliquait un gros verrou qui limitait la montée en charge. En outre, le débranchement était lui aussi global (via la fonction « blk_run_queues ») ce qui provoquait un « unplug » sur tous les périphériques, alors qu’il aurait été préférable de ne débrancher que le périphérique concerné.
Ces limitations ont conduit Jens Axboe (déjà lui !) à modifier le code du noyau en mars 2004. Avec les patches de Jens, le débranchement pouvait se faire pour un périphérique spécifique (per‐device unplug) grâce à la fonction « blk_run_queue » (notez le « s » qui a disparu par rapport au nom de la précédente fonction). Ce changement a nécessité un hack assez vilain dans le sous‐système de la mémoire virtuelle, mais la montée en charge en a été facilitée et les performances ont fait un bond important.

Sept ans après ce travail, Jens Axboe s’est penché une nouvelle fois sur le code des entrées‐sorties du noyau en mode bloc. Il s’est rendu compte qu’en 2011, les compromis nécessaires ne sont plus les mêmes que ceux qui étaient pertinents en 2004. Par exemple, toute cette fonction de « plugging » des périphériques est désactivée pour les disques SSD qui ont une fonction intégrée de mise en queue. Les périphériques rapides, qui sont de plus en plus répandus, imposent donc de réécrire le code de « plugging ».
Jens a décidé de revoir complètement la logique présente dans le noyau Linux, et c’est ce travail qui arrive maintenant dans la version 2.6.39 du noyau.

Le but que poursuit Jens est — comme toujours — de pouvoir faciliter la montée en charge (scalability) et d’augmenter les performances générales. Quels sont les problèmes du mécanisme actuel ?
D’abord, il faudrait que le périphérique lui‐même ne soit plus bloqué par le plugging. En effet, un verrou est tenu sur la queue d’accumulation des données du périphérique, et ce verrou limite la montée en charge.
Un autre problème est la nature asymétrique du mécanisme qui existait jusqu’à présent. On avait un branchement qui se faisait de façon implicite dès que des entrées‐sorties étaient soumises, mais le débranchement devait se faire de façon explicite via l’appel à la fonction « blk_run_queue ».

La solution retenue est de ne plus accumuler les opérations d’entrée‐sorties dans un tampon vivant dans le contexte du périphérique (shared state in the device). Au lieu de ça, une structure est créée directement dans la pile du processus qui soumet les données et cette structure, nommée « struct blk_plug », va accueillir le tampon d’accumulation des entrées‐sorties.
En résumé, maintenant, on ne branche plus un périphérique en particulier. On branche directement les processus qui veulent envoyer des données. Cette opération de branchement se fait explicitement avec la commande « blk_start_plug » et le débranchement s’effectue via « blk_finish_plug ».

Ce nouveau mode opératoire permet de corriger les deux défauts du précédent mécanisme qui ont été évoqués plus haut.
Le plus important c'est qu'on n'accumule plus les données en tenant un verrou sur la queue de branchement du périphérique. Ainsi le chemin critique (hot path) est moins contraint par des verrouillages incessants et la montée en charge est bien plus facile.
Les opérations de branchement et de débranchement sont maintenant complètement symétriques, ce qui réduit une source potentielle de bugs. Avant, il fallait utiliser des heuristiques pour débrancher quand un processus se mettait à attendre la complétion de ses opérations I/O. Maintenant, plus besoin d'heuristiques puisque le débranchement se fait explicitement avec un blk_finish_plug quand le thread qui soumettait des requêtes I/O à fini de les envoyer.
Pour que la joie soit complète, la suppression de cette fonction de branchement implicite a permis de retirer de nombreuses lignes de codes qui étaient devenues inutiles. Le changelog a été qualifié par Jens de tasty (succulent) car le nombre total de lignes est réduit dans le noyau (1520 lignes insérées et 2112 lignes supprimées).
En outre, et pour que la joie soit vraiment ultime, le hack assez moche qui avait été introduit en 2004 dans la fonction sync_page n'est plus nécessaire et il a été retiré (pour le plus grand soulagement des responsables du sous-système de la mémoire virtuelle).

Linus ne s'y est pas trompé et ce nouveau mode d'écriture des entrées/sorties en mode bloc du noyau est le seul changement qui a droit à un paragraphe complet dans son mail d'annonce de la RC-1 :

Le nouveau modèle de branchement des périphérique en mode bloc se fait maintenant par thread et a permis de nettoyer considérablement le code. Cela permet aussi d'éviter pas mal de verrouillages sur le chemin critique et ça devrait donc généralement être une bonne idée.

Bien entendu il y a eu des petits problèmes au début lors de l'inclusion et Linus a aussi évoqué ces légers désagréments :

Ceci dit, le nouveau mécanisme s'est mis à manger les systèmes de fichiers XFS pour son petit-déjeuner, mais c'est corrigé et on espère que tout devrait être bon maintenant.

Les dernières corrections ont été intégrées au moment de la RC-4 ce qui démontre quand même qu'il n'y a pas assez de gens qui testent les noyaux de développement (la branche -next par exemple) et qu'il faut attendre la fin de la période de merge pour que les utilisateurs se mettent soudain à couiner en cas de bugs.
Quoi qu'il en soit ce nouveau mécanisme semble bien plus efficace que son prédécesseur et il constitue donc une avancée marquante du nouveau noyau.

En bref

Transcendent memory

Les patchs de « Transcendent memory » écrits par Dan Magenheimer sont entrés dans la branche -staging du noyau 2.6.39.
L'idée derrière ce patch Tmem consiste à doter le noyau d'un moyen différent de gérer la mémoire du système. Ce code alternatif offre un réservoir de pages mémoire créé par la fonction tmem_new_pool() et l'idée ressemble un peu à celle de memcached puisqu'on va se servir de ce réservoir de mémoire pour éviter de coûteuses opérations d'entrées/sorties sur le disque. Selon Dan, cette technique et le mode de gestion particulier de cette mémoire sont notamment utiles dans le cas d'un système virtualisé.
Aux côtés de ce patch de « Transcendent memory », on note également le mécanisme de compression du cache des pages mémoire « zcache » qui entre lui aussi dans -staging. Ce code utilise le mécanisme Tmem mais n'est pas encore fonctionnel puisqu'il nécessite une autre pièce du puzzle (le patch « cleancache ») que Linus a refusé lors de la période de merge.

User namespaces

Développé par Eric Biederman et Serge Hallyn, le patch de « user namespace » est une extension du méchanisme des « capabilities » du noyau. Classiquement les capabilities sont utilisées pour donner à un processus des droits ayant une granularité plus fine que le classique, et fort dangereux, flag setuid().
Ici l'idée est de créer une sorte de conteneur où tous les processus auront l'illusion de tourner sur le système racine alors qu'en réalité, ils seront confinés dans leur espace de nommage (namespace) où chacun des conteneurs aura son ensemble d'UIDs.
Jusque là, rien que de très classique…mais le but est de permettre à des utilisateurs normaux (non root) de créer ces conteneurs. Pour cela il faut contrôler de façon plus fine les capabilities des processus.
Ainsi, un user non privilégié du système pourra utiliser l'appel ns_capable() pour gérer les capacités. Si ce user utilise cet appel système il ne pourra que positionner une capacité sur un processus dans son espace de nommage ou dans un espace de nommage qui descend du sien. Il lui sera interdit de « remonter » dans la hiérarchie des espaces de nommages.
Le patch qui entre dans le noyau 2.6.39 n'est que le début d'un travail à long terme puisque le code a été conçu pour élargir progressivement les capabilities qui seront autorisées dans ces « user namespace » spéciaux. Pour l'instant, seuls trois appels système sont autorisés : sethostname() (si le user à la capacité CAP_SYSADMIN), l'appel check_kill_permission() (si le user à la capacité CAP_KILL) et enfin ptrace() (si CAP_SYS_PTRACE est positionné).
Une page du wiki Ubuntu coordonne l'avancement des travaux et, comme l'explique fort bien cet article LWN, l'approche incrémentale a été choisie afin de pouvoir relire et tester plus longuement les fonctions de « user namespace » puisqu'il s'agit d'une fonction sensible concernant la sécurité.

Système de fichiers pstore

Le système de fichiers spécialisé pstore, destiné à recueillir les derniers mots d'un système à l'agonie, a été intégré au noyau 2.6.39. L'idée derrière pstore est simple. Quand le système se vautre, il est fort utile de connaître la raison du crash afin de pouvoir corriger le problème. Le moyen classique c'est de loguer les derniers messages du système sur le disque pour pouvoir les lire plus tard.
L'ennui de ce schéma, c'est que le crash peut avoir empêché l'écriture des logs sur le disque ou bien tout simplement corrompu les données. Ce serait bien d'avoir une solution alternative qui n'utiliserait pas le disque et - bien entendu - cette option de la dernière chance ne devrait pas être spécifique à une architecture, mais plutôt conçue comme étant la plus générique possible.
Il y a eu plusieurs faux départs puisqu'à l'origine, le code se basait uniquement sur la table ERST (Error Record Serialization Table) de la norme ACPI et l'interaction était réalisée via le système de fichiers virtuel sysfs. Après une suggestion d'Alan Cox, il a été décidé de sauter le pas et de convertir pstore en un vrai système de fichiers.
Par défaut, quand un Oops ou un panic se produit, les dix derniers kilo-octets de logs sont passés, à l'aide de kmsg_dump, au pilote pstore.
Avec cette solution en place, toutes les plates-formes qui disposent d'une petite quantité de mémoire non volatile pourront sauver les derniers messages du noyau. Après un reboot, il suffira de lancer mount -t pstore - /dev/pstore pour aller ensuite lire la sauvegarde de données.
David Miller, le mainteneur de l'architecture Sparc64, a déjà indiqué qu'il allait utiliser ce mécanisme pour implémenter la fonction sur son architecture de prédilection.

Open by handle

La fonctionnalité « Open by handle » qui est décrite dans cet article LWN, a été incluse dans le noyau. Un file handle c'est, en gros, un identifiant numérique qui est attribué par le système lors de l'accès à un fichier. C'est une donnée purement interne qui normalement n'est pas accessible par les applications vivant en espace utilisateur.
Le commit de Aneesh Kumar change la situation puisqu'il ajoute deux nouveaux appels système, qui sont réservés à l'administrateur de la machine, et qui vont permettre à certaines applications d'utiliser directement le handle d'un fichier au lieu de passer par son nom. On va ainsi appeler la fonction name_to_handle_at() pour établir une correspondance entre un nom et le handle et la fonction open_by_handle_at pour ouvrir le fichier en utilisant le handle.
Les noyaux compilés avec CONFIG_FHANDLE permettront donc d'utiliser cette possibilité qui est très utile dans le cas d'un serveur de fichier qui tournerait en espace utilisateur. Le serveur, une version spéciale de NFS par exemple, va pouvoir trouver le handle d'un fichier et le passer directement au système de fichiers sous-jacent qui pourra s'en servir ultérieurement.

Améliorations de LIO

L'infrastructure LIO qui permet de faire du Target iSCSI et qui est entrée lors du cycle précédent, a été améliorée par deux patchs assez conséquents.
C'est tout d'abord le module tcm_ Loop qui a été intégré par Nicholas Bellinger. Ce module permet d'émuler un périphérique SCSI à partir d'un « raw device » c'est-à-dire d'un périphérique en mode bloc qu'on va attaquer directement sans passer par le système des caches de l'OS.
Le second patch ajoute à LIO la possibilité d'utiliser le système de fichiers virtuel configFS pour récupérer des statistiques sur le fonctionnement de l'infrastructure de Target iSCSI. Le message de commit explique bien toutes les données, complexes, qui sont maintenant disponibles.

Device mapper

Le device mapper est la couche logique qui permet par exemple de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode blocs. La fonction de « striping » (c'est à dire l'aggrégation de disques en mode RAID 0) a été complétée par l'ajout des "merge methods" qui augmentent significativement les performances. Alors qu'avant, on pouvait avoir des cas où une seule page était envoyée dans une opération d'entrées/sorties, maintenant, le patch du noyau 2.6.39 prend soin d'utiliser la fonction stripe_merge pour assembler dans tous les cas une plus grande quantité de bios (bloc i/o). Le message de commit indique que ces "merge methods" autorisent des gains en débit de données qui peuvent aller de 12% à 35%.
Toujours en ce qui concerne le "device mapper", on peut citer la nouvelle cible DM nommée "Flakey target". Cette cible permet de générer des erreurs d'entrées/sorties avec des intervalles paramétrables (up interval et down interval). C'est très utile quand on veut tester intensivement des périphériques et le code de gestion d'erreur présent dans le noyau.

Swap MTD

Un pilote générique de swap pour les périphériques MTD (Memory Technology Device) a été écrit par Jarkko Lavinen. La couche MTD s'interpose entre le pilote matériel bas niveau des périphériques utilisant de la mémoire flash et les couches plus hautes du noyau Linux. Ces partitions MTD sont assez souvent utilisées dans le monde de l'embarqué. Le nouveau pilote mtdswap permet maintenant, avec l'option de configuration MTD_SWAP, d'utiliser le périphérique MTD comme si c'était un périphérique classique en mode bloc utilisé pour le swap du système. Comme le support des données est constitué de mémoire flash, une fonction d'étalement des écritures (wear levelling) est incorporée dans le pilote mtdswap.

Systèmes de fichiers

Dans le domaine des systèmes de fichiers présents dans ce nouveau noyau Linux, on notera l'activation par défaut dans ext4 de la fonction « direct bio layer » qui était décrite dans la news du 2.6.37. Cette fonction augmente significativement les performances, mais elle avait été désactivée à la suite d'un bug de corruption de données. Le fix ayant été écrit par Curt Wohlgemuth, et les tests démontrant que le mécanisme était devenu d'une robustesse à toute épreuve, Ted Ts'o a décidé d'activer par défaut la fonction.
En ce qui concerne btrfs, outre l'ajout de points de traçage et l'utilisation de la commande FITRIM qui permet d'optimiser l'utilisation des disques SSD (voir l'explication), on peut relever la nouvelle possibilité de compression par fichier ou par répertoire. Avant ce patch, on pouvait uniquement positionner une option lors du montage du système de fichiers pour lui indiquer d'activer, ou pas, les fonctions de compression et de COW (Copy-On-Write). Le travail de Liu Bo permet maintenant d'utiliser le flag générique FS_IOC_SETFLAGS pour spécifier si on souhaite activer la compression ou le COW pour un fichier ou un répertoire particulier.
Enfin, le code de désallocation des blocs du système de fichiers pour clusters GFS2 a été amélioré par Bob Peterson de façon à ne plus mettre à jour le fichier des quotas et le fichier des statistiques à chaque désallocation. Bob a testé son optimisation en créant 200 fichiers de 100 Mo chacun sur quatre machines en cluster. La suppression simultanée de ces fichiers stresse GFS2 puisqu'il y a compétition entre les ressources. Avec l'ancien code le travail était terminé en 118,6 secondes alors qu'il ne faut plus que 89,4 secondes avec le patch.

Appel système syncfs

L'appel système sync() permet d'ordonner au système de vider tous les caches sur le périphérique de stockage. Grâce à lui on peut s'assurer qu'une donnée a bien été écrite sur le disque et ainsi ne pas se tourmenter pour la cohérence des données.
Tout ça est bien joli, mais un inconvénient de sync(), c'est qu'il oblige à synchroniser tous les systèmes de fichiers qui sont montés sur le système. On ne peut pas en choisir un et ne synchroniser que celui-là…ou plutôt si on peut, mais en rusant et en étant obligé d'avoir des droits root (par exemple en faisant un 'mount -o remount,rw' sur un système de fichiers pour forcer un sync).
C'est pour corriger cette limitation que Sage Weil a créé l'appel syncfs() qui prend en paramètre le système de fichiers qu'on désire synchroniser et qui, tout comme sync(), est un appel non privilégié qui n'est pas réservé à root.

Unicore32

Comme l'a annoncé Linus dans son mail sur la première version candidate, une nouvelle architecture fait son entrée dans la branche principale du noyau. C'est le « Microprocessor Research and Development Center » de l'Université de Pékin qui a conçu cette puce Unicore32. Il s'agit d'un processeur RISC avec un jeu d'instructions mixte 16/32 bits qui vise l'embarqué et qui a été intégré dans divers SoC en Chine. On le retrouve même dans des mini stations de travail fanless comme celle-ci.
On peut certes considérer que cette architecture est extrêmement exotique et que son ajout dans le noyau Linux n'est qu'une anecdote sans importance. Ce serait une erreur puisque cela reflète en réalité la montée en puissance de la Chine et de ses technologies. Qu'il s'agisse d'Unicore32 ou de la puce MIPS/Loongson qui sera au coeur des futurs superordinateurs chinois, il est clair que Pékin a de grandes ambitions et que cette volonté d'indépendance passe par Linux.

Perf

Comme d'habitude l'outil de tracing perf a fait l'objet d'une multitude de patchs améliorant son fonctionnement ou ajoutant des fonctions. C'est un sous-système du noyau qui est en évolution très rapide depuis plusieurs versions et les développeurs s'en donnent à coeur joie.
En vrac on peut citer le support des futurs processeurs AMD Bulldozer, la commande evlist qui liste tous les évènements enregistrés dans un fichier perf.data, la possibilité de filtrer la liste des évènements par catégorie alors qu'avant la commande perf list n'admettait pas d'arguments ou encore l'amélioration du support des compteurs matériels des puces Nehalem.
L'avancée la plus notable est sans doute le patch permettant de ne monitorer qu'un cgroup particulier au lieu de devoir examiner tout le système. Ce nouveau filtrage par cgroup marche avec perf stat comme avec perf record avec la nouvelle option -G et on peut surveiller plusieurs groupes en parallèle en listant leurs noms séparés par une virgule.

Pilotes graphiques

Le noyau 2.6.39 intègre pour la première fois dans sa branche -staging un pilote psb_gfx dédié à la puce graphique GMA500 (plus connue sous le nom de Poulsbo). Le pilote est développé directement par Alan Cox et, même s'il ne dispose pas encore de la 3D accélérée et n'utilise pas les moteurs vidéos matériels de la puce, le code gère le framebuffer ainsi que la 2D. Comme l'explique Kristoffer Ericson le pilote est stable et, si vous n'avez pas besoin de l'accélération 3D, il constitue une alternative tout à fait réaliste à l'ignoble blob d'Imagination Technologies.

Du côté d'AMD peu de nouveautés à noter hormis les patchs de prise en charge des puces HD 6900 (Cayman) et d'activation du tiling pour les puces R600 qui entrent dans le noyau.

Le pilote Nouveau offre maintenant la z-compression c'est-à-dire que les données sur la profondeur sont stockées en mode compressé dans un tampon mémoire spécifique (le z-buffer). Cela permet de savoir si il faut vraiment afficher le pixel ou si ce n'est pas nécessaire parce qu'il est masqué. La technique du « page flipping » est également ajoutée au pilote Nouveau du noyau 2.6.39. Avec cette technique on utilise deux tampons pour la vidéo, l'un qui est affiché sur l'écran (front buffer) tandis que l'autre se remplit (back buffer). Au moment opportun, on bascule d'un tampon à l'autre avec un pointeur ce qui évite de copier des données (qui a pensé aux sprites ?).
Enfin la correction d'un problème de performance permet de gagner d'un seul coup entre 10 et 30% d'images par seconde en plus par rapport aux noyaux précédents.

Pour en terminer avec les pilotes graphiques, en ce qui concerne Intel, on relève plusieurs patchs améliorant la gestion de la puce graphique présente dans le processeur Sandy Bridge (20% de performances en plus dans Nexuiz). Le pilote i855 a également été complètement revu et nettoyé.

Xen

Les développeurs de l'hyperviseur Xen continuent leur combat pour essayer de rejoindre la branche principale du noyau en tant que Dom0 (c'est à dire en mode d'accueil de systèmes invités). Cette fois c'est le pilote réseau générique netback qui entre dans le noyau. Ce pilote permet aux systèmes invités, plus précisément à leurs périphériques réseau paravirtualisés, de communiquer entre eux. C'est une étape importante mais le noyau Linux n'est toujours pas prêt à jouer le rôle d'hôte en Dom0 puisqu'il manque encore des pilotes cruciaux. La situation n'est pas près de changer puisque les hackers du noyau semblent considérer que les développeurs de Xen sont des gorets produisent un code trop invasif. On peut citer l'exemple du pilote générique en mode bloc qui a été proposé sur la LKML par Konrad Rzeszutek Wilk qui travaille chez Oracle. La réponse de Christoph Hellwig a été immédiate :

Tout ça devrait être en espace utilisateur. Et la dernière fois que cela a été discuté Stefano a indiqué que le backend Xen disk de qemu était tout aussi rapide que ce code noyau. Et encore il n'est même pas très optimisé.
Donc de ma part c'est un clair NACK pour l'ajout de tout ce bordel dans le noyau.

Même si Xen Dom0 semble bloqué la partie DomU continue d'avancer régulièrement. Dans cette nouvelle version 2.6.39 on retrouve également le support Xenbus pour les « PM Events ». Cela permet aux systèmes invités (guests) de recevoir les notifications du sous-système de gestion de l'énergie comme par exemple les mises en veille, en hibernation, etc.

KVM

Toujours dans le domaine de la virtualisation, KVM a corrigé un problème de performance ennuyeux. Rik van Riel a constaté que les systèmes invités, et en particulier Windows, souffraient dans certains cas d'une lenteur rédhibitoire ( gigantic slowdown).
Auparavant, quand un thread d'un système invité était bloqué par un spinlock, le processeur prévenait KVM de ce blocage et le code de KVM était conçu pour faire avancer d'autres processus extérieurs au guest. Il a été constaté que cette stratégie était finalement loin d'être optimale et qu'il valait mieux donner du temps de processeur au thread tenant le verrou. Ce renforcement de la priorité du thread s'effectue avec un appel à yield_to() et cela permet de renforcer les chances de déblocage au profit de tout le système.
Un second patch KVM qui vaut la peine d'être evoqué est celui qui s'intitule « asynchronous page faults processing ». Le message de commit est très abscons, mais l'idée est finalement assez simple. Normalement, quand le système invité rencontre un défaut de page, l'hôte interrompt le fonctionnement du guest et s'occupe d'aller chercher la page mémoire requise. L'idée du patch est de ne plus suspendre l'exécution du guest et d'utiliser ce délai pour permettre au système invité de faire avancer un autre thread. Pour cela, l'hôte envoie un message de « défaut de cache asynchrone » et l'invité endort uniquement le thread qui a demandé la page mémoire. Le guest peut donc continuer à faire tourner d'autres threads et n'est plus complètement bloqué. Quand l'hôte fournit la page, alors un signal de réveil est simplement envoyé au thread qui était suspendu.
D'après les tests de Gleb Natapov, et qui sont résumés dans ce fichier pdf, les gains sont très importants. Le protocole se base sur un hôte accueillant quatre machines virtuelles. Sur chacun des systèmes invités, un thread réalise des accès mémoire aléatoires tandis qu'un autre incrémente un compteur. Au bout d'une minute, on regarde le compteur pour voir la quantité de travail qu'a pu effectuer le thread d'incrémentation :
Sans « async page fault » : 129 752 639 953
Avec « async page fault » : 258 846 142 585
Certes, le test est conçu pour bien mettre en évidence les changements induits par le patch…mais un doublement des performances c'est quand même assez spectaculaire !

DMI

La norme DMI (Desktop Management Interface) est une couche d'abstraction qui permet de décrire tous les composants matériels d'un ordinateur. Le noyau Linux contient un décodeur DMI et, grâce à lui et grâce aux infos de SMBIOS, on peut lancer une commande qui va retourner une liste descriptive de la machine. La commande en question, c'est le bien connu dmidecode qui doit être lancé en root.
Pour faciliter l'obtention de ces informations sur le matériel, le noyau Linux 2.6.39 implémente une nouvelle interface /sys/firmware/dmi/. Si le noyau est configuré avec l'option DMI_SYSFS alors un simple utilisateur pourra utiliser les informations présentes dans ce répertoire pour connaître tous les secrets cachés de son ordinateur.

Fenêtre de congestion TCP

Les réglages par défaut de la pile TCP du noyau ont été modifiés dans la nouvelle version 2.6.39.
Le protocole TCP spécifie un algorithme spécial pour découvrir le débit maximum que supporte une connexion. Cet algorithme, nommé « slow start », va commencer par envoyer très peu de données et va progressivement augmenter la cadence jusqu'à la saturation du lien. C'est bien pratique d'avoir ainsi un fonctionnement qui s'adapte aux conditions réelles du réseau… mais les ingénieurs de Google ont récemment signalé un problème. Comme l'indique le nom « slow start », on va commencer en douceur et la fenêtre de congestion (initial congestion window) est très petite au début de la connexion. La limite est de quatre segments, ce qui correspond environ à 4 Ko. Si la durée de connexion est courte, alors cela signifie qu'on n'aura jamais vraiment profité du débit de la ligne puisqu'on sera resté tout le temps en mode « 4 segments ».
Cette limite est donc de nos jours un goulet d'étranglement puisque les réseaux permettent des débits plus importants qu'au moment où a été décidé la limite de congestion (en 2002 dans la RFC 3390). Les tests de Google (voir le pdf de l'article An Argument for Increasing TCP's Initial Congestion Window) ont montré qu'un passage à une fenêtre de congestion à dix segments permettrait de réduire d'environ 10% le temps de latence moyen d'une requête HTTP.
David S. Miller, le mainteneur de la couche réseau du noyau, a donc écrit le patch qui modifie la taille de la fenêtre de congestion et le noyau 2.6.39 est la première version à proposer ce nouveau réglage par défaut.

Algorithmes CHOKe et SFB

Toujours dans le domaine des réseaux, le noyau 2.6.39 accueille deux nouveaux algorithmes de contrôle de la congestion. En effet, quand un lien est saturé, il faut avoir une méthode pour réduire le débit et ce problème du contrôle de la congestion est encore un domaine de recherche actif pour trouver l'agorithme le plus efficace.
Le patch d'intégration de SFB (Stochastic Fair Blue) explique que la stratégie de cet algorithme ne se base plus sur la longueur des queues de paquets des routeurs pour déterminer qu'un engorgement du réseau est en cours. On va plutôt baser les heuristiques sur le nombre de paquets perdus et sur les périodes de veille du lien (link idle events), ce qui est perçu comme plus représentatif.
Le second algorithme intégré dans le noyau adopte une stratégie complètement différente. Portant un nom qui ne peut que faire plaisir au barbare sanguinaire qui sommeille en nous, l'algorithme CHOKe (pour « CHOose and Kill ») va examiner les limites fixées à la longueur des queues de paquets des routeurs. Quand la taille paramétrée est dépassée, on compare le paquet entrant avec un paquet se trouvant déjà dans la queue et choisi au hasard (c'est le CHOose). Si ces deux paquets émanent du même flux, alors il y a une grande chance que le coupable de la saturation du lien soit identifié. On passe alors à l'étape Kill en supprimant sans pitié les deux paquets. Bien entendu si les deux paquets ne sont pas membres d'un même flux, alors on se contente de tuer le paquet entrant.
L'avantage de cette stratégie c'est que le routeur n'a pas a surveiller en permanence l'origine réelle des divers flux (ce qui est très coûteux) puisque l'heuristique pourra identifier le coupable avec une bonne précision en cas de problème.

BKL: That's all folks

Après l'annonce de la fin du « Big Kernel Lock » dans le noyau 2.6.37 les derniers bouts de code obscurs qui l'utilisaient encore ont été impitoyablement traqués. Même si c'est plus pour la beauté du geste qu'autre chose, Arnd Bergmann a converti les derniers récalcitrants : les systèmes de fichiers UFS et HPFS, les protocoles X.25, IPX ou encore Appletalk ont été modifiés pour supprimer toute référence au verrou global.
Certes ce travail est sans doute un peu vain puisque les utilisateurs réels de ces sous-systèmes doivent se compter sur les doigts de la main d'un lépreux. Pourtant le fait de mettre un point final à cette épopée a une certaine valeur en soi. Psychologiquement, même si cela n'a pas de conséquences pratiques, il est important de ne pas laisser des parties délaissées du noyau dépendre du BKL. On peut sentir transparaître la satisfaction du devoir accompli quand on regarde le message de commit d'Arnd. Qu'il s'agisse du fier « That's all Folks », du listing des contributeurs ayant participé à la traque ou encore du statut « deleted file » appliqué au fichier lib/kernel_lock.c, c'est vraiment un commit historique que nous avons là et c'est une page du noyau qui se tourne avec la fin du BKL.

Le bilan en chiffres

Du côté des statistiques de ce cycle, l'article récapitulatif du site LWN pour le 2.6.39 est disponible. On peut également consulter le site remword dédié aux statistiques du noyau Linux pour trouver les principales données quantitatives de cette version (chiffres au 17 mai).

Il est à noter que ce cycle a été particulièrement calme et court. Les régressions signalées sur la LKML ont été peu nombreuses et Linus a publié seulement 7 versions candidates avant de sortir le noyau 2.6.39 définitif. Entre le 14 mars et le 18 mai seulement 64 jours se sont écoulés, ce qui représente le cycle de développement le plus réduit depuis l'import initial dans Git en avril 2005 pour la version 2.6.12-rc2.

En matière de patchs et de nombre de développeurs cette version est un bon cru puisqu'on relève l'intégration de 10 208 patchs écrits par 1 292 développeurs (9 432 patches et 1 201 développeurs pour le noyau 2.6.38). On peut noter qu'environ 670 000 lignes de code ont été ajoutées au noyau et 346 000 lignes supprimées et que le plus gros contributeur individuel est Thomas Gleixner (auteur des patchs sur le sous-système des interruptions évoqué plus haut).
Une donnée toujours importante est celle des primo-contributeurs (les personnes postant un patch pour la toute première fois depuis la bascule vers Git en avril 2005). Ils sont cette fois 310 ce qui constitue le second plus grand total depuis plus de dix cycles.

En termes de contributions par les entreprises, c'est toujours Red Hat qui est en tête, avec Intel en seconde position et Novell juste derrière.
Dans l'article de LWN Jon Corbet indique que la position d'Oracle continue de décliner et il est peut-être intéressant de vérifier cette assertion en regardant de plus près les statistiques. Je me suis donc penché sur les chiffres relatifs aux contributions d'Oracle afin de voir comment évoluent la tendance depuis quelques années. Est-ce que la création d'« Unbreakable Linux » a conduit au développement d'une solide expertise interne ? Est-ce que le nombre de patchs a varié depuis le rachat de Sun en janvier 2010 ? Est-ce que le niveau d'implication dans le noyau est toujours le même ?
Regardons l'évolution depuis le noyau 2.6.27 d'octobre 2008 :

Si on excepte le pic du noyau 2.6.29, qui s'explique par l'intégration de btrfs dans la branche principale, on constate que la tendance est plutôt à la baisse et qu'en termes de patches Oracle semble de moins en moins actif. En termes de rang parmi les autres entreprises contributrices le recul est également perceptible puisque Oracle était régulièrement dans les dix premiers contributeurs alors que depuis le noyau 2.6.33 l'entreprise s'enfonce lentement vers la vingtième place.
Nul doute que ces données quantitatives, et la tendance qu'elles révèlent, sont à prendre en compte par les entreprises qui étudient une transition vers « Unbreakable Linux ».

Pour la suite

En ce qui concerne les futures nouveautés des prochaines versions du noyau, on peut se tourner vers la page spécifique de la Fondation Linux.

ARM : une solution en vue

Les récriminations de Linus Torvalds au sujet de la branche ARM ont été suffisamment sonores pour inquiéter sérieusement les mainteneurs de cette architecture. Quand on lit des phrases comme « Je suis à deux doigts de ne plus accepter aucun patch de certaines personnes à moins que les choses ne s'améliorent » c'est qu'il est grand temps de s'activer afin d'améliorer la situation dans les futurs noyaux.

C'est pour réfléchir à la meilleure stratégie que Linaro, l'organisation à but non lucratif qui rassemble les entreprises intéressées par ARM, a organisé un sommet des développeurs à Budapest au mois de mai. Paul E. McKenney a résumé les échanges dans plusieurs posts successifs sur son blog (1 - 2 - 3).
Il semble que les développeurs ARM vont essayer de migrer le maximum de sous-architectures vivant dans /arch/arm/* vers le répertoire /drivers/*. Cela permettra de fusionner plusieurs pilotes quasi-identiques et de partager davantage de code entre les divers SoC. Un travail de fond pour consolider le code des sous-architectures est également lancé. Qu'il s'agisse de la gestion des horloges, de cpufreq ou cpuidle, de l'unité de gestion de la mémoire (IOMMU), des gestionnaires d'interruptions, etc. Chacun de ces points a été examiné soigneusement pour ne plus dupliquer le travail et le code.
Quelques patchs d'unification vont rejoindre le noyau dès la version 2.6.40 mais c'est vraiment à partir du 2.6.41 que les choses vont s'accélérer avec la mise en place d'un « device tree » descriptif pour les cartes ARM et les SoC.
Un dépôt Git spécifique va être mis en place avec des accès pour les principaux responsables ARM (Arnd Bergman, Nicolas Pitre, Marc Zyngier, Thomas Gleixner et Russell King) et des branches pour chacune des sous-architectures. Cela permettra de proposer à Linus des branches propres à importer vers le noyau.
Selon Paul E. McKenney cette nouvelle organisation n'est certainement pas la solution ultime au problème ARM mais elle montre que les développeurs Linux sont conscients du problème et ont commencé à s'y attaquer :

Il y a une quantité de code incroyable dans le répertoire ARM de Linux, et une quantité effrayante qui est générée chaque jour : plus d'un quart de million de lignes par an selon certaines estimations.
Il serait trop facile de conclure que la situation actuelle est un désastre complet. Au contraire, ceux d'entre nous qui sont là-dedans depuis un certain temps verront ça comme une grosse amélioration par rapport à la période maudite où les développeurs de l'embarqué gardaient leurs patchs pour eux. Nous dans la communauté du noyau Linux nous leur avons demandé de soumettre leurs patchs et ils ont commencé à le faire. Il est donc temps pour nous de comprendre comment nous allons pouvoir boire à cette lance à incendie ;-)

Aller plus loin

• Les nouveautés du noyau 2.6.39 (2005 clics)
• LWN : Le bilan des ajouts partie 1 (350 clics)
• LWN : Le bilan des ajouts partie 2 (159 clics)
• LWN : Le bilan des ajouts partie 3 (162 clics)