Le noyau Linux 3.2 est disponible

La sortie de la version stable 3.2 du noyau Linux vient d'être annoncée par Linus Torvalds sur la liste de diffusion et sur Google+. 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.

P.‐S. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction. Merci également à Laurent Wandrebeck (low) pour sa contribution sur la brève concernant DVFS.

Sommaire

• La phase de test
  • RC-1
  • RC-2
  • RC-3 - Juste à temps pour <em>Thanksgiving</em>
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • CFS bandwidth controller
  • Ext4 bouge encore
  • EVM
  • Proportional rate reduction
  • Bull Mountain
  • Gestion dynamique du writeback
• En bref
  • • SHA-1 optimisé
    • Blowfish et Twofish
    • RAID-5 pour Exofs
    • Hexagon
    • AMD Bulldozer
    • DVFS
    • Samba va plus vite
    • SLUB
    • Améliorations de Btrfs
    • Cross memory attach
    • DM et « thin provisioning »
    • TAINT_OOT_MODULE
    • Hibernation
    • Sous-système de contrôle des broches
    • Pilotes graphiques
    • Cronopio dentiacutus
• Statistiques
• Pour la suite
  • Pilotes Android

La phase de test

RC-1

La version RC-1 a été annoncée le 7 novembre dernier par Linus :

Cela fait donc deux semaines depuis la 3.1, et vous connaissez le fonctionnement maintenant.
Je dois dire que cela n'a pas été ma fenêtre d'intégration favorite. J'aurais vraiment voulu prendre uniquement les choses qui se trouvaient dans -next, mais vérifier tout ça a été très douloureux, surtout que de nombreuses branches ont été réunifiées, et celles qui ne l'ont pas été contenaient souvent de nouveaux correctifs qui étaient toujours visibles quand je faisais un « git log linux-next..FETCH_HEAD ».
Dans l'ensemble, la plupart des trucs étaient corrects et je n'ai pas vraiment protesté auprès des gens. Je suis à peu près sûr qu'il y a des branches que je n'aurais pas dû laisser passer mais la majorité était vraiment dans -next.
L'autre point d'irritation est qu'il y a des nouveaux patchs qui sont arrivés hier et qui, en gros, ont pris la fenêtre d'intégration pour une sorte de dance Limbo high-tech. S'il ne s'agissait pas de quelques branches que je voulais intégrer, j'aurais en fait planifié la sortie de -rc1 dimanche après-midi, juste pour couper court à ces demandes d'intégration de dernière minute.
D'ailleurs certaines branches n'ont pas été intégrées. Vous vous reconnaîtrez, et vous pouvez essayer de faire appel à mon côté gentil si vous pensez que c'est injuste. Bien sûr, si vous réussissez à le faire, merci d'informer ma femme et mes enfants, ils seront ravis de l'apprendre.
En fait la raison principale de la non-intégration de ces branches est qu'elles ont généré de longues flame-wars. Je ne voulais pas aggraver les choses ces temps-ci, surtout en sachant qu'il y avait plein d'autres branches à intégrer.
Qu'ai-je intégré ? Beaucoup de choses. Les statistiques sur les différences sont énormes, et remplies de renommages. Les pilotes réseau ont été réorganisés, ce qui est un gros morceau de renommage, mais il y a les architectures qui ont été, elles aussi, nettoyées et réorganisées (UML et quelques sous-architectures arm, par exemple) ajoutant leur propre lot de renommages. À cela s'ajoutent des pilotes de la branche -staging qui sont passés dans la branche principale, etc.
Mis à part les réorganisations, il y a vraiment beaucoup de changements un peu partout. À peu près 75 % pour les pilotes (et cela sans compter les renommages), 15 % architecture, et 10 % « le reste » (principalement système de fichiers et réseau - avec les fichiers d'en-tête s'affichant aussi dans les statistiques).
Ce qui n'apparaît même pas dans les statistiques, ce sont les changements sur la mémoire virtuelle, bien que ceux-ci soient les plus remarquables au coeur du système. C'est peut-être proportionnellement petit, mais c'est un peu fondamental, et cela a le potentiel de toucher tout le monde. Les gens ont travaillé sur le writeback, et tout ce qui concerne la gestion fine de l'écriture de pages dirty. Ainsi, maintenant les problèmes de writeback devraient faire partie du passé. Voyons comment tout cela fonctionne.
Amusez-vous, testez le bien. Il ne devrait rien avoir d'énormément effrayant là-dedans, mais il y a beaucoup de choses. Le fait que 3.1 ait traîné signifie que cela fut une des plus grosses fenêtres d'intégration, mais je ne me sens pas trop nerveux à ce propos.

RC-2

La version RC-2 est sortie le 15 novembre :

Linux 3.2-rc2 est maintenant disponible. En fait, les dépôts git sont là (kernel.org et github), et les fichiers tar devraient être bons, mais le patch est toujours en cours de transfert.
Une chose qui vaut la peine d'être remarquée : j'ai corrigé mes nouveaux scripts de publication, ainsi maintenant les fichiers de -rc2 se trouvent à la place qui leur revient de droit « v3.x/testing », contrairement à -rc1 où les fichiers étaient directement dans « v3.x ». Je corrigerai l'emplacement de cette -rc1 quand je serai dans un endroit ayant un meilleur réseau.
Et pour une version -rc2 venant après une fenêtre d'intégration aussi longue, elle semble avoir une taille assez raisonnable. En fait, bien que ce soit le plus gros linux-next au cours d'une publication dans toute l'histoire de linux-next (je pense), -rc2 a exactement le même nombre de commits depuis -rc1 que c'était le cas avec le noyau 3.1.
Environ la moitié des changements concerne des corrections d'architectures (m68k et arm, avec un peu de powerpc et une poignée d'autres). Pour le reste, environ la moitié concerne les pilotes (la plupart concernent DRM), et le reste est « système de fichiers et diverses mises-à-jour ».

RC-3 - Juste à temps pour Thanksgiving

La version RC-3 a été annoncée par Linus le 23 novembre, veille de la fête de Thanksgiving aux USA :

Hey, puisque la majeure partie des États-Unis sera dans le coma demain, suite aux indigestions, je sais que publier une nouvelle version candidate est une bonne idée.
Un quart de mises à jour d'architectures, 2 quarts de pilotes, et un autre quart de changements aléatoires. Secouez vigoureusement et servez froid…
Et peut-être que le reste du monde peut essayer de compenser la probable absence de participation des États-Unis ? Hmm ?
Peu importe, que vous vous gaviez de dinde ou non demain, une nouvelle -rc est sortie. J'aurais aimé vous dire que les choses se sont calmées, et que le nombre de commits se réduit, mais je mentirais. -rc3 est en fait plus gros que -rc2, principalement à cause de mises à jour réseau (rien dans -rc2) et avec Greg faisant son truc 'usb/driver-core/tty/staging' habituel.
Nous avons aussi eu des mises-à-jour sur DRM.
Ceci étant dit, la plupart des commits sont assez petits et raisonnables. Bon, il y a certainement plus de trucs que ce que j'aurais souhaité, mais ce n'est pas comme s'il s'agissait d'un tas de gros changements.

RC-4

Une fois que le « food-induced coma » de la version précédente a été surmonté, c'est le premier décembre que Linus a fait paraître la version RC-4 du noyau 3.2 :

Cela ne semble pas énormément plus petit que la -rc2 ou la -rc3 mais ça l'est vraiment.
Oui, il y a bien quelques modifications sur ARM, des corrections dans le nouveau code DRI Exonys et une mise à niveau tardive d'ocfs2, mais si vous ignorez ces trois secteurs (et la plupart d'entre-vous le font avec joie), les choses se sont joliment calmées.
Il y a quelques petites mises à jour sur la partie son, et btrfs reçoit encore des correctifs (mais bien moins que pour la -rc2), mais en dehors de cela, tout a été inhabituellement calme.
Je m'attends à une seconde vague. Il est possible que Davem et GregKH se retiennent - leur silence est très suspect, et j'ai le sentiment d'entendre des petits rires démoniaques. Mais, c'est peut-être tout simplement l'heure de prendre mes médicaments.

RC-5

Une semaine plus tard, le 9 décembre au moment de la RC-5, Linus a confirmé que ses craintes étaient fondées :

Cela fait un peu plus d'une semaine, et je suis désolé de constater que la -rc5 est plus grosse (au moins en nombre de commits - la plupart d'entre eux sont assez petits, il est donc possible que le fichier des différences soit plus petit, mais je n'ai pas vérifié) que la -rc2 et la -rc4 l'ont été.
Tant pis pour « les choses se sont joliment calmées ».
Bon, cela est probablement dû en partie au retour d'Ingo et de ses commits en retard (principalement x86 et perf). Mais franchement, cela n'est pas suffisant pour expliquer tout ça - nous avons des modifications sur xfs et btrfs, des mises-à-jour réseau, et l'habituel 50 % de modifications éparpillées parmi les pilotes (son, périphériques de pointage, processeurs graphiques sortent du lot, mais il y a aussi pas mal de mouvements du côté réseau et raid logiciel).
Ceci étant dit, il n'y a rien de bien dangereux et cela tend à être de petites modifications, dont plusieurs corrigent de sacrées régressions.
Je vais continuer à résister un peu auprès des gens qui m'envoient des trucs, mais j'espère aussi que c'était un accident isolé et que nous allons vraiment lever le pied maintenant.
OK ? Parce que nous voulons tous des vacances tranquilles, n'est-ce pas ? Et le père Noël n'aime pas quand je lance des bordées de jurons par courriel.

RC-6

La version RC-6 a été annoncée le 16 décembre par Linus :

Bon, les gens ont compris comment tricher avec mon timing de sortie des nouvelles versions parce que j'ai reçu aujourd'hui plus de la moitié des commits de la -rc6.
Je serai généreux et je dirai juste « OK, les gens ont simplement attendu le dernier vendredi avant les vacances pour envoyer leurs commits ». Peut-être qu'il ne s'agit pas vraiment de tricher avec le cycle des -rc, mais de manière générale je déteste quand les gens envoient leurs demandes au dernier moment.
Donc si vous avez fait exprès de faire ça, arrêtez s'il vous plait.
Ce serait bien mieux de répartir les choses sur la période - et d'avoir des développeurs qui suivent la branche -git pour réagir au fur et à mesure - plutôt que d'avoir un tir groupé juste avant la sortie de la -rc.
Ceci dit cette version est plus petite que les précédentes et les choses semblent se calmer. Nous en sommes à la -rc6 et, si je peux m'imaginer en train de faire une -rc7, je n'irai probablement pas jusqu'à la -rc8 à moins que nous ne trouvions un gros problème. Il n'y a pas vraiment de raison de faire traîner les choses un peu plus et nous aurons probablement le vrai 3.2 vers la nouvelle année.

RC-7

Finalement l'ultime version candidate, la RC-7, a été annoncée le 24 décembre par Linus :

Voilà la probable dernière -rc avant la sortie finale du 3.2, donc, testez-la bien entre vos fêtes de fin d'année s'il vous plaît.
La plupart des changements ne font qu'une seule ligne, mais quelques commits sur le pilote qla4xxx sont plus gros et concernent, en fait, 40 % du diff. Cela, avec une mise à jour du pilote VMWare DRI et quelques changements dvb ainsi que les corrections habituelles de pilotes font que 80 % des changements sont dans les pilotes.

Les nouveautés

CFS bandwidth controller

L'ordonnanceur CFS (Completely Fair Scheduler) du noyau Linux 3.2 incorpore maintenant la fonction de contrôle de bande passante (bandwidth controller) développée par Paul Turner.

En temps normal, l'ordonnanceur CFS essaye de rester fidèle à son nom en allouant le temps processeur de façon équitable entre les processus qui s'exécutent sur la machine. Le code divise simplement les ressources processeur en autant de tranches (slices) qu'il y a de processus. Bien entendu, on peut, via l'option de « Group Scheduling » introduite dans le noyau 2.6.38, favoriser un groupe de processus, si on veut une répartition différente du temps de processeur.
Que se passe-t'il si un processus ne dépense pas son temps de CPU parce qu'il n'en a plus besoin ? Par défaut, dans ce cas de figure, CFS n'est pas obtus au point de forcer le caractère « complètement équitable » de la répartition des ressources. L'ordonnanceur va donc allouer le temps CPU inutilisé aux autres processus qui tournent à ce moment-là. Certes ce n'est plus équitable mais c'est bien plus efficace !

Il y a toutefois des cas de figure où on ne veut pas de ce comportement « altruiste » qui offre les cycles processeur inutilisés aux autres processus. On veut - au contraire - pouvoir contrôler finement les allocations de temps CPU décidées par CFS.
Bharata Rao, qui - avant Paul Turner - avait proposé une première série de patchs, a listé dans son mail d'annonce les cas d'utilisation potentiels de cette fonction de « bandwidth control ».

• On retrouve le scénario classique d'un environnement virtualisé où l'administrateur souhaite limiter la consommation CPU d'un conteneur, et ce même si des ressources inutilisées sont disponibles par ailleurs.
• Un autre cas d'utilisation envisageable est celui ou des garanties de temps d'exécution doivent exister. En faisant du « bandwidth control » on est certain que le processus crucial ne verra pas son temps processeur mangé par les autres à un moment crucial.
• Enfin, le scénario du « pay-per-use » devient également possible grâce à ce travail sur le contrôle de bande passante. Une entreprise qui vend à ses clients un temps d'utilisation de CPU ne veut pas que ces derniers profitent gratuitement de ressources additionnelles. La société vendeuse utilisera donc le nouveau « bandwidth controller » pour spécifier exactement ce à quoi ont droit les processus du client.

Afin d'activer le contrôleur de bande passante, il faut un noyau compilé avec l'option CFS_BANDWIDTH (attention l'option dépend encore d'EXPERIMENTAL pour le moment). Le paramétrage se fait via les deux variables cpu.cfs_period_us et cpu.cfs_quota_us avec la microseconde comme unité de compte.
La bande passante CPU qui est accordée à un groupe pendant une durée de cpu.cfs_period_us est égale au quota cpu.cfs_quota_us.
Par exemple, si je veux limiter la consommation à 20 % du CPU par période d'une demi-seconde, je vais faire un petit :

echo 100000 > cpu.cfs_quota_us
echo 500000 > cpu.cfs_period_us

Chaque demi-seconde (la période), le groupe est autorisé à consommer seulement un dixième de seconde de temps CPU (le quota), ce qui correspond bien à 20 % des ressources.
En cas de machine multiprocesseur, on augmente simplement le quota pour refléter les ressources de la machine. Si, par exemple, on désire limiter le groupe à une bande passante correspondant à deux cœurs, on peut - par exemple - définir un quota d'une seconde toute les périodes d'une demi-seconde :

echo 1000000 > cpu.cfs_quota_us
echo 500000 > cpu.cfs_period_us

La documentation explique très bien tout ce mécanisme et détaille également les possibilités qui existent en termes de génération de statistiques (via cpu.stat).

Ext4 bouge encore

Dans le tout nouveau noyau Linux 3.2, le système de fichiers Ext4 a été modifié grâce au patch bigalloc afin d'améliorer ses performances. Divers changements visant à renforcer encore un peu plus sa stabilité ont également été intégrés.

Les dernières grosses améliorations sur Ext4 ayant été ajoutées dans le noyau 2.6.37, on pouvait penser que ce système de fichiers allait maintenant entrer en mode de maintenance pure, sans ajouts importants.
Finalement, ce n'est pas le cas et les développeurs continuent d'ajouter des fonctions afin de renforcer son attractivité. On peut d'ailleurs noter que Ted Ts'o pense que Btrfs ne pourra probablement pas remplacer Ext4 dans certains cas de figure bien particuliers.

La grosse nouveauté de ce cycle est donc l'intégration du patch bigalloc qui permet de regrouper en « clusters » les blocs de données traités par Ext4. La taille de ces blocs de données est de 4 Kio et il n'est pas facile de changer cette taille car le noyau s'attend à la retrouver dans une multitude d'endroits (gestion de la mémoire, cache des pages, etc.). Dans les faits, la taille des blocs du système de fichiers est donc limitée par la taille des pages et la surcharge de travail - induite par la gestion de ces blocs - est conséquente.
Puisqu'on ne peut pas - sans des efforts démesurés - changer la situation en aval, les développeurs Ext4 ont décidé de traiter le problème en amont. C'est donc le système de fichiers lui-même qui va prendre en charge la coalescence des blocs de 4 Kio, pour former des « clusters » plus gros.
En temps normal, Ext4 gère ses blocs dans un « tableau de bits » (bitmap) et chaque bit représente un bloc de 4 Kio. Le nouveau système permet d'allouer et de désallouer , d'un seul coup, un « cluster », c'est-à-dire une collection de blocs. Chaque bit du tableau de bits représente donc maintenant 2 puissance n nombre de blocs.
On voit bien que cette notion de « cluster » est purement interne à Ext4 et que le reste du noyau ne verra que les blocs individuels classiques de 4 Kio.
La taille du cluster doit être choisie au moment du formatage initial du système de fichiers (version 1.42 au minimum pour e2fsprogs) et cette fonction bigalloc n'est pas rétrocompatible avec les anciens noyaux. Attention également à ne pas choisir une trop grande taille, si vous avez beaucoup de petits fichiers, car la perte de place sera alors importante.

Ted Ts'o a expliqué dans un message sur la LKML le gain de performance qui pouvait être espéré du fait de ce patch bigalloc.
Les ingénieurs de Google veulent utiliser au maximum de leur capacité les fort nombreuses machines de leurs centres de données. Pour économiser l'énergie et pour minimiser le coût, il est nécessaire d'envoyer le plus possible de jobs sur chaque machine. Comme le patch bigalloc réduit la charge de gestion des structures de données (le tableau de bits est plus petit), il est donc très bénéfique dans ce cas.
C'est dans ce contexte que le test de Ted a été effectué, sur une machine en production. Il a comparé le temps (en microseconde) que met Ext4 à effectuer le travail associé aux appels systèmes fallocate et truncate:

Résultats pour fallocate
Ext4 classique => 14 262 µs
Ext4 bigalloc (cluster 64 kio) => 895 µs
Ext4 bigalloc (cluster 256 kio) => 318 µs
Ext4 bigalloc (cluster 1 Mio) => 122 µs

Résultats pour truncate
Ext4 classique => 12 944 µs
Ext4 bigalloc (cluster 64 kio) => 6 911 µs
Ext4 bigalloc (cluster 256 kio) => 4 541 µs
Ext4 bigalloc (cluster 1 Mio) => 4 558 µs

On note que le gain sur l'appel système fallocate est particulièrement impressionnant avec deux ordres de grandeur pour les clusters d'un Mio !

EVM

Après une longue période de maturation, le sous-système de vérification cryptographique EVM (Extended Verification Module) a été intégré dans le noyau Linux 3.2.

Cette intégration dans la branche principale est l'aboutissement d'un long et patient travail du développeur Mimi Zohar et de ses collègues d'IBM. Depuis plusieurs années, la firme américaine se consacre inlassablement à ce projet qui vise à préserver l'intégrité totale du système contre toutes les tentatives de manipulation ou de modification.
La saga commence en 2005 avec les premiers patchs proposant l'inclusion du mécanisme IMA (Integrity Measurement Architecture) dans le noyau 2.6.12. Le noyau Linux 2.6.11 était sorti en mars de cette année, avec un pilote de gestion des puces TPM (Trusted Platform Module) et IBM voulait s'appuyer sur ce pilote pour faire entrer son architecture IMA. Cette dernière est utilisée pour prendre les empreintes SHA-1 des fichiers et binaires du système, dans le but de pouvoir attester auprès d'un tiers qu'ils n'ont pas été modifiés (voir cet exemple de listing IMA).

Il s'est avéré qu'IBM avait été bien trop optimiste dans ses prévisions, puisque les patchs d'IMA n'ont pas été intégrés immédiatement. De nombreux développeurs ont critiqué la qualité du code et le fait que l'utilisation de cette architecture empêchait le chargement d'autres modules de sécurité comme SELinux. En effet, l'architecture de gestion des modules de sécurité (LSM) ne permet pas de les empiler les uns sur les autres (stacking) et il faut en choisir un et un seul.
Il a donc fallu qu'IBM passe par une réécriture complète, qui n'utilise plus LSM pour satisfaire les gardiens du noyau. Finalement, c'est seulement en juin 2009 - au moment de la parution du noyau 2.6.30 - qu'IMA est rentré dans la branche principale de Linux.
Après ce premier succès, obtenu de haute lutte, IBM a continué ses efforts. En effet, le mécanisme d'Integrity Measurement Architecture peut lister les hashs des fichiers et des binaires, mais il est vulnérable à une attaque hors ligne comme, par exemple, le démarrage depuis un live-CD. Ce qu'il faut ajouter, c'est un mécanisme de vérification cryptographique complet de bout en bout, basé sur le TPM de la machine.
En mars 2011, le noyau Linux 2.6.38 a accueilli une première étape de ce mécanisme sous la forme du patch Trusted keys conçu pour sécuriser les clés de chiffrement (la « trusted key » qui est générée par le TPM et qui est elle-même chiffrée avec la « storage root key » interne du module).

Le nouveau noyau 3.2 apporte donc la dernière pierre de l'édifice et incorpore le mécanisme complet EVM (Extended Verification Module) qui permet de protéger le système contre tous les types d'attaques.
Techniquement, l'architecture d'ensemble est intéressante et un document PDF récapitulatif a été rédigé à l'intention des utilisateurs curieux.
L'empreinte SHA-1 des fichiers (le HMAC) - qui est générée par IMA - est stockée dans les attributs étendus du système de fichiers. Ces attributs étendus (xattr) relèvent de l'espace de noms security.* et c'est security.ima qui stocke le HMAC du fichier. Il existe d'autres attributs étendus qui concernent la sécurité, par exemple security.selinux qui stocke le label SELinux du fichier ou encore security.capability pour enregistrer les capacités POSIX spécifiques attachées au fichier.
Il faut protéger ces attributs étendus contre l'attaque hors ligne et c'est le rôle d'EVM que de veiller à cette intégrité. Le sous-système va calculer un hash de tous les attributs, signer ce hash avec la « trusted key » du TPM et stocker tout ça dans le nouvel attribut security.evm.

Supposons qu'un malandrin ayant accès à la machine utilise un live-CD pour démarrer et veuille remplacer un binaire par un autre dans lequel il aura placé un trojan. Ce qu'il ne sait pas c'est que l'administrateur est un paranoïaque et que le noyau de la machine a été compilé avec la panoplie complète de protection (CONFIG_IMA + CONFIG_TRUSTED_KEYS + CONFIG_EVM). Lors du démarrage suivant, la signature des hashs - qui est présente dans la puce TPM - sera vérifiée par la fonction evm_verifyxattr(), et le résultat indiquera clairement que le binaire a été modifié, ce qui dénoncera la manipulation.

Toute la gymnastique de mise en place de ce mécanisme IMA/EVM est décrite avec force détails sur le site linux-ima. Après tout, après plus de six ans d'efforts pour intégrer la branche principale, les développeurs ont largement eu le temps de peaufiner leur documentation !

Proportional rate reduction

La pile réseau TCP du noyau Linux 3.2 accueille le nouvel algorithme « Proportional rate reduction » conçu par l'ingénieur Google Nandita Dukkipati.

Le protocole TCP règle l'envoi des paquets sur le réseau en fonction de plusieurs algorithmes différents. Le but étant à chaque fois de faire passer le plus de données possible, d'avoir une latence la plus réduite possible et de résister aux diverses perturbations et pertes qui se produisent invariablement. Pas facile de tout concilier !
Dans le cas où des paquets se perdent dans la nature parce que la bande passante est saturée, alors l'envoyeur ne va pas recevoir les accusés de réception (les ACK pour ACKnowledgement) qui correspondent aux paquets envoyés et il saura qu'il est nécessaire de réduire le flux d'envoi. La « fenêtre de congestion » (congestion window c'est-à-dire l'idée que se fait l'envoyeur des capacités maximum de la ligne) était trop large et il va falloir être moins optimiste dans l'envoi des données.

Il existe plusieurs idées pour résoudre le problème ,mais la plus employée (RFC2581) conseille une méthode assez radicale : diviser immédiatement la « fenêtre de congestion » par deux.
C'est une mesure un peu sévère et qui dégrade trop les performances aussi le noyau Linux emploie par défaut un mécanisme un peu plus sophistiqué nommé « rate halving ». L'idée est de ne pas diviser tout de suite la fameuse fenêtre par deux. On va plutôt la réduire petit à petit, d'un segment à chaque fois que l'on reçoit deux ACK. Le résultat final est le même, puisque lorsque tous les ACK en attente auront été reçus, on aura bien divisé par deux la précédente fenêtre de congestion. L'avantage, c'est que la latence est meilleure et que la décroissance des capacités se fait de façon plus « douce » (voir, par exemple, les graphiques page 12 de ce pdf).

Les ingénieurs de Google ont voulu aller plus loin que cet algorithme de « rate halving » employé jusqu'à présent dans Linux et c'est le résultat de leur travail qui est entré dans ce nouveau noyau 3.2. Un brouillon (draft) a été soumis à l'IETF pour une future normalisation, mais l'idée peut se résumer ainsi : On va calculer la différence entre le nombre de paquets actuellement en cours de transmission et le nombre de paquets qui devraient idéalement être envoyés selon l'algorithme de contrôle de la congestion. Cette différence peut bien entendu être positive ou négative.
A) Si la différence est négative (on a moins de paquets « dans les tuyaux » que ce que peut supporter la fenêtre de congestion cible), alors on peut augmenter immédiatement le taux de transmission selon l'algorithme slow start habituel. On gagne en latence car l'augmentation du débit se fait immédiatement.
B) Si la différence est positive (on a plus de paquets « dans les tuyaux » que ce que peut supporter la fenêtre de congestion cible), alors on va réduire le taux de transmission, mais en ayant pour cible la fenêtre de transmission idéale et non en divisant par deux brutalement. On gagne en débit car on exploite mieux la bande passante disponible.

Un article au format PDF explique en détails l'algorithme « Proportional rate reduction », ainsi que les tests qui ont été effectués sur les serveurs de Google.
Les auteurs de PPR ont observé une réduction de la latence comprise entre 3 % et 10 % par rapport aux performances d'un noyau Linux classique (moins de timeout). La fenêtre de congestion obtenue en fin de processus est également plus précise et permet de faire passer plus de paquets. Le slide 9 de ce fichier indique ainsi qu'en cas de congestion, alors un noyau sans PPR doit passer entre 3 % et 5 % de temps de transaction en plus par rapport au nouveau noyau 3.2.

Bull Mountain

La société Intel a introduit dans sa future architecture Ivy Bridge une fonctionnalité dont elle est très fière. Il s'agit d'un générateur matériel de nombres aléatoires, connu sous le nom de code Bull Mountain.
Les nombres aléatoires, c'est bien sûr fort utile dans le monde de l'informatique ; on les utilise surtout pour la cryptographie, mais il y a de nombreux autres domaines d'applications.
Il faut bien distinguer les nombres pseudo-aléatoires des vrais nombres aléatoires. Les premiers sont générés très rapidement, puisqu'ils sont simplement issus de l'exécution d'un algorithme par le processeur. La contrepartie de cette rapidité, c'est que les nombres n'ont que l'apparence de l'aléatoire et qu'il faut se méfier d'eux dans les applications cryptographiques.
On peut, à l'inverse, se servir d'un dispositif physique (radioactivité, bruit quantique, etc.) pour générer de vrais nombres aléatoires, mais dans ce cas, on est souvent limité par un débit de production assez faible. En outre, ces circuits analogiques ne sont pas très pratiques, consomment en permanence du courant et sont difficiles à améliorer au même rythme que les circuits numériques qui suivent la loi de Moore.
Intel a donc choisi d'abandonner sa filière de générateurs matériels analogiques qui est présente sur certaines de ses cartes mères (description dans ce pdf de 1999) et qui se base sur le bruit thermique d'un circuit.
Le nouveau système, nommé Bull Mountain, est purement basé sur des circuits numériques ce qui va permettre de baisser la consommation, tout en ayant des débits de nombres aléatoires sans commune mesure avec ce qui existait auparavant.

Le module numérique est gravé à même la puce d'Ivy Bridge et il se base, pour simplifier outrageusement les explications de cet article d'IEEE Spectrum, sur des transistors qu'on force à être dans un état métastable. C'est un peu comme un crayon qu'on maintiendrait en équilibre sur la pointe de sa mine. Quand on lâche le crayon, on sait qu'il va retomber, mais on ne peut pas deviner la direction de sa chute (cela dépend des micro-mouvements du doigt juste avant de le lâcher). C'est pareil avec les transistors utilisés dans Bull Mountain, dès qu'on cesse le forçage métastable, ils vont revenir dans un état normal - c'est-à-dire 0 ou 1 - et le choix entre les deux possibilités est purement aléatoire, puisqu'il dépend du bruit thermique.
Tout ça se déroule à la même cadence que celle du processeur (environ 3 GHz de nos jours) et sans avoir besoin de subir les latences inutiles et les inconvénients des circuits analogiques classiques, en termes de consommation et de difficulté à faire évoluer.
Avec l'ancien système analogique, Intel parvenait à générer quelques centaines de kilobits de nombres aléatoires par seconde. Avec le module Bull Mountain d'Ivy Bridge on sera à plus de trois gigabits par seconde !

Ce flux de données aléatoires va ensuite servir à alimenter une unité matérielle spéciale qu'Intel nomme un « conditionneur ». Cette unité va chiffrer les bits aléatoires qu'elle reçoit avec l'algorithme AES (en mode CBC-MAC). C'est l'architecture classique en cascade qui utilise les nombres purement aléatoires comme valeur en entrée d'une fonction mathématique générant des nombres pseudo-aléatoires (un PRNG pour PseudoRandom Number Generator).
Cela joue un peu le rôle d'un « réservoir d'entropie » (random pool) afin de sortir en fin de parcours des nombres utilisables pour les applications cryptographiques les plus exigeantes.

Le module matériel Bull Mountain est donc complet (self contained comme disent les Anglo-saxons) et les logiciels peuvent accéder à ses nombres aléatoires, sans passer par les bibliothèques habituelles. Le processeur Ivy Bridge propose pour cela la nouvelle instruction RDRAND qui permet - au choix - d'obtenir en retour une valeur aléatoire de 16, 32 ou 64 bits.
Les patchs, soumis sur la liste de diffusion par H. Peter Anvin, ajoutent donc au noyau Linux 3.2 la gestion de cette instruction RDRAND, qui est utilisée par les applications qui veulent recevoir le flux de nombres.

Comme la LKML ne serait pas ce qu'elle est sans un certain degré « d'espièglerie », il y a eu des échanges assez féroces à propos de ces patchs. Matt Mackall a commencé par annoncer qu'il s'opposait à leur inclusion (nack) parce que, selon lui, il fallait proposer une couche d'abstraction au lieu d'un accès direct via un crochet logiciel (hook). À la fin de son message, il a même ajouté que ce serait bien d'avoir des systèmes auditables sans avoir besoin d'un microscope électronique.
Linus Torvalds s'est empressé de lui répondre que son nack ne comptait absolument pas et que sa proposition d'abstraction était stupide :

Parler de « pilote standard » pour les modules aléatoires matériels est tout simplement débile quand on peut y accéder via une simple instruction qui prend quelques nanosecondes. Toute perte de temps induite par le pilote serait une folie et aucun utilisateur ne voudrait de ça de toute façon.
L'espace utilisateur n'en voudrait pas non plus, parce qu'il veut juste profiter de cette instruction directement. Ce n'est pas un de ces trucs merdeux accessible via le bus PCI. Là c'est du haut débit avec latence faible.
Pour x86, les choix entre les différents générateurs aléatoires (si quelqu'un se préoccupe encore de ceux de Cyrix ou autres) peut s'effectuer via asm_alternate().
Et si tu ne fais pas confiance au RNG du processeur, ce n'est pas la peine de sortir des arguments stupides au sujet des microscopes électroniques. Teste-le ou bien, plus raisonnablement, fais-en juste une des sources d'alimentation d'une réserve d'entropie. Mais ne cherche pas à alourdir tout le truc alors que le but de ce module c'est justement d'être rapide et léger.

Matt Mackall n'a pas bien pris le rejet de son nack (Good to know, feel free to drop me from MAINTAINERS.) mais il n'a pas pu convaincre Linus et les autres développeurs du bien fondé de son point de vue (voir aussi la réponse ironique d'Arjan van de Ven au sujet du microscope électronique).
H. Peter Anvin a toute de même modifié ses patchs pour inclure la solution de Linus, basée sur des chemins alternatifs. Le noyau 3.2 dispose donc maintenant de la gestion de RDRAND, même si la fonction n'est utilisée qu'en tant que source non bloquante (similaire à /dev/urandom).
Après tout, la remarque de Matt sur la confiance qu'on peut accorder à un tel module recèle un fond de vérité. Comme l'a expliqué Ted Ts'o, il vaut mieux se servir de Bull Mountain comme d'une source parmi d'autres pour alimenter le vrai générateur sécurisé qu'est /dev/random.

Gestion dynamique du writeback

Le travail de fond commencé il y a plusieurs mois par le développeur Wu Fengguang a fini par porter ses fruits. Linus a accepté d'inclure dans le nouveau noyau 3.2 ses patchs qui modifient profondément le comportement du sous-système de la mémoire virtuelle.

Avant de tenter d'expliquer à quoi sert ce mécanisme très complexe, il est bon de faire un petit peu de terminologie (en adaptant un paragraphe similaire de la dépêche du noyau 2.6.32).
Les patchs de Wu changent la manière de gérer la fonction de « writeback » du système… mais qu'est-ce que ce mécanisme de « writeback » ?

Quand une application quelconque veut écrire des données, alors le noyau Linux place ces données dans un cache nommé « page cache ». Au fur et à mesure que les données sont mises dans une queue d'entrées/sorties allant conduire à l'écriture sur le périphérique, elles sont marquées par le drapeau « dirty ». Enfin les données étant vraiment en train d'être écrites sur le périphérique sont identifiées comme étant en « writeback ».

On peut visualiser ce qui se passe à un instant donné en regardant le contenu de /proc/meminfo. Par exemple ici, lors de la copie d'un gros fichier vidéo sur une clé USB :

patrick@laptop:~$ cat /proc/meminfo
MemTotal: 2052912 kB
Cached: 929652 kB
Dirty: 185268 kB
Writeback: 13020 kB

Ma mémoire totale est de 2 Go, j'ai 929 Mo en cache et il y a 185 Mo qui sont marqués comme « dirty », c'est-à-dire qu'ils sont en chemin pour être écrits sur le disque. Enfin 13 Mo de données sont vraiment en cours d'écriture sur la clé USB.
On comprend bien que l'affichage de ces totaux de pages « dirty » et « writeback » change en permanence en fonction de l'état du système et qu'un cat /proc/meminfo lancé quelques secondes plus tard donnera un autre résultat.

Quand on présente les choses comme ça, tout a l'air simple et clair. En réalité, ce mécanisme est assez fragile et source de nombreux problèmes. Que faire, par exemple, quand un processus génère une grosse quantité de pages « dirty », plus que ce que peut accepter le système ? Dans ces conditions, le noyau passe en mode « direct reclaim » c'est-à-dire qu'il va explicitement essayer de libérer des pages mémoires.
La fonction de « direct reclaim » n'est pas très bien considérée par les développeurs du noyau, car elle a tendance à dégrader fortement les performances d'entrées/sorties du système. C'est quand même gênant de réduire ainsi la bande passante vers le disque, alors que la situation initiale était justement un trop-plein de page « dirty » !
Si on ajoute à ça les risques de débordement de la pile (stack overflow), on comprend mieux les nombreuses tentatives des développeurs pour améliorer ce système du « direct reclaim ».

Wu Fengguang est parti d'une autre idée. Si le « direct reclaim » n'est pas réellement efficace, alors il ne sert à rien de passer dans ce mode. Autant travailler en amont, par exemple sur la gestion fine du débit des pages « dirty », afin de ne pas se faire submerger.
Son ensemble de patchs se nomme en anglais « IO-less dirty throttling » parce que le but est d'étrangler plus ou moins le flux des pages dirty qui vont être envoyées pour écriture sur le disque. Une régulation par rétroaction automatique est mise en place afin de trouver le ratio idéal de pages « dirty ».
Quand le nombre de pages est faible, alors l'étranglement du flux (le throttling) se relâche pour augmenter le débit.
De même, quand le nombre de pages est trop élevé, alors l'étranglement devient progressivement de plus en plus fort. Cette réduction du débit se fait très simplement puisque le code place le processus en « sleep » pendant une certaine période.
Ce message de commit de Wu est particulièrement explicite sur le mécanisme mis en place. J'en copie sans vergogne les schémas en ascii-art.

Système précédent de gestion des pages « dirty »:

                           aucune contrainte  |  zone d'intervention
----------------------------------------------+---------------------------->
                                                                 nombre de pages dirty

On voit bien qu'il existe une zone n'ayant aucune contrainte et puis, brusquement, quand un seuil déterminé est franchi, le noyau tente de réduire à tout prix le flux de pages.

Nouveau système avec rétroaction:

  ^
  |           * 
  |            *
  |             *
  |              *
  |                *
  |                  *
  |                     *
  |                         *
  |                               *
  |                               .     *
  |                               .          *
  |                               .              *
  |                               .                 *
  |                               .                    *
  +-------------------------------.-----------------------*------------>
                          OBJECTIF^                 LIMITE^       nombre de pages dirty

Le code prend en compte la quantité globale de pages ayant le flag « dirty » et il confronte ce chiffre avec la cible à atteindre (OBJECTIF) et avec le maximum absolu qui a été défini (LIMITE). Malheureusement, on ne peut pas se contenter d'un ratio aussi simple et il faut prendre en compte les différents périphériques (ou plutôt des BDI ce qui signifie Backing Device Info et qui est une abstraction au-dessus des périphériques réels).
Après tout, un BDI particulier peut être saturé en pages « dirty » sans que le système lui-même ne soit proche de la limite. Le calcul final est donc un ratio par BDI que Wu nomme le pos_ratio (le ratio en fonction de la position sur la courbe).
Le processus qui envoie des données pour écriture est donc tenu d'une main ferme par le code gérant la mémoire virtuelle. Dans le cas où il enverrait un déluge de pages « dirty », alors la pression de rétroaction se ferait de plus en plus forte (il passerait en « sleep » de plus en plus souvent), afin de réguler ce flux.
Tous ces calculs, et les formules qui sous-tendent le fonctionnement du mécanisme, sont détaillés dans ce message de Fengguang Wu (attention au risque élevé d'explosion cérébrale en essayant de comprendre les détails !). Un fichier PDF récapitulatif est également disponible pour ceux qui voudraient comprendre plus en profondeur le travail de Wu Fengguang (et des autres hackers ayant collaboré avec lui).

Bien entendu, avant d'accepter ce nouveau mécanisme invasif, les tests ont été particulièrement nombreux. Le code qui gère la mémoire virtuelle est notoirement sensible et tout changement est scruté de près sur la LKML. Ainsi, de nombreux points de traçages ont été incorporés dans le code afin de vérifier le bon comportement de ce système de gestion dynamique du « writeback ». Les régressions concernant NFS ou les disques JBOD ont été résolues une à une, jusqu'à ce que les mainteneurs du noyau soient satisfaits du résultat.

À l'issue de tout ce travail, le noyau Linux 3.2 permet donc de gérer de manière bien plus efficace la fonction de « writeback », sans risquer l'engorgement comme c'était le cas auparavant. D'après les tests de Wu Fengguang, le gain ne se situe pas nécessairement au niveau du débit de données, mais plutôt dans la réduction de la charge processeur :

Sur un simple test de 100 dd, on observe que le %system time du CPU passe de 30 % à 3 % et que le débit d'entrées/sorties passe de 38 Mo/s à 42 Mo/s.

Les résultats sont donc très encourageants et ce n'est pas un hasard si le patch de « dirty throttling » a été évoqué explicitement dans le mail de RC-1 envoyé par Linus. Bien entendu, la véritable épreuve du feu commence maintenant, avec la sortie officielle du noyau. Comme Linus le dit lui-même : Let's see how that all works out.

En bref

SHA-1 optimisé

La rapidité de la fonction de hachage cryptographique SHA-1 a été améliorée spécifiquement pour l'architecture x86-64 dans le noyau 3.2.
C'est le développeur Mathias Krause qui a proposé plusieurs séries de patchs pour ajouter une implémentation de SHA-1 en assembleur dans le noyau Linux. Le nouveau code exploite à fond les jeux d'instructions vectorielles SSSE3 et AVX.
D'après les tests effectués par Mathias sur un tunnel IPsec, et avec un processeur Core 2 Quad cadencé à 2,4 GHz, on obtient les chiffres suivants :

SHA-1 classique : 344 Mbit/s
SHA-1 optimisé : 464 Mbit/s (soit un gain d'environ 34 %).

Bien entendu, l'implémentation classique de SHA-1 en langage C reste présente dans le code de Linux et sert de recours (fallback), au cas où l'utilisation du code optimisé n'est pas possible.

Blowfish et Twofish

Il n'y a pas que SHA-1 à profiter d'une implémentation toute neuve en assembleur. Les algorithmes de chiffrement symétrique Blowfish et Twofish vont aussi pouvoir en bénéficier dans le nouveau noyau Linux 3.2.
Ces deux algorithmes, des créations de Bruce Schneier et de ses collaborateurs, sont moins connus qu'AES, mais ils restent utilisés dans de nombreux logiciels.
C'est le développeur finlandais Jussi Kivilinna qui a proposé pour ce cycle plusieurs patchs d'optimisation des performances. L'idée derrière le code est de viser les processeurs modernes (architecture x86_64 et traitement out-of-order) en proposant des chemins alternatifs optimisés.

Twofish avait déjà un code en assembleur (dans /arch/x86/crypto/twofish-x86_64-asm_64.S), mais celui-ci ne chiffrait qu'un bloc à la fois. Avec le patch de Jussi, ce sont trois blocs de données qui seront traités en parallèle (d'où le nom twofish-x86_64-asm_64-3way.S donné au fichier source). Le message de commit donne de nombreux résultats de tests en fonction des divers modes de chiffrement, on note par exemple qu'en mode ECB, on peut espérer une vitesse de chiffrement ou de déchiffrement multipliée par 1,3.

Le cas Blowfish est un peu différent puisqu'il n'existait pas - jusqu'à présent - d'implémentation en assembleur. Le code présent dans le noyau 3.2 devrait donc permettre des gains très substantiels sur les processeurs x86_64 modernes. Jussi a pris la peine de faire les choses bien avec deux chemins, le premier qui travaille de façon classique sur un bloc à la fois, alors que le second peut chiffrer ou déchiffrer quatre blocs à la fois.
Dans le message de commit du premier septembre, on trouve un test tcrypt entre l'ancienne implémentation en C et la nouvelle en assembleur. Un gain d'un facteur 2,2 ou 2,3 en mode ECB a été constaté. Le 23 septembre dernier, Jussi a soumis un dernier patch d'amélioration qui permet de gagner encore 15 % (sur AMD Phenom II) par rapport à son code initial.

RAID-5 pour Exofs

Exofs est un système de fichiers bien particulier. Ayant fait son entrée dans le noyau Linux 2.6.30, il est basé sur l'idée des « Object storage devices ». Cela signifie que le système d'exploitation ne gère plus directement les blocs et les secteurs du disque, mais se contente d'interagir avec des « objets » abstraits qui ont chacun un identifiant sur 64 bits, ainsi que des attributs et des méta-données associées. Tout le code de gestion bas niveau sur les blocs et les secteurs est délégué au micrologiciel du disque. Cela lui permet, en théorie, de prendre de meilleures décisions que l'OS.
Quelle que soit l'opinion que l'on ait à propos de cette idée, Linux propose ce système de fichiers et des développeurs continuent de travailler à son amélioration. Dans la dépêche du noyau 2.6.34, il était indiqué que le mode RAID-0 avait été intégré et que son auteur, Boaz Harrosh, travaillait maintenant sur le mode RAID-5. Cela a été plus long que prévu, mais la prise en charge du RAID-5 entre maintenant dans le noyau 3.2 (1 - 2 - 3). Si on en croit le message d'annonce de Boaz, le code est conforme avec la norme IETF qui décrit la gestion des objets dans le standard « Parallel NFS » pNFS.

Tout cela est bel et bon, mais le fait d'intégrer dans le noyau une troisième implémentation du RAID-5 - en plus de celles qui existent dans MD et DM - a fait froncer quelques sourcils. Boaz s'est donc empressé de signaler que le code ORE (Objects Raid Engine) était très générique et pouvait donc être réutilisé par d'autres systèmes n'ayant pas encore de gestion RAID-5 (par exemple Btrfs).
En dépit de ces arguments, on peut penser qu'un travail de consolidation dans ce domaine sera nécessaire à plus ou moins brève échéance.

Hexagon

Après OpenRISC dans le précédent noyau, c'est maintenant l'architecture Hexagon de Qualcomm qui intègre l'arbre des sources de Linux.
Cette puce Hexagon est assez inhabituelle puisqu'il s'agit, à la base, d'un processeur de signal numérique (un DSP). En temps normal, une telle architecture ne fait pas tourner un système d'exploitation comme Linux, elle est seulement utilisée comme processeur d'appoint pour accélérer les calculs numériques (codecs vidéos par exemple).
La firme Qualcomm a conçu Hexagon comme étant un hybride qui peut faire tourner un OS généraliste et elle axe sa communication sur ce point :

Hexagon merges the numeric support, parallelism, and wide computation engine of a DSP, with the advanced system architecture of a modern microprocessor.

Si on excepte le paragraphe introductif de Richard Kuo dans le premier patch de sa série, on trouve assez peu de détails sur le web à propos de l'architecture Hexagon. N'écoutant que mon courage, et pénétré de ma mission sacrée au service des lecteurs de LinuxFr, j'ai donc créé un compte sur le serveur « Qualcomm Developer Network » afin de pouvoir télécharger les documents techniques.
Il s'avère qu'Hexagon est un processeur possédant trente-deux registres 32 bits, avec des instructions qui peuvent être regroupées dans des « mots » de grande taille (architecture VLIW). Des unités vectorielles sont également présentes afin de faire des calculs de type SIMD. On trouve, bien entendu, une unité de gestion mémoire MMU et aussi la gestion du multiprocesseur via SMP. Le cache L1 est de 2 fois 32 Kio (données et instructions), tandis que le cache L2 est actuellement de 256 Kio, mais cette quantité augmentera sans doute dans les futures versions.
Il est à noter qu'Hexagon implémente un hyperviseur matériel natif (HVM pour Hexagon Virtual Machine) et que Linux tourne via cette couche de virtualisation. Selon les documents, cela permet de faire fonctionner en même temps une application temps-réel fortement optimisée pour un matériel spécifique et aussi un OS généraliste.
Nous verrons avec le temps si les choix de Qualcomm se révèlent justes, et comment s'opérera le partage des tâches sur les machines ayant un coeur ARM et un DSP Hexagon. Ce qui est certain, c'est que cette architecture Hexagon qu'intègre le noyau 3.2 est prometteuse et novatrice.

AMD Bulldozer

L'architecture Bulldozer des nouveaux processeurs AMD n'a pas provoqué un enthousiasme délirant dans la presse spécialisée.
La conception des puces Bulldozer est assez originale, puisqu'elle brouille la définition de ce qu'est un coeur de calcul sur un processeur. La brique de base se nomme « module » et elle contient deux pseudo-cœurs qui partagent les unités de chargement et de décodage des instructions (le front end), ainsi que l'unité de calcul sur les flottants (FP). L'idée est que ce partage n'aura que peu d'impact sur les performances et qu'il permettra d'économiser de la place pour ajouter encore plus de « modules » sur la surface de silicium.
L'ennui, c'est que ce fonctionnement est inhabituel et que les systèmes d'exploitation devront être adaptés finement pour profiter au maximum de cette architecture.
Par exemple, il s'est avéré que le partage du cache L1 des instructions entre les deux pseudo-cœurs posait, dans certains cas, un problème d'invalidation des données dans le cache. Le patch écrit par Borislav Petkov pour le noyau Linux 3.2 vise à corriger ce comportement et permet de gagner environ 3 % de performances dans un benchmark stressant le processeur.
Comme ce patch change le mode de gestion du cache, il a été décidé d'offrir le choix aux utilisateurs de l'utiliser ou pas. La nouvelle option align_va_addr doit donc être passée au noyau lors du démarrage avec quatre valeurs possibles :

1: Activation de la fonction seulement pour les processus 32 bits.
2: Activation de la fonction seulement pour les processus 64 bits.
on : Activation de la fonction pour les processus 32 ou 64 bits.
off : Désactivation de la fonction.

DVFS

Depuis longtemps, le noyau est capable de réduire la fréquence et la tension d'alimentation du processeur, afin d'obtenir un fonctionnement optimal entre performance et consommation. Ce n'est pourtant pas le seul composant capable d'une telle adaptation, mais le processeur étant le principal consommateur d'énergie, personne ne s'était jusqu'à maintenant penché sur les autres puces.
Une nouvelle interface de programmation a été intégrée dans le noyau 3.2 pour faciliter cette gestion de la consommation de tous ces périphériques. Cette API, nommée DVFS (pour Dynamic Voltage and Frequency Scaling), permet de gérer le matériel en se reposant sur des gouverneurs, comme c'est le cas pour le processeur central.
Le développeur d'un pilote voulant profiter de DVFS va d'abord se servir de l'infrastructure OPP (Operating Performance Points) incluse dans le noyau 2.6.37 et qui permet de déclarer les couples fréquences/tensions disponibles pour le périphérique. Une fois cela déclaré, il va initialiser une structure pour déclarer la fréquence de fonctionnement de départ de son périphérique (initial_freq) et indiquer s'il souhaite que le gouverneur de fréquence interroge périodiquement le matériel (polling). Pour des besoins spécifiques, il est possible d'écrire un gouverneur dédié mais, en général, les développeurs utiliseront ceux qui ont été ajoutés dans le noyau pour cette fonction devfreq:

• devfreq_powersave => On force la fréquence la plus basse disponible.
• devfreq_performance => On force la fréquence la plus haute disponible.
• devfreq_userspace => On ne prend aucune décision et on s'en remet, via sysfs, à un programme en espace utilisateur.
• devfreq_simpleondemand => On essaye d'avoir un équilibre entre les performances et la consommation.

Il est nécessaire d'avoir des gouverneurs distincts de ceux gérant le processeur car cpufreq n'accepte pas d'avoir plusieurs périphériques hétérogènes enregistrés.
Bien entendu, ce mécanisme devfreq s'interface avec le code gérant la qualité de service (QoS) pour être certain que la réduction de la consommation ne se fera pas au détriment des obligations décrites dans cette API.

Il est à noter qu'à l'heure actuelle, cette interface DVFS n'est pas encore utilisée par un quelconque matériel… mais les prochains noyaux devraient voir arriver les premiers pilotes utilisant cette nouvelle possibilité.

Samba va plus vite

Le système de fichiers CIFS (Samba), qui est utilisé pour partager des ressources en réseau avec des machines Windows, a reçu un important patch écrit par Jeff Layton.
Dans le noyau Linux 3.2, CIFS peut maintenant faire des appels asynchrones en lecture vers le serveur distant. Cette nouvelle infrastructure cifs_async_readv permet de réduire les temps d'attente et les tests effectués par Steve French montrent un gain substantiel.
Selon cette évaluation, basée sur dbench (avec soixante processus), on peut espérer une amélioration d'environ 5 % par rapport au noyau précédent.

SLUB

Christoph Lameter continue de travailler sur l'allocateur mémoire SLUB. Après ses patchs du noyau 3.1 qui visaient à retirer des verrous inutiles, Christoph a cette fois concentré son attention sur la quantité de travail effectué après la prise du verrou.
Par exemple, le noyau 3.2 permet, quand le verrou list_lock est posé, de traiter plusieurs pages partielles au lieu d'être limité à une seule. Dans son message de commit, le mécanisme est détaillé et il donne les résultats d'un test hackbench :

./hackbench 100 process 20000
Avant : 207.176 secondes
Après : 156.940 secondes

Améliorations de Btrfs

Les développeurs de Btrfs continuent d'améliorer les performances de leur bébé afin qu'il puisse, un jour, prendre la succession d'Ext4 en tant que système de fichiers de référence sous Linux. Le plan annoncé par Oracle d'utiliser Btrfs par défaut dans leur distribution dérivée de Red Hat Entreprise Linux, a conduit à mettre également l'accent sur la fiabilisation et les corrections de bugs.

Le noyau 3.2 voit notamment l'introduction du mécanisme générique de « readahead », ce qui permet d'implémenter des stratégies de lecture des données bien plus efficaces.
Après un appel à btrfs_reada_add, les extents du système de fichiers, c'est-à-dire les zones de stockage contiguës qui ont été pré-allouées, vont pouvoir être mis en cache plus efficacement. En outre, comme chaque disque a son cache readahead, on peut les utiliser en parallèle pour augmenter le débit.

Un autre raffinement concerne les disques en configuration miroir. Au lieu de lancer un readahead sur les mêmes zones (ce qui reviendrait à gâcher les capacités de recherche), le système lit des parties différentes du système de fichiers afin, là aussi, de maximiser les performances.
Tout ce travail paye puisque, selon les tests effectués par Arne Jansen, la fonction de scrubbing (vérification des sommes de contrôles des extents et des superblocs présents sur le volume de stockage) est grandement améliorée. En abandonnant l'énumération naïve des arbres de données au profit du mécanisme de readahead, le système d'Arne passe de 89s à seulement 43s pour vérifier un volume.
En outre, ce scrubbing est plus intelligent puisque l'ancien système ne renvoyait que le numéro du bloc corrompu en cas d'erreur. Le code intégré dans le noyau 3.2 permet maintenant d'obtenir directement le nom du fichier impacté, ce qui facilite le travail de l'administrateur.

Parmi les autres améliorations, on peut citer la nouvelle option de montage -o recovery qui permet de monter une racine de secours au cas où le montage de la racine principale est impossible.
Il y a aussi le patch de Josef Bacik, qui relâche un peu les contraintes vis-à-vis de l'erreur ENOSPC (plus d'espace sur le disque). En ayant une stratégie plus fine (évaluation en temps réel de l'espace libre), on peut respecter les garde-fous mis en place pour éviter l'erreur ENOSPC tout en améliorant les performances. La connaissance de la quantité d'espace non alloué permet de faire de l'overcommit. Dans son message de commit, Josef signale qu'un test simpliste d'écritures aléatoires sur un volume de 3 Tio passe de 45 minutes à seulement 10 secondes !

Cross memory attach

Le patch de « cross memory attach » développé par Christopher Yeoh a été incorporé dans le noyau Linux 3.2.
Le but de ce travail est d'améliorer les performances des processus qui utilisent le protocole MPI (Message Passing Interface). Cette norme est souvent utilisée dans le calcul haute performance puisqu'elle permet aux très nombreux processeurs d'un supercalculateur d'échanger des messages pour traiter les données.

Au sein d'un noeud de calcul (intra-node), il est nécessaire de procéder à deux opérations de copies de données. En gros, on a l'émetteur qui copie depuis son espace d'adressage dans un segment partagé et le receveur qui copie depuis ce segment partagé dans son espace d'adressage à lui.
Avec la fonction de « cross memory attach », il n'est plus nécessaire d'en passer par ce mécanisme à double-copie.
L'émetteur va simplement envoyer au receveur une adresse mémoire et une taille. Le receveur va alors lire et copier directement les données (puisqu'il a l'adresse et la taille) dans son propre espace d'adressage. La fonction utilisée est process_vm_readv() (voir les explications sur la page de man).
L'opération inverse est également prévue et le processus émetteur peut ainsi écrire directement dans l'espace d'adressage du receveur via la nouvelle fonction process_vm_writev.

Christopher Yeoh a modifié la bibliothèque Open MPI pour qu'elle exploite cette nouvelle possibilité de « cross memory attach » et il a lancé plusieurs benchmarks sur une machine ayant 64 coeurs POWER6. Comme on pouvait s'y attendre en supprimant une coûteuse opération de copie, les tests montrent un gros gain de performance :

Nombre de Processus         4   8   16  32
Nb de Mo/s sans le patch    1235    935 622 419
Nb de Mo/s avec CMA     4741    3769    1977    703

DM et « thin provisioning »

La couche « device mapper », qui permet de mapper un périphérique en mode bloc sur un autre, a reçu plusieurs ajouts intéressants dans le nouveau noyau.
C'est tout d'abord la bibliothèque des données persistantes qui est prévue pour stocker toutes les métadonnées des cibles du « device mapper ». Comme les fonctions du DM se complexifient, il devient payant de regrouper toutes les structures de données qui étaient utilisées auparavant par une couche générique.

Un des premiers utilisateurs de cette « persistent-data library » est la nouvelle application permettant de faire de l'allocation fine et dynamique (thin provisioning). Dans le cadre d'un SAN, plutôt que d'allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l'espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n'occupera que l’espace réellement consommé. C'est avantageux car les pages non utilisées par un client peuvent être réallouées à d'autres (via la fonction de Zero Pages Reclaim).
Cette implémentation du « thin provisionning » dans le noyau 3.2 est encore marquée comme expérimentale. Elle est fort prometteuse puisqu'elle autorise la prise d'images (snapshots) à volonté et avec une administration simplifiée. Ces snapshots peuvent être hiérarchiques et le coût en performance ne dépend plus de la profondeur d'imbrication.

Enfin, dernier ajout notable au « device mapper », un cache spécialement adapté pour les entrées/sorties a été développé. Ce cache, nommé bufio, est plus efficace que les caches génériques du noyau, car il a été pensé dès le début pour satisfaire les besoins du DM. Le module de « thin provisionning » est pour l'instant le seul utilisateur de ce nouveau cache, mais il est probable que d'autres cibles DM seront converties par la suite.

TAINT_OOT_MODULE

En octobre dernier le développeur Dave Jones a proposé sur la LKML de marquer spécifiquement les noyaux ayant chargé le module externe VirtualBox. Dave semble avoir une piètre opinion de ce module vboxdrv:

Le nombre de rapports de bug que nous recevons d'utilisateurs ayant le module virtual box chargé est vraiment stupéfiant.
C'est sous GPL mais, hélas, cela ne veut pas dire que c'est de bonne qualité.

Il a donc proposé de marquer avec le drapeau « TAINT_CRAP » les noyaux ayant chargé ce module maléfique qui fait planter les systèmes et qui remplit sa boîte mail. Habituellement, le drapeau « TAINT_CRAP » est réservé aux pilotes de la branche -staging, pour indiquer que ces pilotes n'ont pas le niveau de qualité requis. Un rapport de bug dévoilant que le noyau a été marqué avec ce drapeau peut voir sa priorité réduite, ou même être tout simplement ignoré.
Greg KH a semblé enchanté par cette proposition de Dave Jones :

J'aime ça, et je pense que je vais l'ajouter aux noyaux d'OpenSUSE. Comme ça nous pourrons éviter les nombreux rapports de bugs que nous recevons au sujet de ce pilote tout pourri.

Toutefois, au fil de la discussion, plusieurs personnes ont proposé des solutions alternatives à l'infâmant stigmate « TAINT_CRAP ». L'idée de Pekka Enberg d'ajouter le module vboxdrv à la branche -staging pour l'améliorer a été rapidement rejetée (toi tu n'as jamais lu le code de ce module hein ?).
Frank Mehnert, qui travaille chez Oracle, a annoncé qu'il acceptait volontiers l'idée de marquer spécialement les modules ne faisant pas partie de la branche principale. En revanche, c'est étonnant, Frank n'était pas spécialement emballé par le terme de « CRAP » ;-)
Bastian Blank est intervenu pour signaler que Debian utilisait depuis un certain temps un patch marquant tous les modules externes avec le drapeau « TAINT_OOT_MODULE ».
C'est cette idée qui a finalement été acceptée par tous et qui fait son entrée dans le noyau Linux 3.2. Comme le code externe est bien moins testé que celui qui fait partie de la branche principale, ce sont donc tous les modules externes (Out Of Tree) qui sont marqués avec « TAINT_OOT_MODULE », et plus seulement VirtualBox.

Hibernation

Le code de la fonction d'hibernation inclus dans le noyau 3.2 a été amélioré par le développeur Bojan Smojver.
Quand l'ordre de mise en hibernation est envoyé au noyau, alors le contenu de la mémoire vive (RAM) est compressé puis sauvé sur le disque dur. À l'inverse, au moment du réveil, le disque est lu et les données sont décompressées pour revenir à l'état d'avant l'hibernation. C'est ce qui différentie l'hibernation de la simple mise en veille (Suspend) où la RAM est toujours alimentée.
Dans le cas de l'hibernation, le goulot d'étranglement est clairement la vitesse du périphérique de stockage, et c'est pour ça que l'étape de compression est utile. Même s'il s'agit d'une opération de compression coûteuse, le jeu en vaut la chandelle puisque des poignées de secondes seront économisées au moment d'écrire les données sur le disque.
Le patch de Bojan permet maintenant de faire de la compression/décompression multithread avec l'algorithme LZO. Cet usage des threads (LZO_THREADS) est limité à trois pour ne pas surcharger la mémoire… ce qui serait une mauvaise idée alors qu'on veut passer en hibernation !
Le patch ajoute également la vérification des données via CRC32 pour améliorer la robustesse des transferts entre la mémoire et le disque.
D'après les tests effectués par Bojan Smojver, le multithreading de la compression LZO a tout simplement doublé la vitesse de lecture/écriture sur son système.

Sous-système de contrôle des broches

Les systèmes complets embarqués sur une puce (SoC) ont souvent un brochage assez particulier. Il leur est possible, via un « pin controller », de gérer de façon complexe les broches du processeur. On peut multiplexer les pattes, faire varier les caractéristiques électriques, etc.
Le noyau Linux 3.2 offre aux développeurs un nouveau sous-système qui permet de gérer ces broches contrôlables et qui va, dans le futur, réduire les doublons de code au sein de l'architecture ARM.
Pour l'instant, ce « pin control subsystem » est limité à l'énumération et au nommage des broches (pinmuxing), mais les prochains noyaux apporteront la prise en charge des fonctions de gestion électrique. Linus Walleij, développeur Linaro à l'origine de ce travail, a indiqué dans son message de commit ce qui motive cet ajout :

Le but de ce travail est de dépeupler le répertoire arch/arm/* de tous les pilotes spécifiques et d'essayer d'avoir une infrastructure d'abstraction pour toutes les fonctions dont ils ont besoin.

La documentation du sous-système de contrôle des broches est très complète et le pilote ARM U300 a été converti pour servir de référence aux autres développeurs.

Pilotes graphiques

Dans le domaine des pilotes graphiques, on note l'activation de la gestion PCI-Express 2.0 pour les cartes « Northern Islands », c'est-à-dire la série des Radeon HD 6000. Divers patchs ont également été postés pour réorganiser et accélérer les opérations de blit (en gros il s'agit de combiner plusieurs bitmaps lors d'une opération de rasterisation).

En ce qui concerne les cartes NVidia et le pilote « Nouveau », on trouve notamment les patchs de refonte de la gestion de DisplayPort ainsi que l'activation de l’accélération pour les architectures NVC1, NVC8 et NVCF (1 - 2 - 3). En revanche, le travail sur la gestion des fréquences (re-clocking) n'a pas encore abouti et n'a pas pu être intégré.

Le pilote Intel i915 a été nettoyé d'un grand nombre de bugs. Le mail d'annonce de Dave Airlie cite en particulier les corrections à destination des Macbook Air d'Apple, ainsi que les patchs pour RHEL. Le patch permettant la gestion de trois moniteurs sur puce Ivy Bridge a été également intégré.
Un autre patch notable pour le pilote Intel est celui qui active la gestion du mode d'endormissement RC6. Quand le processeur graphique n'a rien à faire, il peut ainsi passer en veille profonde et réduire drastiquement la consommation (un passage de 21.5 watts à seulement 15 watts sur un laptop Sandy Bridge est évoqué dans cet article).
L'activation de RC6 avait été tentée puis retirée dans le noyau précédent, à cause de divers crashs. Maintenant que la situation semble mieux maîtrisée, il peut faire partiellement son retour.
Selon le premier message de commit de Keith Packard, ce mode RC6 ne fonctionne que sur les puces Ivy Bridge (inconditionnellement) et sur les puces Sandy Bridge (si VT-d est désactivé).
Néanmoins, à la dernière minute, Keith a demandé à Linus de désactiver une nouvelle fois le mode RC6 pour les processeurs Sandy Bridge. Seuls les Ivy Bridge pourront donc profiter pour l'instant de cette économie de consommation.

Après avoir parlé des trois « grands », il faut également signaler la sortie de -staging du pilote vmwgfx utilisé par VMware ainsi que l'introduction du pilote Samsung Exynos4 dans le nouveau noyau 3.2. C'est le tout premier pilote DRM pour un System-on-chip ARM à entrer dans la branche principale. Bien entendu, il ne faut pas s'exciter trop vite et le pilote est encore loin d'être complet. Pour l'instant, il ne s'occupe que du « kernel mode-setting » et de la gestion de la mémoire (via GEM). Pas d'accélération 2D ou 3D à l'horizon et il reste à voir si Samsung va travailler pour proposer un pilote libre en espace utilisateur.

Cronopio dentiacutus

Comme c'est devenu l'habitude, Linus Torvalds a encore une fois changé le nom de code par défaut du noyau. Après le très sage « Divemaster Edition » de Linux 3.1 on revient aux noms animaliers dans cette édition 3.2. Le commit de Linus a été effectué le 8 novembre, au moment de la première version candidate, et il indique que le nom de code est maintenant Saber-toothed squirrel (écureuil à dents de sabre).
On pourrait penser qu'il ne s'agit, comme la fameuse « Belette rose péteuse », que d'une manifestation de l'humour particulier de Linus. En fait le commentaire associé nous indique le contraire:

Linux 3.2-rc1 avec un nouveau nom. Parce que rien ne respire mieux la « version de qualité du noyau » que de le nommer d'après un animal disparu qui a fait les gros titres récemment.

En effet des paléontologues américains et argentins viennent de publier un article dans la revue Nature pour annoncer la découverte, en Amérique du Sud, d'un spécimen de petit mammifère à dents de sabre. Ce Cronopio dentiacutus a suscité l'intérêt du grand public et les articles de vulgarisation ont fleuri sur la toile (1 - 2).
Avec un air aussi féroce, nul doute que ce Scrat du Crétacé représentera dignement le noyau 3.2.

Statistiques

Du côté des statistiques, le site LWN a publié son classique article récapitulatif pour le noyau 3.2.
Ce cycle a été particulièrement chargé, avec plus de 11 800 patchs ayant intégré la branche principale. C'est une très honorable médaille de bronze au classement des plus grosses versions de tous les temps. Pour l’anecdote, la médaille d'argent revient au 2.6.30 avec 11 989 commits et la médaille d'or au 2.6.25 avec 12 243 patchs.
Ce nombre imposant de changements intégrés dans le nouveau noyau 3.2 s'explique en partie par la compromission ayant affecté les serveurs de kernel.org.
Linus a retardé l'ouverture de la période de merge parce qu'il préférait que tout revienne à la normale avant d'ouvrir les digues. Le travail des développeurs s'est donc quelque peu accumulé avant d'être finalement intégré dans ce noyau.

Si on regarde le classement des entreprises contributrices, on remarque que la domination relative de Red Hat semble s'éroder lentement. Les patchs restent nombreux (près de 1 000 dans ce cycle), mais la montée en puissance de sociétés comme Qualcomm ou Samsung dilue quelque peu ce travail, puisqu'il ne représente plus que 8,5 % du total.
Les employés de Microsoft continuent de travailler sur leur pilote de virtualisation Hyper-V avec 177 patchs de plus. La sortie du pilote de la branche -staging est programmée pour le noyau 3.3.
Au total, selon les chiffres de LWN, ce sont les développeurs de 191 entreprises différentes qui ont participé à ce cycle. Cela démontre une fois de plus la vitalité et la résilience qui caractérisent le développement de Linux. Comme le dit Jonathan Corbet :

En d'autres termes, le processus de développement semble continuer à fonctionner très correctement, et ce en dépit des difficultés de kernel.org et de l'ouverture retardée de la fenêtre de merge.
Tôt ou tard, nous sommes condamnés à rencontrer un problème qui aura un impact important - la vie est comme ça - mais cela ne s'est pas produit cette fois-ci.

Pour la suite

Pilotes Android

Après le retrait des pilotes Android de la branche -staging au moment du noyau 2.6.33, aucun vrai effort de réunification n'avait été tenté. Pourtant, un peu à la surprise générale, les développeurs Linux ont profité du sommet du noyau de Prague, en octobre dernier, pour se mettre d'accord sur un projet de réintégration de ce code ayant divergé.

À la suite de cette décision, un plan a été tracé et c'est Tim Bird, employé par Sony, qui a annoncé le 20 décembre la naissance de « Android mainlining project ». Un wiki dédié a été mis en place pour coordonner les efforts et le noyau 3.3 verra l'intégration de nombreux patchs. D'après Greg KH, ce prochain noyau devrait presque pouvoir faire démarrer l'environnement user space d'Android (the next linux-next Linux kernel release should almost boot an Android userspace).

Si on regarde le répertoire Android de la branche -next (c'est-à-dire la branche accueillant les patchs qui vont entrer dans le noyau 3.3), on constate que de nombreuses pièces critiques de l'infrastructure Android sont présentes. Qu'il s'agisse de hashmem (mécanisme de partage mémoire) de binder (permettant la communication inter-processus) ou encore de logger (infrastructure de log), tous ces sous-systèmes vont être ajoutés au prochain noyau Linux.

Bien entendu, ce n'est que le début du chemin et de nombreux pilotes seront encore absents dans la branche principale.
Il faudra également s'attaquer au gros morceau qu'est le patch wakelock si on veut que le système, une fois démarré, ne vide pas la batterie à une cadence accélérée.
Néanmoins, le delta entre le noyau Linux et le noyau que Google utilise dans Android va se réduire considérablement à brève échéance. C'est indéniablement une très bonne nouvelle.

Aller plus loin

• LWN 1: Les nouveautés du noyau 3.2 (1318 clics)
• LWN 2: Les nouveautés du noyau 3.2 (591 clics)
• Les articles récapitulatifs du site h-online.com (148 clics)
• La liste des nouveautés sur kernelnewbies.org (459 clics)