Nouvelle version 2.6.35 du noyau Linux

La sortie de la version stable 2.6.35 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 (qui est sous licence CC BY-SA).

Le sommaire...

• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
• Les nouveautés
  • Fonction cpu_stop
  • Gestion de l'énergie
  • Compactage mémoire
  • Le réseau avec RPS et RFS
  • Qualité de service avec pm_qos
  • Gestion des interruptions
• En bref
  • Arbres bicolores
  • Fonction truncate
  • ramoops
  • btrfs
  • Pilote radeon
  • Pilote intel
  • OCFS2
  • Couche VFS
  • defconfig ARM
  • splice et FUSE
  • md et RAID
  • Hash CRC-32
  • AES-NI en mode CTR
  • Support APEI
  • Monitoring
  • GTSM pour IPv6
• Documentation technique et maintenance du code
  
• Le bilan en chiffres
  
• Pour la suite
  
  • Suspend blockers

La phase de test (↑)

RC-1

Quinze jours après la sortie du noyau 2.6.34, Linus Torvalds a annoncé le 30 mai l'arrivée de la première version candidate RC-1 : « Cela fait deux semaines et donc la période de merge est fermée. Et s'il vous plaît essayons de respecter ça cette fois. Ne m'envoyez plus aucune demande, à part si c'est pour corriger une vraie régression ou un bug majeur, OK ? Cette fois il n'y a pas de nouveau système de fichiers (surprise, surprise) mais il y a évidemment eu du boulot sur les systèmes existants (btrfs, ceph, cifs, ext4, nfs, ocfs2 et xfs) ainsi que sur la couche VFS (nettoyage sur les superblocks et les quotas en particulier). Mais comme d'habitude le gros des changements se trouve dans les pilotes. Environ les deux tiers des changements pour être exact. Les pilotes infiniband, réseau ou staging représentent la plus grande part mais il y a des commits un peu partout : drm, son, media, usb, périphériques d'entrée, etc. Ce qui est réconfortant, c'est de constater que nous continuons d'avoir de bonnes statistiques avec environ 8 500 commits et presque 1 000 développeurs différents. Bien entendu c'est biaisé puisque la médiane de commit par personne est de seulement trois… mais je pense que c'est exactement ce que nous voulons voir dans un environnement de développement en bonne santé ».

RC-2

Le 5 juin c'est la RC-2 qui a fait son apparition et Linus a annoncé que le cycle de développement allait être un peu différent cette fois-ci du fait de contraintes personnelles : « Bon la RC-2 est disponible et, je l'espère, elle corrige plus de problèmes qu'elle n'en introduit. Je ne suis pas très content de sa taille. C'est vrai qu'elle n'est pas aussi grosse que la RC-2 du cycle précédent mais cette dernière était vraiment inhabituelle. J'espérais vraiment un cycle de release plus calme cette fois-ci. En fait je vais forcer la RC-3 à être saine parce que la semaine prochaine est la dernière semaine d'école pour mes enfants. Et quand les gosses ne vont plus être à l'école je vais être off-line pour un moment. Je ne veux _vraiment_ pas intégrer le moindre truc un peu effrayant pour cette RC-3. Les demandes de pull ont intérêt à être uniquement pour des corrections de bugs parce que cette fois je ne laisserai rien passer d'autre ».

RC-3

Linus a tenu parole et il a été particulièrement strict dans son acceptation des patchs soumis pour la RC-3 du 11 juin. De nombreux développeurs se sont vus opposer des refus fermes et ceux qui mélangeaient les corrections et les nouvelles fonctions dans leurs branches ont été vivement rabroués (« Tu as deux heures pour m'envoyer une demande de merge ne contenant que les corrections de bugs si tu veux faire partie de la RC-3 »). Cette politique a payé puisque le delta entre la RC-2 et la RC-3 est particulièrement réduit : « J'ai été intraitable pendant une semaine, peut-être même un peu trop, et ça veut dire que la RC-3 sera meilleure que ne l'était la RC-2. Non seulement nous avons eu des corrections de régressions mais en plus nous n'avons plus ce bug stupide de corruption mémoire qui a touché tellement de gens de diverses façons (selon la zone mémoire aléatoire qui était corrompue). Une des conséquences de mon inflexibilité est que cette RC-3 est sans doute la plus petite que nous ayons eu depuis longtemps. Le diff ressemble à ça : "165 files changed, 1624 insertions(+), 859 deletions(-)". En tout 159 commits, et le plus gros des changements consiste juste en des déplacements de fonctions dans iwl-agn.c plutôt qu'en de vraies modifications de lignes. Donc testez bien ! ».

RC-4

Pendant que Linus faisait de la plongée en famille les amateurs de nouvelles versions candidates ont dû se morfondre puisqu'il a fallu attendre durant une loooongue période de plus de trois semaines pour voir finalement apparaître, le 4 juillet, la version RC-4 : « Hé les gars, il y a finalement une nouvelle RC disponible. Je suis rentré depuis une semaine et, à en juger par le genre de patchs et de demandes de pull que j'ai reçu, je dois dire que le fait d'avoir été strict pour la RC-3 a bien fonctionné. Le diff entre les deux RC est très raisonnable et j'espère que nous aurons un 2.6.35 dans les temps en dépit de mes vacances. C'est ma plus grande période loin du noyau depuis plusieurs années je crois. J'ai suivi mes mails sur mon téléphone mais je n'ai pas fait la moindre compilation et j'ai pris du bon temps sous l'eau ».

RC-5

Après ses vacances de sybarite, Linus est revenu à un rythme plus habituel et a annoncé la disponibilité de la RC-5 le 12 juillet : « Nouvelle semaine, nouvelle RC. OK en fait ça fait huit jours mais bon. C'est tant mieux puisque j'ai pu merger des corrections supplémentaires aujourd'hui (des problèmes de son et des régressions dans V4L). Et j'ai aussi mergé le patch de minimisation defconfig de la branche ARM. Ce n'est que le début des changements dans defconfig mais comme ce patch supprime presque 200 _mille_ lignes c'est quand même un sacré truc. J'espère que ça va continuer et que nous aurons beaucoup moins de bruit defconfig dans nos futurs diffs et, on l'espère, aussi des nettoyages de code ».

RC-6

C'est le 22 juillet dernier que Linus a annoncé la sixième version candidate du noyau 2.6.35 : « Bon je pense/j'espère que ce sera la dernière RC. Les choses ont été vraiment calmes et, même si cette RC a plus de commits que la RC-5 n'en a eu, ce n'est pas de beaucoup et rien ne me semble effrayant. Donc à ce stade ça ne rime à rien de faire traîner les choses pour cette version à moins que nous ne découvrions un truc bloquant. En plus, un des bugs corrigés dans cette RC-6 semble être un gros poisson. Le commit "Enable low power render writes on GEN3 hardware" de Dave Airlie pourrait être la solution pour le vieux problème de freeze sur certaines cartes Intel GM945. Donc, en dépit du fait que le commit ne fait qu'une ligne, cela pourrait être un truc assez important pour les gens ».

Les nouveautés (↑)

La fonction cpu_stop

Créé par le développeur Tejun Heo, le mécanisme de cpu_stop a été incorporé dans le nouveau noyau. D'abord proposé sous le nom cpuhog en mars dernier, la fonction a été renommée à la demande de Peter Zijlstra car le nouveau nom de cpu_stop permet de faire le lien avec la fonction stop_machine. On a gagné en clarté sur l'utilité de la fonction (on comprend que c'est lié à stop_machine) mais on a un peu perdu de vue le mécanisme lui-même puisqu'en réalité cpu_stop ne stoppe pas le processeur ! Ce que fait ce patch, quand on fait appel à la fonction stop_one_cpu() qu'il propose, c'est qu'il monopolise à 100% un processeur particulier sans laisser aucun autre processus y accéder. Cela peut sembler un peu bizarre de vouloir faire ça, mais en fait nous allons voir que c'est très utile dans certains cas. Par exemple, pour la fonction stop_machine, qui est utilisée quand on veut tout figer sur un ordinateur avant de changer quelque chose de très important, comme par exemple remplacer un processeur, insérer des sondes dynamiques, etc. : jusque là cette fonction utilisait un mécanisme ressemblant quelque peu à cpu_stop (les workqueues) puisqu'elle faisait tourner un thread à haute priorité sur les divers processeurs. Le passage à cpu_stop permet, outre une factorisation du code, de corriger des dysfonctionnements sur les très grosses machines comme par exemple un temps de boot exagérément long. Dimitri Sivanich rapporte qu'un système SGI UV de 1024 processeurs passe de 30 minutes à seulement 12 lors d'une utilisation de stop_machine. Le mécanisme de migration de thread qui — comme son nom l'indique — prend un processus sur un processeur et le migre sur un autre processeur, est lui aussi modifié pour reposer sur cpu_stop. En effet, la première phase de la migration implique de faire sortir le thread du processeur. Quoi de mieux pour cela que de faire appel à cpu_stop qui monopolise le processeur pour lui tout seul ! On voit bien que le travail de Tejun Heo, outre le fait qu'il offre une nouvelle possibilité aux développeurs, permet surtout de nettoyer toutes les implémentations disparates (dans stop_machine, dans le migration thread etc.) et de les remplacer par un code sous-jacent unique et performant.

Gestion de l'énergie

Le sous-système cpuidle du noyau 2.6.35 a été modifié par deux patchs notables qui vont permettre de mieux gérer la consommation d'énergie des processeurs de nos machines. – Le premier patch a été écrit par Len Brown qui travaille chez Intel et qui s'occupe habituellement du code noyau permettant la gestion de l'ACPI. Constatant que les tables ACPI de sa machine Dell étaient complètement fausses, et que chez les autres constructeurs ce n'était guère plus brillant, il a décidé d'écrire un pilote spécifique afin de corriger le problème. La norme ACPI s'occupe de gérer la consommation d'énergie des composants d'un ordinateur par l'intermédiaire de tables descriptives (Differentiated System Description Table) et d'un langage spécifique (ACPI Machine Language). Cette norme est extrêmement complexe et elle a été critiquée à de nombreuse reprises par les développeurs du noyau. Les constructeurs ne semblent pas faire preuve d'une grande fiabilité dans l'écriture des tables ACPI qui sont livrées avec leurs machines et cette situation énerve au plus haut point les développeurs Linux qui sont obligés de passer du temps à contourner ces tables ACPI fautives. Avec sa franchise habituelle, Linus Torvalds a fait connaître son sentiment sur cette norme (« ACPI was designed by a group of monkeys high on LSD ») mais, en dépit de cette mauvaise humeur, il a bien fallu se résoudre à la prendre en charge du fait de son universalité. Le travail de Len Brown est toutefois original car, avec ce patch spécifique, il a choisi d'écrire un pilote spécial, nommé intel_idle, qui gère tous les processeurs de type Nehalem et Atom. Ce pilote ne dépend pas des tables ACPI et n'est donc pas impacté par un bug qui existerait dans celles-ci. Avec intel_idle, la machine se comportera correctement même si les tables ACPI sont fausses puisque seul le pilote Linux sera utilisé. En outre, les tables ACPI indiquent seulement (quand elles sont justes) le temps de latence de sortie d'hibernation alors que, selon Len Brown, l'information réellement pertinente est le seuil de consommation. Il a bien entendu pris soin d'indiquer ce seuil dans son pilote. Sur l'ordinateur Dell de Len, du fait d'un bug de la table ACPI, le processeur ne pouvait pas entrer dans un état d'hibernation plus profond que C1 et le mode Turbo était désactivé. Avec son patch spécifique intel_idle, le processeur peut entrer en hibernation dans tous les modes profonds (ce qui fait passer la consommation de 100 Watts à 85 Watts) et le mode Turbo fonctionne à nouveau. À noter que ce pilote est marqué EXPERIMENTAL pour le moment, mais Len Brown prévoit d'enlever cette marque dans le prochain noyau. – Le second patch modifiant les fonctions de gestion de l'énergie du noyau Linux 2.6.35 a été écrit par Arjan van de Ven, grand spécialiste de ce sujet puisqu'il est l'auteur de PowerTOP et de l'initiative Lesswatts.org. La fréquence du processeur d'une machine sous Linux est gérée par un « gouverneur » qui est chargé de prendre les meilleures décisions possibles. Quand le processeur n'a rien à faire, c'est l'infrastructure cpuidle qui est utilisée et qui gère le degré d'endormissement du processeur. Il doit choisir entre les fameux « C-States » pour ordonner au processeur de faire juste une sieste rapide (par exemple passer en C1) ou bien de jouer la belle au bois dormant en sommeil cryogénique (l'état C6 sur les machines modernes). L'ennui, c'est que ce gouverneur cpuidle n'a pas la possibilité de prédire le futur (c'est bien dommage) et qu'il ne sait pas à quelle quantité de travail le processeur aura à faire face à l'instant suivant. Il en est réduit à faire des prédictions sur le temps pendant lequel le processeur n'aura rien à faire (le temps pendant lequel il sera en « idle »). Pour prendre sa décision sur le degré d'endormissement idéal (le choix du C-State), le gouverneur se sert tout simplement du timer de la machine. Il évalue combien de temps il reste avant le prochain timer afin de savoir si il est rentable ou pas d'endormir le processeur dans l'état C1, C2 etc. Ce qui est ennuyeux avec cet algorithme, c'est que le prochain timer ne donne qu'une borne supérieure et que le processeur peut être réveillé bien avant par d'autres événements (une interruption matérielle par exemple). Ce qui serait bien, ce serait de pouvoir prédire également ces interruptions mais cela n'est, hélas, pas vraiment possible. Sans se laisser décourager par ce triste constat, Arjan a décidé que le noyau pouvait au moins détecter les interruptions répétitives. Pour cela le patch ajoute une fonction de mémorisation qui stocke les huit dernières interruptions et les compare à un seuil prédéfini. Avec cet algorithme très simple, il est possible de détecter des profils d'interruptions répétitifs comme, par exemple, le déplacement d'une souris, les charges réseau utilisant la fonction d'irq mitigation ou encore l'envoi de trames Wi-Fi de type beacon. Le patch d'Arjan améliore le taux de bonnes prédictions du gouverneur cpuidle et, dans son message sur la LKML, Arjan présente certains chiffres très encourageants. Par exemple avant le patch seulement 43.6% des prédictions de durée de idle étaient précises à un facteur 4 près par rapport à la réalité. Après l'application du patch, ce taux passe à 75.2% et l'infrastructure « cpuidle » peut donc endormir le processeur à meilleur escient.

Compactage mémoire

Le patch de compactage mémoire écrit par Mel Gorman a été accepté dans le noyau Linux 2.6.35. Tout d'abord, il ne faut pas confondre ce patch avec le mécanisme ramzswap qui avait été évoqué dans la dépêche du noyau 2.6.33. Ramzswap est là pour augmenter artificiellement la capacité mémoire d'une machine grâce à la compression d'une partie des pages mémoires (par exemple on a 256 Mo de RAM, mais le système se comporte comme si on avait 512 Mo). De son côté, le but du patch « Memory compaction » de Mel Gorman est de réduire la fragmentation de la mémoire. En effet, après la phase d'allocation de la mémoire à un processus, les pages mémoires occupent des blocs physiques qui sont ensuite libérés lors des désallocations. Au fil du temps, la mémoire se retrouve fragmentée et le stock de blocs contigus libres se réduit. Pourtant, dans certains cas il est très important, voire absolument nécessaire, d'allouer une quantité de mémoire contiguë. Par exemple, le tampon DMA de nombreux périphériques réclame une quantité de mémoire contiguë. Du point de vue des performances, l'accès à de la mémoire non fragmentée peut également faire une grosse différence. En outre, le problème de la fragmentation peut empirer dans certains cas car les processeurs ne se limitent pas à des allocations de 4 Ko et ils peuvent — si l'OS le gère — utiliser le mécanisme des « huge pages » pour allouer d'un seul coup de grandes quantités de mémoire dans l'espace d'adressage. Évidemment, le taux de succès de l'allocation de ces « huge pages » dépend de façon critique de l'existence de zones mémoire contiguës et rend plus désirable que jamais une fonction de défragmentation. Le travail de Mel Gorman sur la réduction de la fragmentation mémoire a commencé il y a longtemps et a progressé à petit pas car le code de la mémoire virtuelle est notoirement complexe et sensible. Après son travail de 2006 sur les pages déplaçables (« GFP_MOVABLE ») il propose cette fois un mécanisme simple mais efficace de défragmentation. L'idée est de lancer deux scanneurs de pages au sein d'une zone mémoire. Le premier algorithme (nommé le « migration scanner ») démarre au début de la zone et liste toutes les pages déplaçables qui existent dans la zone (en se servant justement du flag GFP_MOVABLE). À chaque fois qu'il rencontre une page déplaçable, il l'ajoute à la liste migratepages. Le second algorithme (le « free scanner ») est lancé à partir de la fin de la zone mémoire et il recherche toutes les pages libres susceptibles d'accueillir des données. Quand il en trouve, il y déplace les pages listées dans la migratepages. Chaque algorithme progresse le long de la zone un peu comme pacman (c'est la phase de « compaction run ») et quand ils finissent par se rencontrer le travail est fini ! Le parcours des deux algorithmes ressemble donc un peu à ce chef-d'œuvre d'ascii-art : Début : [OO] Compression en cours : [-----OO------] Fin : [------------O<>O-------------] Selon les mots de Mel Gorman : « La méthode est un peu primitive, mais elle est simple à comprendre et une plus grande sophistication aurait impliqué des compteurs sur chaque pageblock. Cela aurait eu un gros impact sur le code d'allocation et cela seulement pour améliorer le compactage. Le compromis n'aurait pas été bon ». Pour lancer une défragmentation mémoire il existe trois méthodes :

• Tout d'abord on peut défragmenter toute la mémoire en écrivant 1 dans /proc/sys/vm/compact_memory. Mel indique que cette méthode peut être utile, par exemple, pour un job scheduler qui va défragmenter toute la mémoire pour préparer le système et le placer dans un état optimum avant de lancer une application ;
• Ensuite, plus raffiné, on peut compacter juste un nœud en écrivant dans /sys/devices/system/node/nodeN/compact (on remplace N par l'identifiant du nœud) ;
• Enfin, si le noyau a été compilé avec l'option CONFIG_COMPACTION, le mécanisme de défragmentation se déclenche automatiquement en cas d'échec lors d'une allocation mémoire demandant plusieurs pages contiguës (c'est ce qu'on appelle des « high-order pages »). Dans ce dernier cas, la défragmentation s'arrête dès que l'allocation redevient possible (pas besoin d'attendre que les deux scanneurs se rencontrent).

Mel Gorman a effectué plusieurs tests différents qui sont détaillés dans son message sur la LKML. Le plus stressant pour le système consiste à lancer plusieurs compilations du noyau en parallèle (de façon à remplir la mémoire avec un mix de pages déplaçables ou pas) tout en essayant d'allouer 90 % de la mémoire en « huge pages ».

• Taux de succès de l'allocation sur x86 avant le patch : 98 %
• Taux de succès de l'allocation sur x86 après le patch : 99 %
• Taux de succès de l'allocation sur x86-64 avant le patch : 95 %
• Taux de succès de l'allocation sur x86-64 après le patch : 98 %
• Taux de succès de l'allocation sur PPC64 avant le patch : 55 %
• Taux de succès de l'allocation sur PPC64 après le patch : 70 %

On voit bien que le pourcentage de succès des allocations de page est plus important après l'application du patch de défragmentation écrit par Mel Gorman. Un échec d'allocation étant très pénalisant, chaque point de pourcentage gagné se traduit par une amélioration des performances, pour le plus grand bénéfice de nos machines.

Le réseau avec RPS et RFS

Les patchs Receive Packet Steering et Receive Flow Steering qui améliorent les performances réseau ont été acceptés par Linus et incorporés dans la pile réseau du noyau 2.6.35. Le problème auquel les ingénieurs de Google ont choisi de s'attaquer à travers ces deux patchs est simple à énoncer : cette firme n'utilise pas de matériel exotique, mais plutôt des machines standard en grand nombre. Ces ordinateurs ont certes des processeurs multi-cœurs, mais leur carte réseau lambda ne peut traiter qu'une seule queue de paquets réseau à la fois. Comment faire pour utiliser au mieux un processeur multi-cœurs quand on a une carte réseau mono-queue ? Le problème ne se pose réellement que pour les paquets entrants. Pour ceux qui sortent, le système sait déjà comment découper son travail entre les processeurs avant d'envoyer ses ordres à la carte réseau (NIC). En revanche, le flot en entrée vient d'une seule source (la queue unique gérée par la carte réseau) et il est difficile de le découper intelligemment afin de distribuer la charge sur les divers cœurs de calcul. La solution évidente serait de changer de carte réseau pour en acheter une qui gère de multiples queues en parallèle… mais Google ne veut en aucun cas acheter des machines qui sortent de l'ordinaire et doit donc résoudre ce problème avec du matériel standard et donc avec une NIC mono-queue. Quand on ne peut ou veut pas changer le matériel, alors la seule solution c'est d'améliorer le logiciel. L'équipe Google de Tom Herbert s'est donc attelée à la tâche et a produit le patch Receive Packet Steering. Quand un paquet arrive, le nouveau code s'occupe de traiter aussi vite que possible l'en-tête (le header) pour pouvoir connaître l'adresse IP et le port utilisés. Une fois que c'est fait, on fabrique une empreinte de cet en-tête (un hash) afin de pouvoir l'affecter à un processeur particulier. La liste des processeurs utilisés peut se configurer en écrivant dans /sys/class/net/eth0/rps_cpus (l'exemple est pour une carte eth0 bien entendu). La solution du Receive Packet Steering est donc conceptuellement assez simple, puisque le hash permet de s'assurer que les divers paquets d'un même flux seront routés vers le même processeur. En fait, la fonction Receive Packet Steering émule un NIC multi-queues et distribue le travail sur les architectures multi-cœurs. Le code de Google est quand même un peu plus subtil que ça, puisqu'il peut souvent se passer de calculer lui-même le hash. C'est une opération coûteuse, car on ne peut pas garder le calcul dans le cache du CPU. Chaque paquet entrant est différent et entraîne donc des « défauts de cache » (cache miss) qui sont très préjudiciables pour les performances. De nombreuses cartes réseau récentes calculent toutes seules le hash des paquets et le patch RPS utilise ce travail pour router gratuitement les paquets, sans avoir à calculer lui-même cette empreinte (le champ rxhash a été ajouté à la structure de la pile réseau Linux). Côté performances, les résultats sont très impressionnants. Tom Herbert a procédé à divers tests et ses benchmarks donnent les chiffres suivants (pour le test netperf TCP_RR) : Carte de type e1000 sur machine 8 cœurs Intel :

• Sans patch : 90 000 transactions/s avec 34 % d'utilisation des CPU ;
• Avec patch RPS : 292 000 transactions/s avec 66 % d'utilisation des CPU.

Carte de type forcedeth sur machine 16 cœurs AMD :

• Sans patch : 117 000 transactions/s avec 10 % d'utilisation des CPU ;
• Avec patch RPS : 327 000 transactions/s avec 29 % d'utilisation des CPU.

Afin de gagner encore un peu en performances, l'équipe de Google a proposé un second patch nommé Receive Flow Steering. L'idée est astucieuse : quand une application en espace utilisateur lance des appels système de type recvmsg() ou sendmsg() (NdM: remplacement par des liens archive.org), on peut soupçonner qu'elle traite des paquets réseau et donc on stocke l'information sur le CPU qui fait tourner cette application. Une fois cette information stockée, on utilise le mécanisme Receive Packet Steering décrit plus haut mais, cette fois-ci, on ne route pas les paquets vers un processeur choisi au hasard. On les envoie directement sur le même cœur de calcul que celui de l'application. Le bénéfice de ce patch, c'est qu'il améliore la « proximité des données » (CPU locality) entre le flot de paquets entrants et l'application traitant ces données. C'est tout bénéfice pour l'augmentation du débit et la réduction de la latence. Bien entendu, la réalisation technique de cette idée astucieuse est plus compliquée qu'on ne le croit (comme souvent dans le monde du noyau). Les développeurs ont dû tenir compte de la possibilité d'avoir des paquets réseau dans le désordre (out-of-order packets). Pour éviter ça, il y a en réalité deux tables contenant les hashs des processeurs (rps_sock_flow_table et rps_dev_flow_table) et lors du choix, par appel à la fonction get_rps_cpu(), une comparaison est réalisée pour éviter d'avoir un mélange des paquets réseau. Tom Herbert dans son message sur la LKML précise que les gains de performances sont variables et dépendent de la hiérarchie des mémoires caches ainsi que de la charge de l'application. Il a donné les chiffres suivants (toujours pour le test netperf TCP_RR) : Carte de type e1000 sur machine 8 cœurs Intel :

• Sans patch : 104 000 transactions/s avec 30 % d'utilisation des CPU ;
• Avec patch RPS : 290 000 transactions/s avec 63 % d'utilisation des CPU ;
• Avec patch RPS+RFS : 303 000 transactions/s avec 61 % d'utilisation des CPU.

On voit que le gain est moins spectaculaire que pour la fonction Receive Packet Steering, mais qu'il reste tout à fait substantiel. Sur un autre test (request/response avec 100 threads sur chaque host) le bénéfice est plus marqué, puisque l'application en espace utilisateur est plus chargée : Carte de type e1000 sur machine 8 cœurs Intel :

• Sans patch : 103 000 transactions/s avec 48 % d'utilisation des CPU (latence max 3 185 µs) ;
• Avec patch RPS : 174 000 transactions/s avec 73 % d'utilisation des CPU (latence max 2 468 µs) ;
• Avec patch RPS+RFS : 223 000 transactions/s avec 73 % d'utilisation des CPU (latence max 1 382 µs).

Ces patchs tournent depuis longtemps sur les noyaux des machines Google dans les fermes de serveurs, donc on peut penser que le code est robuste. Le bond des performances pour les machines ayant un NIC mono-queue est considérable et ces deux fonctions RPS et RFS constituent donc l'une des grandes nouveautés de ce noyau.

Qualité de service avec pm_qos

L'infrastructure pm_qos (Power management – Quality of service) a été modifiée dans le nouveau noyau 2.6.35. Cette infrastructure est utilisée pour spécifier au noyau Linux quelles sont les latences à respecter quand il essaye d'économiser de l'énergie. En effet, un noyau trop agressif dans ses actions en vue d'économiser l'énergie peut générer des latences désagréables. Avec pm_qos on peut indiquer au noyau d'économiser au maximum les watts, mais tout en respectant les exigences de latence ou de débit d'une ou plusieurs applications particulières. Par exemple, on peut demander au noyau de faire son travail d'économie tout en respectant une latence maximum de 50 millisecondes pour l'application mplayer. Il y a trois paramètres sur lesquels on peut jouer :

• Latence du processeur (en µs) : PM_QOS_CPU_DMA_LATENCY ;
• Temps de réponse réseau (en µs) : PM_QOS_NETWORK_LATENCY ;
• Débit réseau (en Ko/sec) : PM_QOS_NETWORK_THROUGHPUT.

Dans le nouveau noyau, l'API interne permettant d'accéder à pm_qos a été changée. Avant, on utilisait pm_qos_update_requirement() et on devait envoyer une chaîne de caractères pour spécifier la qualité de service désirée. Évidemment, le fait d'envoyer une chaîne de caractères signifie que le noyau doit parcourir une liste et doit effectuer des comparaisons de chaînes de caractères. Ce sont des opérations qui prennent du temps et ce n'est clairement pas optimal de faire ça quand on veut justement spécifier une latence minimale ! Mark Gross a proposé un patch qui change ce comportement afin que le noyau puisse parcourir le code critique (le hot path) plus rapidement. La nouvelle API s'utilise avec pm_qos_update_request() et la spécification de la qualité de service se fait avec un pointeur (un handle), ce qui évite le parcours d'une liste et la comparaison de chaînes de caractères. Cette modification, modeste en elle-même, est encore un exemple de la politique de changement des API internes du noyau qui caractérise Linux. Comme les pilotes sont intégrés dans le noyau, il est judicieux d'améliorer les API internes puisqu'on peut simultanément mettre à jour les pilotes utilisant cette API. Ainsi, le noyau s'améliore sans avoir à traîner des couches de compatibilité pénalisantes.

Gestion des interruptions

Le noyau 2.6.35 a désactivé la fonction permettant la création d'interruptions « lentes » et il fonctionne maintenant uniquement avec des interruption « rapides ». Pour comprendre de quoi il s'agit, il faut savoir que les divers périphériques peuvent interrompre le processeur dans son travail à tout moment. Ces interruptions s'effectuent quand le matériel a besoin d'une action urgente de la part du système. Cela peut-être dans le cas d'une entrée/sortie, de l'avancement d'une horloge, d'un défaut matériel, etc. Le mécanisme des interruptions est astucieux, car il permet au processeur de faire son travail normal d'exécution d'un programme sans s'occuper du reste. Si un évènement requiert son attention, alors il sera 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 le programme en cours d'exécution est suspendu et la main passe au gestionnaire des interruption (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 le main au programme qui était suspendu. Tout ça c'est la théorie mais, comme souvent, le monde réel se révèle plus compliqué. Parfois même beaucoup plus compliqué ! En réalité, il n'y a pas qu'un seul type d'interruptions mais deux. Tout d'abord, il y a les interruptions « rapides » qui ne peuvent pas être elles-mêmes interrompues par une autre interruption. Le second type d'interruption, les « lentes », a une notion de priorité et elles peuvent donc être interrompues par une interruption de plus haute priorité.

Interruption « rapide » :

Ininterruptible

Interruption « lente » :

Peut être interrompue

Les programmeurs ont été obligés de créer les interruptions « lentes » car ils ne pouvaient pas se permettre de monopoliser le processeur quand l'action requise par le périphérique devait durer un certain temps. Bien entendu, ces interruptions « lentes » sont une complication dont on aimerait bien se passer. Leur gestion occupe de la place sur le cache du CPU et leur temps de complètement n'est pas prédictible car elles peuvent être stoppées par une interruption de plus haute priorité. En outre, s'il y a trop de niveaux de priorités qui s'imbriquent, alors il peut en résulter un débordement de la pile d'interruption (interrupt stack). Ce bug de débordement de la pile a déjà été observé quand des cartes réseaux multi-queues envoient toutes leurs interruptions sur un seul processeur. Pour toutes ces raisons, certains développeurs comme Thomas Gleixner ont pensé qu'il était devenu désirable de trouver un moyen de supprimer les interruptions « lentes » et d'avoir un noyau fonctionnant exclusivement avec les interruptions « rapides ». L'ennui, c'est que Linus Torvalds s'est empressé de démolir l'idée en soulignant que les interruptions « lentes » étaient certes une plaie, mais qu'à son avis on ne pouvait pas faire sans elles. Selon lui, quand l'interruption implique beaucoup de travail à réaliser et que le processeur n'est pas un foudre de guerre, il n'est pas envisageable de déclencher une interruption ininterruptible (« rapide » donc) qui monopoliserait le CPU pendant de longues périodes et induirait de la latence. En outre, de nombreux pilotes sont écrits en se basant sur l'idée que les interruptions « lentes » existent, donc la suppression de ces interruptions gérant la priorité entraînerait de nombreux dysfonctionnements. Linus a écrit ses mails avec sa véhémence habituelle, mais au fil de la discussion et des échanges d'invectives d'arguments, il a fini par infléchir sa position. C'est Ingo Molnar qui a réussi à le convaincre en signalant que les noyaux faisant tourner l'outil lockdep, comme ceux utilisant un cadencement dyntick, fonctionnaient déjà avec uniquement des interruptions « rapides ». La branche RT (Real Time) de Linux a également bien débroussaillé le code et corrigé la plupart des pilotes nécessitant des interruptions « lentes ». En ce qui concerne l'argument de la latence, il a été répondu à Linus que les processeurs modernes sont suffisamment rapides et peuvent effectuer une grande quantité de travail pendant un temps donné. Le déclenchement d'une interruption qu'il ne serait pas possible de préempter ne devrait donc pas avoir de conséquence sur le temps de latence. En outre, les périphériques modernes sont plus évolués qu'avant et ils ne génèrent plus autant de travail à faire donc les interruptions « lentes » sont moins utiles. Ingo s'est engagé à ce sujet : « Je suis assez sûr, après avoir examiné le truc sous plein d'angles différents, que la désactivation des interruptions « lentes » dans tous les pilotes devrait fonctionner correctement dès aujourd'hui ». Linus, voulant quand même en avoir le cœur net, a vérifié certains pilotes pour savoir s'ils pourraient effectivement fonctionner avec un noyau sans interruptions « lentes ». Ayant constaté qu'Ingo et Thomas avaient raison et lui tort, il a donc tout simplement changé d'avis. C'est un évènement qui mérite d'être noté parce qu'il est fort rare que Linus se trompe sur un point technique. C'est rassurant de voir que lorsque cela arrive, il accepte simplement et sans façon de se ranger à l'avis de ses contradicteurs. Un patch a donc été écrit par Thomas Gleixner pour neutraliser le flag IRQF_DISABLED qui servait à passer en mode ininterruptible. Comme maintenant toutes les interruptions sont définies comme « rapides », ce code devient inutile. Le flag IRQF_DISABLED est maintenant marqué comme DEPRECATED dans le code du noyau Linux et il est désactivé puisqu'il exécute juste une opération NOP. Son retrait interviendra dans une future version du noyau. Pour les besoins spécifiques des pilotes qui veulent absolument gérer une grande quantité de travail lors d'une interruption, il est toujours possible d'utiliser le mécanisme « threaded interrupt handlers » qui fait appel à un thread 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. Au final, le noyau 2.6.35 fonctionne maintenant uniquement avec des interruptions « rapides » ininterruptibles, ce qui simplifie l'écriture des pilotes Linux, permet une meilleure gestion du cache CPU, autorise une prédictibilité des temps de complètement et éradique les risques de débordement de la pile d'interruption. Une belle avancée !

En bref (↑)

L'implémentation interne des arbres bicolores a été modifiée dans le noyau Linux 2.6.35. Ces arbres sont des algorithmes (des arbres binaires de recherche) qui permettent de chercher, d'insérer ou de supprimer des données. Ce genre d'algorithme est très efficace et il est donc utilisé à de nombreux endroits dans le noyau. Néanmoins, les arbres bicolores avaient une importante limitation puisqu'on ne pouvait faire une recherche que par rapport à une seule clé. Quand le développeur Venkatesh Pallipadi s'est aperçu qu'il avait besoin de faire une recherche non pas sur une clé unique mais sur un intervalle, il a décidé de ne pas se contenter de résoudre son problème particulier avec un hack. Il a donc écrit un patch général qui permet de stocker dans chaque nœud de l'arbre des informations supplémentaires (comme la valeur maximum) afin d'avoir un arbre bicolore bien plus utile qu'auparavant, qu'il a nommé un « augmented red-black tree ». Ce nouvel algorithme amélioré peut maintenant être utilisé par tous les développeurs pour optimiser leur code au sein du noyau.

La fonction truncate() qui comme son nom l'indique, est utilisée pour tronquer un fichier à une taille voulue, a été modifiée par Nick Piggin dans le nouveau noyau. Normalement, quand le fichier est plus grand que la taille voulue, alors l'appel à truncate() permet de supprimer tout ce qui dépasse, tandis que si le fichier est plus petit que la taille voulue, il est étendu et l'espace supplémentaire est rempli par des zéros. Tout cela est bel et bon, mais la gestion des erreurs était très difficile avec l'ancien code et il n'était pas vraiment possible de connaître la taille précédente du fichier en cas d'échec du truncate(). Le patch de Nick Piggin corrige tous les problèmes de cette fonction et il propose également la possibilité de désallouer atomiquement les blocs. Le code introduit en plus un flag new_truncate dans la couche VFS qui sera utilisé pendant la période de conversion des divers systèmes de fichiers du noyau. Ce flag n'est pas très élégant, Nick appelle ça un « nasty hack », mais tant que la transition ne sera pas complète, il est obligatoire de connaître le statut de chaque système de fichiers pour savoir s'il utilise la fonction améliorée ou bien l'ancien truncate().

Le patch ramoops de Marco Stornelli permet de stocker les informations générées par le noyau lors d'une erreur, un oops, dans la mémoire RAM (qui peut être persistante). Il existait déjà une solution un peu comparable qui offrait la possibilité de stocker sur mémoire flash les informations du oops. Cette solution, mtdoops, nécessite toutefois la présence du sous-système MTD, ce qui peut être rédhibitoire pour certaines machines. La nouvelle option RAMOOPS autorise maintenant l'enregistrement du oops dans un tampon mémoire circulaire en RAM qui pourra être lu plus tard.

Le système de fichiers de nouvelle génération Btrfs continue d'être amélioré par ses développeurs, et le noyau 2.6.35 ne fait pas exception. Il est maintenant possible d'utiliser Btrfs en mode direct I/O. Ce mode d'entrées/sorties directes contourne complètement les systèmes de cache du noyau (mode buffered I/O) et laisse l'application gérer toute seule le transfert des données. Bien entendu, il n'est pas recommandé de faire ça dans le cas général mais certaines bases de données préfèrent gérer elles-mêmes le flux de données afin d'optimiser les performances. Btrfs était également connu pour avoir un comportement « intéressant » quand le disque était plein. Maintenant le cas d'erreur ENOSPC (No space left on device) est complètement géré (patchs 1 – 2 – 3) y compris dans les cas plus ou moins exotiques (volume management, space balancing, etc.).

Les patchs d'amélioration de la gestion de l'énergie pour les cartes graphiques Radeon ont été intégrés au noyau 2.6.35. Après l'introduction d'une première prise en charge rudimentaire dans le noyau précédent, le nouveau code permet une gestion plus complète et plus fine des fonctions d'économie d'énergie des cartes Radeon. Tout se passe dans le système de fichiers virtuels sysfs et il suffit d'écrire dans /sys/class/drm/card0/device/power_method pour choisir sa méthode d'économie. En écrivant « dynpm » (dynamic power management), on opte pour une gestion complètement automatique qui économise plus d'énergie mais — comme l'indique David Airlie dans son mail — le code n'est pas tout à fait mûr. Le risque, c'est d'avoir des artefacts sur l'écran (ce qu'il nomme « glitch on screen »). Au lieu de cette gestion automatique, on peut indiquer au noyau qu'on veut utiliser un profil bien défini (et on écrira alors « profile » dans /sys/class/drm/card0/device/power_method). Les profils disponibles (à écrire dans /sys/class/drm/card0/device/power_profile) sont :

default :

On laisse la carte graphique tourner à sa fréquence par défaut sans rien toucher.

low :

Le GPU tourne à la vitesse minimum (mode sur batteries par exemple).

high :

Le GPU tourne à la vitesse maximum (mode sur secteur par exemple).

auto :

Changement automatique entre les modes low et high en fonction du mode d'alimentation.

Du côté des cartes graphiques Intel, on note l'entrée dans le noyau de la gestion du PCH (Platform Controller Hub) des futurs processeurs Sandybridge. La gestion du cœur graphique Ironlake (qu'on trouve dans les puces Core i3/Core i5/Core i7) a été améliorée puisque le patch d'auto-rafraîchissement de la mémoire permet d'économiser plus d'un watt en période de veille. Enfin, la grosse nouveauté sur ces cartes Intel Ironlake c'est la prise en charge matérielle du décodage H.264 et VC1. Écrit par le développeur Zou Nan hai, le patch introduit un tampon circulaire (ring buffer) pour accèder au circuit vidéo spécialisé de la puce, le bit stream decoder. Pour que cela fonctionne, il faut utiliser une bibliothèque VAAPI (Video Acceleration API) libva d'une version supérieure ou égale à 1.0.4 et — bien entendu — un lecteur vidéo supportant cette libva. Une page spécifique a été mise en place par Intel au sujet de cette fonction d'accélération matérielle.

Le système de fichiers OCFS2, qui est développé par Oracle pour son utilisation sur des grappes de serveurs, est surtout utilisé pour de la répartition de base de données. Comme l'explique très bien cet article de Linux Mag, le système OCFS2 est souvent sous-estimé puisqu'il reste cantonné aux base de données alors qu'en réalité, on pourrait l'utiliser dans bien d'autres configurations. Dans le noyau 2.6.35, le système de fichiers OCFS2 a été amélioré par l'ajout de deux nouvelles fonctions. La première d'entre elles est l'amélioration de la réservation d'espace par les allocateurs de chacun des nœuds. Cette portion réservée (allocation window) permet d'améliorer la contiguïté des données et, donc, d'améliorer les performances. La seconde amélioration a aussi à voir avec l'allocation des données, puisqu'il s'agit cette fois de permettre d'allouer des blocs venant de régions séparées. Sur un système de fichiers très fragmenté, il peut être difficile de trouver des ensembles de blocs contigus et l'allocateur des noyaux précédents ne savait pas le faire pour des régions séparées. Le patch de Joel Becker répare ça et il améliore donc la robustesse d'OCFS2.

Toujours dans le domaine des systèmes de fichiers, on peut noter la myriade de petits changements dans la couche VFS, qui offre une interface commune à tous les systèmes de fichiers de Linux. Ces modifications sont listées par Al Viro dans son mail d'annonce pour la version 2.6.35. L'une des plus importantes (qualifiée de « serious surgery ») permet une grande simplification du code des verrous logiciels. On constate d'ailleurs que le patch supprime près de 1300 lignes et n'en ajoute que 900. Selon Al, la façon dont sont gérés les superblocks a également été revue de manière à ne plus devoir itérer à travers toute la liste. Le noyau tient maintenant compte des superblocks ayant été supprimés pour s'épargner une bonne part de travail. Ces changements sont certes très techniques, mais le fait qu'ils interviennent dans une couche si critique et qui est utilisée par tous les systèmes de fichiers en décuple l'importance.

Comme annoncé dans son mail accompagnant la sortie de la version candidate RC-5, Linus Torvalds a accepté le patch de minimisation defconfig de la branche ARM. Au fil du temps, le niveau de frustration du leader du projet Linux est lentement monté et a fini par exploser à l'occasion d'une énième demande de merge concernant l'architecture ARM. Linus a indiqué que 55 % de tous les changements dans la branche arch depuis le noyau 2.6.34 concernaient ARM. Le problème vient de l'énorme balkanisation de cette architecture (plus de 170 variantes existent). Comme de nombreux constructeurs proposent des puces ARM, les configurations et les variantes sont très nombreuses et les instructions de configuration (defconfig) sont innombrables. Linus ne veut plus de ce « bruit » continuel. Il a comparé point par point ARM et la branche x86 qui est bien plus propre et a finalement décidé de prendre une décision radicale : « Quand on a deux cents mille lignes de saleté et que ça continue de grossir sans limites, alors quelque chose doit être fait ». À titre préliminaire Linus a donc mergé ce patch de minimisation defconfig (hop près de 200 000 lignes en moins) : 177 files changed, 652 insertions(+), 194157 deletions(-). Les futurs noyaux vont sans doute intégrer un gros travail de factorisation de code et de fusion des sous-architectures afin d'améliorer la propreté de la prise en charge d'ARM dans Linux.

Le développeur Miklos Szeredi a écrit une série de patchs afin de modifier le système de fichiers FUSE (Filesystem in Userspace). FUSE permet d'implémenter un système de fichiers en espace utilisateur au lieu de le faire au sein du noyau Linux. C'est un mode d'utilisation plus souple et c'est parfois très utile, mais cela entraîne évidemment un surcoût CPU du fait de la barrière à franchir entre espace utilisateur et espace noyau. Toute optimisation est donc bonne à prendre et c'est exactement ce qui a motivé le travail de Miklos. Ce dernier a réécrit les routines de FUSE afin de se baser sur l'appel système splice() (qui déplace les données à l'aide d'un pipe sans avoir à les copier). Cette très intéressante optimisation était accompagnée d'un benchmark artificiel qui a provoqué l'ire de Linus : « Merci de ne pas faire de benchs n'ayant aucun sens et d'utiliser les résultats pour justifier toutes sortes de trucs. C'est pire qu'inutile. En fait, cela retire de la valeur au patch juste pour pouvoir dire "Regarde maman, sans les mains !" ». À la suite de cet éclat, une évaluation plus raisonnable a été postée qui permet de mieux estimer l'apport du patch de Miklos.

La couche md qui est utilisée sous Linux pour gérer les configurations multi-disques (pour faire du RAID logiciel) a été complétée. Tout d'abord le mode RAID10 qui consiste à agréger en stripping (RAID0) deux grappes de disques déjà configurées en miroir (RAID1), n'est plus marqué comme « expérimental ». Le message de commit indique que le code existe depuis longtemps et a été suffisamment testé pour être considéré comme fiable. Les deux développeurs Maciej Trela (Intel) et Neil Brown (Suse) ont également écrit plusieurs patchs ajoutant des fonctions de conversion qui manquaient à la couche md. Grâce à ce code, il devient maintenant possible de convertir vos configurations RAID0 vers du RAID5 et inversement, ou encore de RAID0 vers RAID10 et inversement. Par amour du travail bien fait et par souci de complétude, un mode de conversion RAID5 vers RAID4 est aussi disponible même si Neil Brown souligne dans le message de commit que ce mode est « unlikely to be wanted ».

Le code permettant de calculer le contrôle de redondance cyclique (CRC) sur 32 bits a été amélioré. Ce code (se trouvant dans /lib/crc32.c) est utilisé pour faire un hachage rapide de données afin de vérifier qu'il n'y a pas eu d'erreurs lors d'une transmission. Le noyau 2.6.35 fait maintenant une plus grande partie des calculs en avance de phase et il stocke ces résultats précalculés dans des tables. Évidemment, ces tables grossissent un peu par rapport aux noyaux précédents (on passe de 1Ko à 4Ko) mais le gain en performances est sensible. Selon Joakim Tjernlund, qui est l'auteur du patch, une puce embarquée de type MPC8321 et cadencée à 266 MHz enregistre un gain de 28% lors de ses calculs CRC-32. Pour un processeur Core 2 Duo à 3,1 GHz l'exécution du code est carrément deux fois plus rapide.

Dans le domaine de la cryptographie, la prise en charge du jeu d'instructions AES-NI créé par Intel a été améliorée. Présent dans les processeurs de la génération Westmere et dans les futurs processeurs Bulldozer d'AMD, le jeu d'instruction AES-NI sert à accélérer les opérations de chiffrement/déchiffrement de l'algorithme symétrique Advanced Encryption Standard (AES). Dans le noyau 2.6.35, le mode d'opération CTR (mode basé sur un compteur) a été complètement réécrit en assembleur optimisé dans le patch de Huang Ying. Lors de tests effectués avec la couche dm-crypt, il a été constaté une réduction de 50% des temps de chiffrement/déchiffrement.

N'étant pas un pleutre, le noyau Linux ne craint pas les bombardements d'acronymes. Il gère maintenant officiellement l'interface APEI et ses divers outils associés (HEST, EINJ, ERST, CPER etc.). Les plus astucieux d'entre vous auront reconnu qu'il s'agit là de nouveaux spécimens de la luxuriante et redoutable jungle ACPI (Advanced Configuration and Power Interface). Le sigle APEI signifie « ACPI Platform Error Interface » et le patch introduisant la gestion de cette interface va permettre de transmettre les erreurs matérielles des périphériques ou de la carte mère au système d'exploitation, afin de mieux les gérer. Toute une faune d'outils annexes accompagne l'interface pour mieux la tester et la déboguer: HEST (Hardware Error Source Table), EINJ (Error Injection Table), ERST (Error Record Serialization Table), CPER (Common Platform Error Record).

L'outil perf, qui sert à surveiller les performances du noyau, a été enrichi par l'arrivée de plusieurs nouvelles fonctions. L'une d'elle est liée à la virtualisation et notamment à la machine virtuelle kvm. L'incorporation du patch de Yanmin Zhang ajoute à perf la possibilité de collecter des statistiques à propos du système invité (guest) et ce depuis le système hôte. Maintenant, les commandes du type « perf kvm top », « perf kvm record » ou encore « perf kvm report » sont disponibles (voir la documentation) pour avoir une vue plus détaillée du guest tournant sur le système. Une autre nouveauté de perf est le patch apportant une amélioration de l'option --list qui indique maintenant le numéro de ligne et l'emplacement des sondes du système. L'option --dry-run est introduite pour éviter de faire des bêtises et aider à tester ses commandes avant de les lancer réellement. Enfin, le patch d'Arnaldo Carvalho de Melo implémente la prise en charge de la bibliothèque graphique en mode texte Newt (un peu l'équivalent de ncurses). Cela permettra sans doute d'interagir plus facilement avec l'outil perf.

Dans le domaine réseau, le mécanisme de sécurité GTSM (qui a été décrit dans la dépêche du noyau 2.6.34) est maintenant compatible avec le protocole IPv6. Comme dans le cas d'IPv4, il suffit de définir le champ TTL (Time-to-Live) à 255 pour profiter de ce mécanisme de sécurité astucieux qui protège contre certains dénis de service. On peut noter que l'introduction de GTSM sur IPv4 dans Linux ne faisait que rattraper un retard sur les systèmes BSD puisque GTSM faisait partie de FreeBSD 7.0 et d'OpenBSD 4.2. En revanche cette nouvelle option IPV6_MINHOPCOUNT du noyau 2.6.35 n'est pas encore disponible chez les cousins BSD.

Documentation technique et maintenance du code (↑)

Afin de désamorcer le micro-troll de la dernière brève ci-dessus, rendons un hommage aux développeurs d'OpenBSD. On sait que ces derniers refusent de signer des accords de non-divulgation et qu'ils luttent avec acharnement pour obtenir les spécifications complètes des périphériques. Voir par exemple le prix de la FSF obtenu en 2004 par Theo de Raadt pour « ses efforts dans l'obtention de pilotes et documentations libres des cartes de réseau sans fils ». Une fois de plus, l'histoire vient de donner raison à ceux qui mènent ce combat opiniâtre. Un pilote libre ne suffit pas toujours et la disponibilité de la documentation technique est cruciale dans bien des cas. Intel a en effet annoncé que les pilotes Linux des cartes Wi-Fi d'ancienne génération 2100/2200BG/2915ABG (présentes dans les portables Pentium M et Core Duo) passaient en mode « orphelin ». Autrement dit, plus aucun développeur Intel ne travaillera sur ce code libre et le seul message de commit est « Merci de nous faire savoir si quelqu'un est intéressé par la maintenance de ces pilotes ». Ce laconisme a provoqué une vive réaction de la part de Dave Miller, responsable du sous-système réseau de Linux : « Je suis extrêmement déçu de constater que la seule organisation capable de corriger les bugs de bas niveau dans ces pilotes n'est plus disposée à le faire. Si de la documentation ne peut être fournie afin que d'autres puissent maintenir ce pilote (et pas seulement pour quelques personnes en particulier, parce qu'un jour, ces gens-là pourrait eux-aussi ne plus le maintenir) alors ce serait vraiment criminel ». La réponse de la développeuse Intel, Reinette Chatre, n'a pas été encourageante sur la mise à disposition de la documentation technique : « Récemment nous avons perdu toute expertise sur ces pilotes et nous ne sommes plus capables de les maintenir de façon correcte. C'est pour ça que nous avons changé le statut en "Orphaned" parce que ça reflète vraiment la situation à l'heure actuelle. Nous ne savons vraiment pas quoi faire d'autre. Nous sommes incapables de fournir cette documentation, mais nous examinons nos options en ce moment. Avec le démantèlement des équipes cela va prendre un peu de temps ». À l'évidence, Dave Miller a été exaspéré par cette réponse et par le comportement d'Intel dans cette affaire. La firme californienne avait jusqu'à présent joué le jeu du libre en proposant un pilote intégré au noyau Linux et en assurant sa maintenance, mais le tableau s'est assombri avec cette annonce (voir le message sur le site du pilote : « This project is considered stable and Intel is no longer maintaining it »). Bien entendu, il ne saurait être question de dire qu'Intel a une obligation de maintenir un pilote ad vitam æternam. Les développeurs Linux sont prêts à comprendre que le support de vieilles cartes Wi-Fi qui ne sont plus commercialisées depuis longtemps est une activité qui n'intéresse pas cette entreprise. La communauté peut parfaitement prendre le relais… mais dans ce cas, il faut fournir la documentation détaillée sur le matériel au moment du démantélement des équipes ! Le pilote libre est certes un grand atout pour comprendre comment marche la puce mais, si un bug de bas niveau se manifeste, il faut souvent avoir la documentation pour pouvoir le corriger. Si Intel refuse ou est incapable de fournir cette documentation alors, même si le risque est très faible dans le cas d'un pilote ancien, la communauté sera à la merci de l'apparition d'un bug vicieux. C'est le cœur de la réponse de Dave : « Et après on se demande pourquoi nous poussons aussi durement les vendeurs pour qu'ils fournissent la documentation technique de leurs puces, et ça même quand ces vendeurs sont amicaux envers nous et ont une équipe de développeurs qui maintient le code, au moins au début. C'est exactement parce que des trucs comme ça peuvent arriver et arrivent vraiment. Et avec la pléthore de périphériques et de pilotes présents dans Linux, on peut s'attendre à ce que ce genre de chose devienne de plus en plus fréquent. Sans cette documentation nous sommes démunis et à la merci de votre décision ». La position des développeurs d'OpenBSD, qui est aussi celle de Dave Miller et de nombreux autres développeurs Linux, est qu'il faut exiger la documentation technique détaillée des périphériques auprès des fabricants. Ce serait dans l'intérêt de tout le monde puisque, dans le cas d'espèce, Intel ne perdrait rien en diffusant la doc d'une vieille puce Wi-Fi d'ancienne génération. Comme le dit Theo de Raadt dans cet entretien en s'adressant aux industriels: « Le fait de nous donner la documentation nous permet de maintenir vos périphériques et comme ça encore plus de consommateurs sauront que vos périphériques sont bien pris en charge ».

Le bilan en chiffres (↑)

Côté statistiques, l'article récapitulatif pour le 2.6.35 du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux. Dans son mail d'annonce de sortie du noyau Linus indique que sa politique de sévérité s'est traduite par des statistiques inhabituelles. Alors qu'en moyenne il accepte entre 2700 et 3200 commits après la première version candidate, cette fois-ci ce sont moins de 2000 commits qui sont entrés dans sa branche Git après la RC-1. Il faut remonter au noyau 2.6.24 pour avoir un cycle de RC aussi calme. En revanche pour les ajouts dans la période de merge il semble que le noyau a atteint une sorte d'équilibre aux alentours de 10 000 patchs par version (tous les trois mois donc). Si on regarde les chiffres du site remword (au premier août) on obtient cela pour les cinq derniers noyaux :

• 2.6.31 : 10 881 patches (1 164 développeurs) ;
• 2.6.32 : 10 997 patches (1 244 développeurs) ;
• 2.6.33 : 10 863 patches (1 199 développeurs) ;
• 2.6.34 : 9 443 patches (1 171 développeurs) ;
• 2.6.35 : 9 771 patches (1 188 développeurs).

Puisque les chiffres semblent montrer un « plafonnement » dans le développement du noyau, est-ce qu'il faut s'inquiéter de cette situation ? Ce n'est pas l'avis exprimé par Greg Kroah-Hartman dans l'article LWN : « Un certain nombre d'entre nous se demandaient ce que les limites de notre communauté allaient être. Aux alentours de 10 000 changements par version, cette limite s'avère très élevée donc il n'y a pas de motifs d'inquiétude à avoir. Le noyau Linux reste, de loin, le projet de développement logiciel le plus actif que le monde ait jamais vu ». On peut quand même s'interroger sur le goulot d'étranglement qui empêche l'inclusion d'encore plus de patchs. Peut-être est-ce Linus lui-même qui est débordé et qui ne peut pas merger plus de code qu'il ne le fait actuellement ? Jonathan Corbet a analysé cette position centrale de Linus dans un excellent article (On the scalability of Linus) et il conclut que c'est bien ce problème de montée en charge qui pourrait être à l'origine du blocage. Depuis l'époque héroïque où tous les patchs s'envoyaient directement par mail sur la LKML, la communauté a bien progressé. Le passage par Bitkeeper puis l'écriture de Git par Linus lui-même ont permis des bonds fantastiques dans la productivité du mode de développement. Néanmoins, Linus garde un œil vigilant sur ce qui entre dans la branche principale et il n'aime pas trop l'idée que des merges se fassent sur d'autres branches et qu'on ne lui propose qu'un produit global fini. C'est ce comportement qui constitue le facteur limitant pour l'entrée de code dans la branche principale. Peut-être qu'il faudra en venir un jour à ces merges sur d'autres branches car le diagramme d'inclusion actuel est quand même un incroyable entonnoir vers la branche mainline de Linus ! À voir cette image on se doute qu'il doit avoir un sacré boulot. Outre cette réflexion générale sur le développement du noyau, l'article de synthèse de Linux Weekly News propose également une analyse des contributions sur les différentes sous-parties de Linux. On sait que le cœur du noyau est la partie qui est utilisée par tous les utilisateurs, quels que soient leurs processeurs, leurs périphériques ou leurs configuration. Cette partie « core » représente moins de 5 % des lignes de code de Linux et elle est bien distincte des répertoires drivers, fs, net, arch ou autres. Greg Kroah-Hartman a analysé les diverses contributions à ces sous-parties du noyau et les résultats pourront en surprendre plus d'un. Saviez-vous par exemple que, pour ce noyau 2.6.35, le premier contributeur en termes de patchs sur la partie réseau était SFR ? Étonnant non ?

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.

Suspend blockers

Après la polémique suite au retrait des pilotes Android du noyau 2.6.33, les discussions n'ont pas cessé sur la LKML. Tous les aspects du problème ont été disséqués et les développeurs recherchent une solution alternative à la technique wakelock de Google car cette dernière est considérée comme un vilain hack ne s'intégrant pas bien au noyau. Sachant que le code wakelock (rebaptisé « suspend blockers ») n'entrera jamais tel quel dans Linux, il faut trouver un remplaçant… mais en ce moment c'est la confusion qui domine ! Entre la proposition d'Alan Stern et celle de James Bottomley, entre l'avis détaillé d'Ingo Molnar et les critiques de Linus Torvalds, entre la nouvelle tentative d'inclusion du développeur Google Arve Hjonnevag et les dernières propositions de Rafael Wysocki, on ne sait plus trop où donner de la tête. Bien entendu, cette incertitude est provisoire et un vainqueur va finir par émerger qui sera adoubé par Linus. Le mode de développement de notre noyau préféré a toujours été très darwinien (même si, dans ce cas, il y a vraiment un dessein intelligent) et des polémiques actuelles sur la liste de diffusion sortira certainement un code de meilleure qualité qui sera incorporé aux futures versions de Linux.

Aller plus loin

• Les nouveautés du noyau 2.6.35 (171 clics)
• Le bilan des changements partie 1 (16 clics)
• Le bilan des changements partie 2 (9 clics)
• Le bilan des changements partie 3 (7 clics)
• Les prévisions pour l'avenir de Linux (21 clics)