Sortie de la version 2.6.37 du noyau Linux

La sortie de la version stable 2.6.37 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).

PS : Outre mes camarades relecteurs/modérateurs je tiens particulièrement à remercier davy78 qui a bien voulu accepter de relire longuement la dépêche pour traquer les fautes et me permettre de les corriger.

Le sommaire...

• La phase de test
  
  • RC-1
    
  • RC-3
    
  • RC-4
    
  • RC-5
    
  • RC-6
    
  • RC-7
    
  • RC-8
• Les nouveautés
  
  • Améliorations d'ext4
    
  • FITRIM
    
  • Allocateur mémoire memblock
    
  • Contrôleur IO-block et limiteur de débit
    
  • Barrières et systèmes de fichiers
    
  • Jump label
    
  • La fin du BKL
• En bref
  
  • CFS et processus RT
    
  • Btrfs
    
  • Ceph
    
  • NFS
    
  • Pilote Nouveau
    
  • Pilote AMD
    
  • Pilote Intel
    
  • SELinux
    
  • Perf
    
  • HWPOISON et Hugepages
    
  • Hibernation
    
  • Xen
    
  • KVM
    
  • Protocole PPTP
    
  • Architecture Tile
    
  • Accès Syslog
    
  • Tiny RCU préemptible
    
  • Speakup
    
  • Pilote btusb
    
  • Autosuspend
    
  • Fanotify
    
  • Prise en charge de OPC pour les SoC
    
  • Pilote Wi-Fi Broadcom
    
  • Protocole IBoE
• Le bilan en chiffres
  
• Pour la suite
• Optimisations VFS

La phase de test (↑)

RC-1

C'est le premier novembre, seulement dix jours après la sortie du 2.6.36, que Linus a annoncé la sortie de la version candidate 2.6.37-RC-1 :

« La période de merge est terminée et la RC1 est disponible. Il y a un paquet de changements là-dedans, près de 10k commits depuis le 2.6.36, en dépit de la fenêtre de merge un peu réduite. Le truc qui à mon avis mérite d'être mentionné, c'est que nous avons quasiment éliminé le BKL (Big Kernel Lock) de tout le cœur du code. Vous pouvez facilement compiler un noyau sans aucune gestion du BKL. Cela a été une longue route et merci à Arnd et aux autres qui ont travaillé là-dessus.
Notez que "le cœur du code" ne signifie pas "partout". Il y a encore des pilotes qui ont besoin du BKL et si vous configurez votre noyau sans lui vous ne pourrez plus configurer les pilotes V4L par exemple. Ils continuent d'utiliser les appels lock_kernel/unlock_kernel mais j'espère que ce sera également corrigé de façon à ce que, dans un futur pas trop lointain, nous n'ayons plus que quelques vieux pilotes obscurs que personne n'utilise qui auront besoin du vieux verrou ».

RC-2

Après le sommet 2010 du noyau Linux, qui s'est déroulé cette année à Cambridge (Massachusetts), Linus Torvalds a publié la RC-2 avec une semaine de retard par rapport à son rythme hebdomadaire habituel :

« Cela fait deux semaines depuis la RC1, en grande partie à cause du sommet du noyau et des plumbers conferences. Le résultat c'est que ça a été vraiment très calme.
En dépit de ce délai de deux semaines le nombre de changements entre la RC1 et la RC2 est tout à fait normal. En nombre de commits (cela tourne autour des 500+, mais il y a des exceptions: le 2.6.34-RC2 était à 1700, le 2.6.36-RC2 était juste à 237... et le 2.6.32-RC2 était exactement semblable au RC1 parce que j'avais merdé avec le tagging ;)) et en taille du diff. En fait, si on regarde les stats, le diff semble même un peu plus petit que la normale... Ce qui est bon signe.
Donc j'espère que ce cycle 2.6.37 sera aussi indolore qu'il en a l'air jusqu'à présent. Ou bien ça veut juste dire que les gens ne sont pas très actifs après le sommet du noyau. Donc allez-y et testez ! ».

RC-3

Le 21 novembre, c'est la RC-3 qui a été annoncée :

« Nouvelle semaine, nouvelle RC.
Je dois dire que jusqu'à présent j'ai été vraiment content du calme de ce cycle. Bien sûr peut-être que les gens font simplement profil bas, se préparant à me submerger la semaine prochaine avec un flot de patchs pendant que je serai au Japon, juste pour être désagréables. Parce que les développeurs du noyau sont comme ça.
Mais bon je vais croiser les doigts et espérer que cela veut juste dire que cette version est particulièrement calme. Quand on regarde les diffs il y a à peu près 75% des changements qui concernent les pilotes et à peu près la moitié de ça dans des mises à jour DRM ».

RC-4

Linus semble être un bon analyste des pulsions sociopathes des développeurs du noyau puisque, comme il l'avait annoncé, le nombre de patchs proposé a fortement augmenté pendant son voyage au Japon. C'est ce qu'il explique dans le message accompagnant la RC4 :

« Comme je l'avais suspecté, le fait que je passe presque toute la semaine au Japon a provoqué chez certains développeurs du noyau l'émission de cris jubilatoires sur le mode "envoyons-donc ces patchs à Linus quand il sera bien abruti par le décalage horaire pour voir si on peut le désorienter encore plus que d'habitude". Le résultat c'est que la RC4 est environ deux fois plus grosse que la RC3.
Pourquoi est-ce que je ne suis même pas surpris ?
Ceci dit cela reste assez réduit par rapport aux standards habituels. Dans la série des 2.6.3x, seul le 2.6.31 a eu moins de commits à ce stade (286 contre 393). Donc les choses ont été raisonnablement calmes.
En termes uniquement de lignes les changements les plus notables concernent l'architecture Tile et le pilote SiS fbcon (avec 40% et 10% respectivement). Le reste c'est juste du bruit blanc un peu partout (la moitié dans les pilotes et la moitié ailleurs).
Alors testez bien et signalez toutes les régressions que vous voyez ».

RC-5

Lors de la sortie de la RC-5 Linus a tenu à signaler que le code Direct Rendering Manager était à garder sous surveillance :

« Le code DRM (que ce soit Radeon ou Intel) continue de recevoir plus de patchs que ce que j'aimerais voir à ce stade du cycle. Plusieurs des régressions qui sont signalées concernent également ce domaine donc nous ne sommes pas encore au point de ce côté.
A part ça le reste semble tout à fait calme ».

RC-6

Le 15 décembre Linus a annoncé la version candidate RC6, un peu retardée par le fait qu'il n'avait plus son laptop avec lui (sa fille le lui avait emprunté pour l'école). Il a également annoncé son planning pour la sortie de la version définitive du noyau 2.6.37:

« Cela fait un peu plus d'une semaine depuis la -RC5 et maintenant la -RC6 est disponible. Tout a été un peu différé parce que je voyageais sans mon portable et, bien que j'ai pu suivre la situation en lisant mes e-mails sur mon téléphone, je n'ai pas fait le moindre pull la semaine dernière.
Le diff n'est pas tout à fait aussi vide que ce que j'espérais voir à ce stade mais, comme je l'ai mentionné à plusieurs personnes, je n'ouvrirai pas la période de merge pendant les vacances donc nous avons encore quelques semaines devant nous. En particulier nous avons encore à bosser sur la régression concernant l'allocation des ressources PCI.
Merci de continuer à tester et pensez bien à pinguer bugzilla (ou les développeurs) à propos des régressions que vous trouvez, qu'elles soient nouvelles ou anciennes ».

RC-7

La septième version candidate du noyau Linux 2.6.37 est apparue sur les serveurs kernel.org le 21 décembre dernier :

« Rien d'extraordinaire là-dedans. Quelques mises à jour V4L pour corriger des erreurs concernant le retrait du BKL et quelques régressions. Un patch assez gros pour corriger le problème de "charge processeur trop importante" dans le cas NOHZ.
Je suis toujours un peu nerveux au sujet des rapports de régressions pour le pilote graphique Intel, donc merci de continuer à tester et à rapporter les bugs. C'est la dernière -RC avant Noël (ou quelles que soient vos vacances) donc maintenant vous avez tous plusieurs jours de libre et vous n'avez rien de mieux à faire que tester une -RC, n'est-ce pas ? ».

RC-8

Enfin, juste avant le réveillon, Linus a décidé de sortir une ultime version de test du noyau :

« Ce devrait être la dernière de la série 37 et je m'attends à ce que la période de merge s'ouvre début janvier quand les gens seront revenus au travail après avoir trop mangé (et trop bu). Cette RC8 n'est pas très excitante, le changement le plus notable c'est probablement la correction du problème d'écran blanc avec les cartes graphiques Intel. Mais à part ça c'est juste une collection de petites corrections un peu partout.
Alors déchaînez-vous et fêtez la nouvelle année avec un nouveau noyau ».

Les nouveautés (↑)

Améliorations d'Ext4

Dans ce nouveau noyau 2.6.37 le système de fichiers Ext4 a reçu deux patchs importants afin d'améliorer ses performances.
Le premier patch, nommé "lazy inode table initialization", concerne la phase de création du système de fichiers.
Quand le programme mke2fs est lancé pour créer le système de fichiers Ext4, une des actions entreprises est d'effacer la table des inodes c'est-à-dire la table qui stocke les métadonnées des fichiers (leur taille, leur propriétaire, etc). Normalement mke2fs remet à zéro tous les inodes lors d'une création de nouveau système de fichiers mais, après analyse, les développeurs se sont aperçus qu'il n'était pas critique que cette phase de remise à zéro s'effectue dès la création du système de fichiers. On peut très bien remettre ça à plus tard. L'option "lazy_itable_init" est donc maintenant disponible et c'est elle qui permet d'accélérer la phase de formatage/création d'un système de fichiers Ext4.

Vous aurez toutefois noté que le nom du patch n'est pas "without initialization" mais bien "lazy initialisation", donc on peut se douter qu'il faudra quand même à un moment remettre à zéro la table des inodes. Cette phase de nettoyage est effectuée par un thread noyau nommé "ext4lazyinit" qui est lancé lors du premier montage du nouveau système de fichiers. Ce thread s'occupe de remettre tranquillement à zéro la table des inodes sans interférer avec le travail en cours et sans occuper la précieuse bande passante des entrées/sorties. On peut moduler le temps passé à faire ce travail avec le paramètre init_itable. Par défaut il est à 10 ce qui signifie qu'on accorde au thread noyau 10 fois le temps qui est normalement nécessaire pour mettre à zéro un groupe dans la table des inodes. Cette allocation de temps généreuse permet au thread de faire son travail sans impacter les performances.
Cette nouvelle fonction sera sans doute utilisée dans les CD d'installation des distributions, puisque cela permet de gagner du temps à la création du système de fichiers et donc de proposer un système fonctionnel plus rapidement.

L'autre patch améliorant les performances d'Ext4 dans le noyau 2.6.37 est un peu plus ésotérique, mais il promet un véritable bond dans les performances.
L'idée derrière le patch "direct bio layer" est de ne plus passer par une couche intermédiaire de cache quand on doit envoyer des données vers le périphérique mais d'utiliser directement la couche en mode bloc du noyau. Habituellement les données passent par le "buffer layer" qui est une couche entre le page cache et le périphérique en mode bloc. Ce "buffer layer" sert aussi à stocker diverses métadonnées comme les verrous, la valeur de "dirtyness", etc. Le problème c'est que les données qui passent par le "buffer layer" sont envoyées par petits paquets de 4 Ko, ce qui est un goulet d'étranglement.
Avec le nouveau patch il est possible d'envoyer plusieurs mégaoctets à la fois si les données sont disponibles. En plus les tests ont montré que la couche de "buffer layer" limitait la montée en puissance car elle utilise de nombreux verrous. L'utilisation directe de la couche I/O permet donc de mieux profiter des machines ayant de très nombreux cœurs de calcul. Au final, maintenant que le noyau 2.6.37 permet aux entrées/sorties (buffered I/O) venant d'un système de fichiers Ext4 d'utiliser directement la couche en mode bloc, les performances et la capacité de gérer la montée en charge sont bien plus importantes.
Évidemment quand on cherche à ne plus passer par le "buffer layer" on doit réimplémenter dans le code du système de fichiers les fonctions qui étaient offertes dans cette couche. C'est donc plus long et plus difficile... Mais les bénéfices sont conséquents !

Des tests ont été menés sur une machine puissante pour comparer les résultats avant et après le patch. Sur un ordinateur ayant 48 cœurs AMD-64 et un RAID de 24 disques, Eric Whitney a mis en évidence une multiplication par trois des performances dans le cas de la création de gros fichiers (on passe de 40 000 transactions/s à plus de 120 000 transactions par seconde).
Quand Ted Ts'o, leader du développement d'Ext4, a annoncé triomphalement ces résultats sur son blog, certains commentateurs ont fait remarquer que ces chiffres ne faisaient que rejoindre le score du système XFS. Ted a répondu en signalant qu'XFS avait toujours été développé en tant que système spécialisé pour des machines à hautes performances et qu'il était bien moins efficace dans des configurations plus normales. Le patch d'Ext4 permet ainsi à ce système de fichiers standard sous Linux de couvrir tout le spectre des tâches et de devenir bien plus universel.

Avec les deux patchs "lazy initialization" et "direct bio layer", le système de fichiers Ext4 renforce donc son attractivité comme système de référence sous GNU/Linux. On le trouve maintenant aussi sous Android puisque la version 2.3 (Gingerbread) a effectuée une transition de YAFFS (qui était utilisé sur les versions précédentes) vers Ext4. Dans l'attente du mûrissement de Btrfs le système de fichiers Ext4 reste un très bon cru !

FITRIM

Le nouvel appel système FITRIM a été ajouté au noyau Linux 2.6.37.
La commande TRIM, aussi nommée "discard", a été intégrée au noyau Linux dès la version 2.6.30 au sein de la couche SATA et complétée dans le noyau 2.6.33. Cette commande est très importante pour les disques de stockage de type SSD (à base de mémoire flash), car elle permet au système d'exploitation d'indiquer au disque quels sont les blocs de données qui peuvent être effacés.

Cette commande TRIM a été introduite car la technologie des mémoires flash connaît une très importante limitation qu'il est nécessaire de contourner. Il est en effet impossible d'effacer les pages mémoires d'une mémoire flash (4 Ko) et seuls les blocs sont effaçables (128 Ko ou 512 Ko). Évidement la funeste conséquence de cette limitation c'est qu'il arrive, quand on doit écrire des données et qu'il ne reste pas assez de pages libres, qu'on doive placer dans la mémoire cache tout le bloc pour ensuite réécrire ces données ailleurs sur le disque. Cette gymnastique absurde est très bien expliquée, avec des schémas, sur cette page du site Anandtech.
Ce cycle de réécriture ralentit les accès à un moment particulièrement inopportun puisqu'il intervient juste au moment où le système d'exploitation écrit des données sur le disque. La commande TRIM a été conçue pour tenter de réduire cet impact sur les performances. L'idée est simplement d'informer le disque quand une page a été effacée par le système. Comme le disque possède cette information il peut lancer tout de suite la nouvelle écriture du bloc de données qui ne contient plus la page effacée. Ainsi, lors d'une écriture ultérieure, le bloc sera prêt à accueillir les données, puisque toutes les pages inutiles auront été précédemment effacées.

Toutefois la commande TRIM, souvent présentée comme miraculeuse par les fabricants de disques, ne va pas sans quelques problèmes.
Tout d'abord le cycle de réécriture (chargement en cache puis écriture du nouveau bloc) intervient toujours à un moment non optimal. Certes c'est mieux d'effectuer le cycle lors de l'effacement d'une donnée que lors de son écriture mais cela impacte tout de même les performances et il serait souhaitable d'optimiser ce comportement. Ensuite la fonction TRIM, en écrivant des données lors de chaque effacement, risque de consommer le potentiel d'écriture limité des cellules flash. Enfin le comité de normalisation de l'International Committee for Information Technology Standards a défini la fonction TRIM des disques SATA comme étant de type "non-queued". Cela signifie malheureusement que toutes les opérations d'entrée/sortie sont bloquées quand une commande TRIM est exécutée sur la machine.
Comment réduire ces inconvénients tout en gardant les avantages de TRIM ?

C'est ici qu'entre en scène le tout nouvel appel système FITRIM qui a été incorporée dans le noyau 2.6.37. L'idée est de ne plus faire du TRIM à la volée (on-the-fly TRIM) chaque fois que des données sont effacées. On va plutôt permettre au système de fichiers d'informer d'un seul coup le disque sur toutes les pages effacées. Au lieu de travailler en direct (online discard) on travaille en mode batch (batch discard). On peut ainsi lancer la fonction FITRIM quand le disque n'est pas sollicité ou quand on fait une vérification du système de fichiers (fsck) lors du démarrage.
Cette fonction FITRIM (techniquement c'est un ioctl c'est-à-dire une commande d'entrée/sortie) est utilisable sur un système de fichier entier ou seulement sur des parties de celui-ci. La syntaxe d'utilisation de la fonction est décrite dans ce message sur la liste de diffusion linux-ext4 et il faut utiliser le programme fstrim qui a été intégré récemment à la suite util-Linux.
Actuellement l'appel FITRIM est désactivé par défaut et seul le système de fichiers Ext4 peut utiliser cet ioctl, mais le code a été conçu pour être utilisable par tous les autres systèmes de fichiers.

Allocateur mémoire memblock

Vous n'êtes pas sans savoir que le mécanisme d'allocation mémoire du noyau Linux utilise un algorithme de type "buddy allocation" pour les pages mémoire et un autre de type "slab allocation" pour les objets qui se situent à un niveau "plus haut" que les pages mémoire (les ensembles de pages). Ce que vous ne savez peut-être pas c'est que ces deux techniques sont très efficaces mais qu'elles nécessitent un noyau déjà lancé. Comment faire lors de l'amorçage quand il faut allouer de la mémoire pour le démarrage du noyau lui-même ? Il faut bien amorcer le système ("bootstrapper" en bon franglais) pour qu'il puisse lancer l'allocateur de type Buddy et l'allocateur de type Slab.

L'astuce utilisée ressemble un peu à ce qui est mis en place au CERN pour alimenter le LHC (Large Hadron Collider). Avant d'entrer dans le tunnel géant de 27 kilomètres de circonférence, les protons sont accélérés dans des machines plus petites et transférés "en cascade" d'un accélérateur à l'autre (le Linac2 puis le Proton Synchrotron Booster puis le Proton Synchrotron et enfin le Super Proton Synchrotron).
Le noyau Linux fait la même chose puisqu'il enchaîne plusieurs techniques successives, de plus en plus sophistiquées, afin de parvenir à lancer nos amis buddy et slab. Au tout début il y a simplement le désespérément fruste brk() qui permet juste de manipuler la taille du segment de données, mais on enchaîne ensuite sur le mécanisme BIOS e820, puis sur le mécanisme early_res suivi de l'allocateur bootmem qui, enfin, donne la main aux "vrais" allocateurs que nous connaissons. Évidemment, tous ces "injecteurs" successifs sont de bas niveau et le mécanisme décrit est donc spécifique à l'architecture processeur x86/x86-64 :
brk → e820 → early_res → bootmem → buddy/slab

Lors du cycle du noyau 2.6.34, le développeur Yinghai Lu avait posté plusieurs patchs pour simplifier cette série emboitée d'allocateurs en modifiant "early_res" pour qu'il puisse jouer le rôle de "bootmem". Une option de configuration NO_BOOTMEM, activée par défaut, était donc devenue disponible pour signifier la désactivation de cet allocateur :
brk -> e820 -> early_res -> buddy/slab

Comme il fallait s'y attendre avec ces parties obscures et sensibles du code du noyau, de nombreux problèmes étaient apparus et Linus avait même dû menacer, comme il sait si bien le faire, de jeter les patchs à la poubelle pour qu'enfin les choses se stabilisent et que ce changement trouve son chemin vers le noyau 2.6.34 définitif.

Après cette première saga, Yinghai Lu a continué son travail de simplification et, aidé par Ben Herrenschmidt, il fait entrer maintenant dans le noyau le mécanisme memblock pour remplacer "early_res". Memblock est un allocateur plus générique que ne l'était "early_res" puisqu'il est utilisé, sous le nom LMB (Logical Memory Block), sur les architectures Microblaze, PowerPC, SuperH et SPARC. C'est cette "généricité" qui a conduit son adoption dans l'espoir que plus de code commun allait signifier plus de développeurs travaillant sur le code partagé. Ingo Molnar s'est opposé à ce choix en signalant que l'architecture x86/x86-64 représentait 95% des machines et que les 4 architectures utilisant "Logical Memory Block" ne pesaient pas lourd en termes de déploiement. Ben Herrenschmidt n'a pas été impressionné par cet argument du nombre et, comme souvent sur la LKML, le débat est resté fort urbain et remarquablement courtois puisqu'il a répondu ceci à Ingo :

"Si tu utilises cet argument ENCORE UNE PUTAIN DE FOIS tu vas finir dans mon killfile avec une réponse automatique pour refuser systématiquement tout ce qui ressemble à un patch venant de toi".

S'en sont suivis quelques échanges sur le même ton que je paraphrase :
-> "De toute façon t'es qu'un menteur et tes chiffres sont truquées puisque ARM ça représente des tonnes de machines".
-> "Ce qui compte ce sont les patchs et les développeurs ARM ne m'en envoient jamais. Alors moi je m'en fous que leurs machines soient nombreuses".
-> "Pfff, ton exemple il est tout pourri puisque tu travailles sur l'ordonnanceur et que les développeurs ARM, avec leurs processeurs lents et in-order, s'en fichent complètement de ton code".

Après ces joyeuses et primesautières interpellations (il faut avoir le cuir épais pour travailler sur le noyau Linux), les choses sont progressivement rentrées dans l'ordre. Ben Herrenschmidt a retrouvé son calme et Ingo Molnar a admis que le code memblock était plus propre que celui de "early_res". Le travail de Ben a consisté à partir des patchs initiaux de Yinghai pour améliorer et nettoyer encore plus memblock afin de pouvoir le porter sur l'architecture x86.

Dans le noyau 2.6.37 l'architecture x86 abandonne donc "early_res" au profit de memblock et supprime même le vieux code "bootmem" qui était gardé comme option non utilisée depuis le 2.6.34. Le message récapitulatif de Peter Hanvin sur la liste de diffusion indique bien que ce changement est délicat (77 patchs !) puisqu'il modifie fondamentalement la façon dont se déroule le mécanisme initial d'allocation mémoire sur l'architecture x86/x86-64.

On peut penser que c'est se donner bien de la peine pour un mécanisme qui n'est utilisé que brièvement lors du démarrage de la machine mais, fort heureusement, les développeurs de Linux sont des perfectionnistes et un tel changement ne leur fait pas peur. C'est l'avantage d'un mode de développement où le "rang" des développeurs se détermine en fonction de leurs contributions techniques et où leur "gratification" consiste à démontrer à leurs pairs qu'ils sont capables d'écrire du code de grande qualité.
Il est fort probable qu'un éditeur de système d'exploitation à code source fermé n'aurait pas vu d'intérêt économique à se lancer dans un tel changement intrusif pour des bénéfices qui sont, il faut le reconnaître, peu en rapport avec la difficulté de développement.

Les avantages de cette substitution de "early_res" par "memblock" existent tout de même et sont de deux ordres. Tout d'abord la politique d'allocation par défaut passe d'une approche "bottom-up" (du bas de la pile vers le haut) à une approche de type "top-down" (du haut de la pile vers le bas) ce qui préserve mieux la mémoire en limitant la fragmentation. En plus cette politique par défaut facilite la découverte des bugs donc c'est tout bénéfice.
Ensuite, et comme évoqué plus haut, le code de memblock est maintenant utilisé sur la majorité des architectures. C'est plus propre et cela va sans doute permettre une meilleure maintenance à long terme puisque le nombre des développeurs susceptibles d'utiliser memblock est plus grand. C'est ce souci de penser au futur et de privilégier le caractère générique du code qui est la grande force de Linux. Memblock en est un nouvel exemple éclatant.

Contrôleur IO-block et limiteur de débit

Après l'intégration du contrôleur IO-block dans le noyau 2.6.33, c'est maintenant le limiteur de débit (bandwidth controller) qui entre dans le nouveau noyau Linux.
Vivek Goyal, dont la solution io-controller avait été choisie au détriment de ses concurrents dm-ioband et io-throttle, a continué son travail d'intégration des divers patchs. Pour rappel cette fonction permet de faire un arbitrage entre les divers groupes de processus afin d'accéder aux précieuses ressources d'entrées/sorties. Grâce à ce contrôleur I/O l'administrateur de la machine peut fixer des limites en termes de débit sur les entrées/sorties et ainsi éliminer le risque qu'un groupe de processus ne monopolise le disque dur par rapport aux autres groupes.

En termes d'architecture le contrôleur utilise la technique des Control groups (cgroups) qui permet d'isoler les diverses ressources de la machine (processeur, entrées/sorties, mémoire, etc). À noter que les cgroups commencent à remporter un franc succès au sein de Linux puisque divers mécanismes s'appuient sur lui. Nos distributions devraient ainsi accueillir en 2011 le démon systemd qui est un remplaçant du vénérable sysvinit et qui repose entièrement sur les cgroups.

Un autre avantage du code de Vivek est qu'il n'est pas très invasif. C'est cette empreinte relativement réduite qui lui a sans doute permis de remporter la mise par rapport aux solutions concurrentes dm-ioband et io-throttle qui ajoutaient des crochets (hooks) un peu partout dans le noyau. La solution de Vivek a été jugée plus propre et plus simple que les autres... et en plus elle fonctionne avec tous les ordonnanceurs d'entrées/sorties du noyau Linux.
Il faut savoir que le contrôle du débit des I/O a absolument besoin d'un mécanisme d'ordonnancement hiérarchique afin de ne pas biaiser les décisions prises par l'ordonnanceur classique des entrées/sorties. Avec ce mécanisme hiérarchique on a un premier niveau pour l'ordonnancement classique (qui vise les performances) et un second niveau pour les limites de débits.
Comme seul l'ordonnanceur CFQ (Completely Fair Queuing) était doté de ce mécanisme hiérarchique Vivek a donc décidé de prendre cette partie du code de CFQ et de l'extraire pour en faire un mécanisme générique applicable aux autres ordonnanceurs (Deadline, Anticipatory, et no-op). Comme ça on réduit la taille de CFQ sans avoir à dupliquer ce bout de code dans les autres ordonnanceurs.

Les patchs intégrés dans le noyau 2.6.37 permettent, en plus du contrôle des "poids" respectifs des groupes qui était déjà possible avec le mode "Proportional Weight division of bandwidth", d'indiquer maintenant un débit précis au noyau avec le nouveau mode "Throttling/Upper Limit policy".
Pour indiquer son choix de débit (throttling policy) l'administrateur doit bien entendu avoir un noyau compilé avec les options CONFIG_BLK_CGROUP et CONFIG_BLK_DEV_THROTTLING. Le périphérique se désigne par ses nombres majeur/mineur et le débit s'exprime en octets par seconde.
Première étape on monte le contrôleur des entrées/sorties :
mount -t cgroup -o blkio none /cgroup/blkio
Ensuite on indique que le périphérique /dev/sda (8:0) doit avoir un débit de 1 Mo/s en lecture :
echo "8:0 1048576" > /cgroup/blkio.read_bps_device
Maintenant, chaque fois que le groupe voudra lire ce périphérique, le débit sera limité à 1 Mo/s. Encore un outil diabolique dans la besace du BOFH !
Si on veut exprimer une limite en termes de nombre d'entrées/sorties et non plus en octets alors il suffira d'écrire dans blkio.read_iops_device au lieu de blkio.read_bps_device.
La documentation complète est disponible et l'e-mail de Vivek Goyal, où il annonce la version 10 du patch, contient également beaucoup de renseignements sur ce limiteur de débit des entrées/sorties.

Barrières et systèmes de fichiers

Le code des barrières qui était présent dans la couche en mode bloc a été complètement retiré. Ce sont maintenant les systèmes de fichiers qui, dans le noyau 2.6.37, s'occupent directement de spécifier l'ordre des écritures. C'est une des grandes décisions qui ont été prises lors du sommet "Linux Storage and Filesystem" s'étant déroulé les 8 et 9 août dernier à Boston. Après des années d'insatisfaction, le code des barrières a été jugé non nécessaire et les développeurs du noyau se sont lancés dans son remplacement intégral.

Le but de ces fameuses "barrières" est assez facile à comprendre puisqu'on sent bien intuitivement qu'il y a de nombreux cas où l'ordre d'écriture des données sur le disque est crucial. Par exemple si je veux enregistrer ce texte que je suis en train de rédiger en ce moment dans Gedit je me contente bêtement de faire Ctrl-s. Le système, infiniment plus malin que moi, va alors décomposer l'enregistrement en quatre phases (en mode data=journal qui est plus simple conceptuellement) :

1) Début de transaction.
2) Enregistrement des métadonnées et données dans le journal du système de fichiers Ext4 que j'utilise.
3) Fin de transaction.
4) Enregistrement des métadonnées et données sur le système de fichiers proprement dit.

Le point crucial de cette séquence est le troisième, le bit de commit qui certifie que tout a bien été écrit dans le journal. Si un problème arrive après cette étape trois, par exemple un plantage système, alors le journal me permettra de "rejouer" complètement la séquence et je suis sauvé. Si un problème arrive avant cette étape trois alors, certes je vais perdre ce que j'aurai enregistré sur le journal, mais au moins mon système de fichiers ne sera pas corrompu par le plantage.

L'ennui avec cette belle idée c'est qu'il y a beaucoup d'intervenants qui sont ravis, pour des raisons de performances, de réordonner à leur guise l'ordre des opérations d'écriture. On peut citer la couche en mode bloc qui tente de minimiser les déplacements de la tête de lecture du disque dur et, ce faisant, regroupe les données à écrire. On peut aussi citer l'ordonnanceur des entrées/sorties du noyau ou même le disque dur qui contient de la mémoire cache afin de n'écrire les données que par gros batchs.
Toutes ces couches se moquent de l'ordre des écritures et ce mélange peut entraîner des conséquences fort déplaisantes (saccage du système de fichiers) si on ne réintroduit pas un peu de rigueur. C'est le rôle dévolu à ces fameuses "barrières" qui avaient été implémentées dans la couche en mode bloc.
On peut ainsi définir une barrière après l'étape trois de la séquence d'enregistrement. Le système devra alors traiter toutes les opérations se situant avant la barrière et n'aura pas le droit de toucher autre chose tant que ce travail ne sera pas terminé. Une fois tout traité, et seulement à ce moment là, il pourra se consacrer aux requêtes se situant après la barrière.

Bien entendu la contrainte introduite par la barrière réduit fortement les performances et les développeurs cherchent depuis longtemps comment faire pour supprimer ce goulet d'étranglement. On peut évidemment passer en mode "nobarrier" pour améliorer les performances mais c'est introduire un risque de corruption qu'il faut soigneusement évaluer avant de se lancer. Ce que les utilisateurs veulent vraiment c'est, comme d'habitude, les performances du mode "nobarrier" avec les garanties du mode "barrier". Exigeants ces utilisateurs !

Christoph Hellwig a planté le décor dans un message sur la LKML et une monstro-discussion a suivi pour évaluer toutes les options disponibles. La solution sur laquelle les développeurs Linux se sont mis d'accord lors du sommet de Boston consiste à supprimer le code des barrières qui était dans la couche en mode bloc, donc sous-jacente aux systèmes de fichiers. La fonction, sous une forme un peu différente, a été "remontée" dans chacun des systèmes de fichiers au dessus de la couche bloc.
L'idée derrière cette stratégie est de profiter de la connaissance fine sur les données qui est présente dans ces systèmes de fichiers pour prendre de meilleures décisions. La couche en mode bloc est trop "basse" et l'implémentation des barrières trop restrictive alors que dans bien des cas on pourrait se contenter de garanties plus faibles sur la majorité des opérations. Seules les opérations critiques, que les systèmes de fichiers savent identifier, nécessitent vraiment un ordre strict.

C'est Tejun Heo qui a envoyé l'ensemble des patchs sur la liste de diffusion pour passage en revue, relecture attentive et tests divers.
Le premier patch de Tejun élimine donc les barrières de la couche bloc et tous les appels à REQ_HARDBARRIER provoqueront dorénavant une erreur de type EOPNOTSUPP (Operation Not Supported).
Au lieu de la technique des barrières les systèmes de fichiers vont maintenant envoyer directement des "flush requests" pour ordonner au cache du périphérique de se vider (c'est l'ordre REQ_FLUSH) et d'enregistrer réellement les données sur le disque (c'est l'ordre REQ_FUA pour "Force Unit Access"). Ce patch de conversion permet ainsi aux systèmes de fichiers de décider quelles transactions nécessitent réellement une protection via REQ_FLUSH/REQ_FUA et lesquelles peuvent se dérouler à pleine vitesse sans cette machinerie. La documentation writeback_cache_control.txt a été mise à jour pour expliquer la nouvelle règle du jeu.
Au final le débit moyen va augmenter sensiblement puisque seules les transactions vraiment critiques seront ralenties par la protection du mécanisme des ""flush requests"". Le résultat des tests de Hannes Reinecke est encourageant puisqu'il obtient un débit de 115,2 Mo/s après le patch contre seulement 82,7 Mo/s avant.

Jump label

Le mécanisme de "jump label" a intégré le noyau 2.6.37. Il va permettre de réduire à pratiquement zéro le coût des points de traçage non activés.
Depuis plusieurs années, suite à la concurrence de l'aiguillon DTrace, une vaste campagne d'amélioration des outils de tracing du noyau Linux a été entreprise. Le représentant emblématique en est l'infrastructure des "performance counters" et son outil perf associé, mais il y a bien d'autres exemples dans ce domaine.
Ces outils reposent sur des points de traçage (tracing points) qui sont disséminés dans le code du noyau et qui permettent de faire remonter les données vers les compteurs globaux. Le noyau 2.6.37 contient d'ailleurs une tripotée de nouveaux tracing points dans la couche réseau, le code des workqueues, l'insfrastructure de gestion de la mémoire, etc. Chacun de ces points de traçage est plus ou moins écrit de la même façon avec au début un petit test pour vérifier que le tracing est bien activé dans le noyau et ensuite le code effectuant le vrai travail.
En pseudo-code cela ressemble à quelque chose comme ça :
si (unlikely(point_de_tracing_activé))
alors vrai_travail_de_tracing;
sinon ne_rien_faire
De cette façon les noyaux normaux qui n'activent pas le tracing, et qui sont l'immense majorité, ne patissent pas du coût des opérations... à l'exception du petit test initial !
Évidemment un seul test ne représente presque rien en termes de ressources mais le nombre de points de tracing dans le noyau ne fait que croître et les coûts s'additionnent. Chaque fois qu'un test conditionnel est effectué pour savoir si le point de traçage est ou n'est pas activé, cela signifie qu'il faut aller récupérer une valeur en mémoire et cela accroît la pression sur le cache. On a beau essayer de réduire l'impact du test conditionnel en le faisant précéder de la macro unlikely() pour indiquer au compilateur que cette branche est très rarement prise, cela ne suffit pas. Quand on a plusieurs centaines ou plusieurs milliers de points de traçage la surcharge (overhead) n'est plus du tout négligeable.

C'est quand même ennuyeux de faire ainsi payer à tous les utilisateurs une fonction qui n'est même pas activée ni utilisée dans leur noyau. Même pour les rares personnes qui ont un noyau avec le tracing activé il est fort probable qu'elles vont se concentrer sur certains points de traçage et que tous les autres points seront désactivés. Réduire l'impact de ces points dormants est donc fort tentant et c'est ici qu'intervient la nouvelle technique de "jump label".
L'idée est fort astucieuse puisqu'il s'agit d'utiliser une macro JUMP_LABEL qui identifie l'emplacement du point de traçage avec une clé dans une table et qui insère une opération de type nop (no operation). Ainsi quand le point n'est pas activé le coût est presque nul (une instruction nop suivie d'un jump pour ne pas utiliser le code de tracing). Si l'administrateur de la machine veut activer ce point de tracing il va utiliser la fonction enable_jump_label() sur la clé se trouvant dans la table et servant à identifier le point de traçage. La macro JUMP_LABEL va alors remplacer l'opération nop par un goto en assembleur qui pointe vers le code du travail de tracing à affectuer lui aussi contenu dans la jump_table.

On voit donc que le coût de chaque point de traçage est réduit à sa plus simple expression et que le prix à payer est déplacé au moment du build initial du noyau (pour la construction de la jump_table) ou au moment de l'activation/désactivation des points (pour le remplacement du nop par le goto). Patcher son noyau en temps réel est assez inhabituel mais dans ce cas c'est une bonne solution !

Cette solution est optimale (meilleure que DTrace) mais, comme elle fait intervenir du code en assembleur, elle nécessite l'écriture de lignes de code différentes pour chaque architecture. Pour le moment seules les machines de type x86, x86_64, SPARC et MIPS sont compatibles avec cette solution. Il a fallu également faire accepter aux développeurs de GCC le patch permettant le goto en assembleur à partir d'un label en C.
Jason Baron a testé le nouveau mécanisme de "jump label" sur un Core 2 Quad en utilisant la fonction get_cycles() placée judicieusement autour de divers points de traçage non activés. Le premier test se fait en idle (c'est-à-dire avec une machine inoccupée).
Avant le patch : 32 cycles
Après le patch : 2 cycles

Le second test s'effectue après avoir lancé le test tbench pour générer de l'activité sur la machine.
Avant le patch : 88 cycles
Après le patch : 4 cycles

Certes le travail n'est pas encore fini et l'interface des "jump_label" sera peut-être modifiée dans la prochaine version 2.6.38. En dépit de ce caractère expérimental on voit bien que ce nouveau mécanisme permet d'ores et déjà de réduire drastiquement le prix que nous payons tous pour la présence dans nos noyaux d'une multitude de points de tracing.

La fin du BKL

Comme annoncé dans la dernière dépêche le travail d'élimination du verrou global du noyau (BKL) a continué sur un rythme soutenu afin de compléter son éradication. La grande nouvelle du noyau 2.6.37 c'est qu'il est maintenant possible de compiler un noyau fonctionnel sans verrou global.

Le Big Kernel Lock a été introduit dans le noyau Linux en version 2.0 qui est sorti le 9 juin 1996. À cette époque cette technique avait été sélectionnée comme étant la plus simple pour permettre la gestion des machines SMP (plusieurs processeurs en parallèle). L'avantage de ce verrou global du noyau c'est qu'il est très facile à mettre en place et que la menace d'introduire des bugs est assez faible. Ainsi, chaque fois qu'un processus à besoin d'accéder à l'espace mémoire du noyau, il suffit de faire simplement un appel à la fonction lock_kernel() et tous les risques de conflits avec un autre processus sont évités. L'autre thread va simplement attendre gentiment que le verrou soit levé pour faire son travail.

Évidemment cette simplicité se paye puisque les performances décroissent au fur et à mesure que le nombre de processeurs des machines augmente. Le BKL est une bonne solution pour les bi-CPU mais au delà c'est vraiment du gâchis de ressource de mettre ainsi en attente tous les cœurs de calcul pendant qu'un seul d'entre eux exécute un processus en espace noyau.
C'est pour cette raison que la technique du "verrouillage à grains fins" (fine-grained locking) a, au fil du temps, remplacé progressivement le BKL dans toutes les parties critiques du noyau Linux. Ce verrouillage à grains fins évite de poser un verrou global sur l'intégralité du noyau et se contente de poser un lock sur la partie précise dont a besoin le processus. Avec cette solution les situations de compétition entre les processus sont bien plus rares puisque chacun verrouille exactement ce dont il a besoin et ne cherche pas à s'accaparer le noyau pour lui tout seul.

Le désavantage regrettable du verrouillage à grains fins c'est qu'il s'agit d'une technique délicate. Il est facile d'introduire des bugs et les développeurs n'ont fait l'effort de transformer le code du noyau que lorsque cela en valait vraiment la peine pour augmenter les performances.
Quand Ingo Molnar a annoncé en mai 2008 son projet "Kill the BKL" il restait donc encore plus de 1300 appels à la fonction lock_kernel() dans le noyau Linux. Au rythme de retrait des appels au BKL Ingo avait calculé qu'il faudrait encore 10 ans pour en être débarassé définitivement !
Les développeurs ont donc retroussé leurs manches et se sont lancés dans l'éradication du verrou global et dans la conversion de toutes les parties du noyau qui l'utilisaient encore.

Après des mois et des mois de travail, Arnd Bergmann a finalement annoncé que le noyau 2.6.37 allait accueillir une option de configuration nommée CONFIG_BKL qui est le symbole de la victoire contre le BKL. Les quelques pilotes et obscurs morceaux de code qui reposent encore sur le verrou géant sont suffisamment peu nombreux et ésotériques pour qu'on puisse maintenant compiler un noyau vraiment fonctionnel sans verrou global. Les derniers traînards auront donc simplement un petit "depends on BKL" dans leur fichier de configuration. La seule partie qui est vraiment utile et qui a encore besoin du BKL c'est le système de fichiers UDF qui est utilisé pour lire et écrire des données sur les DVD enregistrables. Le patch est arrivé en retard mais il sera incorporé dans le prochain noyau.

Alors est-ce qu'il est enfin temps de se réjouir et de chanter "Hosanna au plus haut des cieux, le BKL est mort" ?
Les développeurs du noyau Linux sont plus flegmatiques que ça et un billet d'Andi Kleen se charge de tempérer quelque peu l'enthousiasme des foules en délire.
Pour Andi l'annonce que le 2.6.37 permet de ne plus utiliser le BKL n'est pas une nouvelle tonitruante :

«Est-ce que c'est vraiment important ? Dans les noyaux de type Linux 2.6 très peu de sous-systèmes continuent à dépendre du BKL. Et la plus grande partie de ce code n'est pas critique pour les performances. Les plus gros utilisateurs (en termes de lignes) sont les appels ioctl dans les pilotes. Bien qu'il y en ait beaucoup (la plupart des pilotes ont des ioctl) le nombre de cycles processeur dépensé dans ce code est vraiment minimal. Habituellement les ioctl sont juste utilisés lors de l'initialisation et dans d'autres tâches peu fréquentes. Ces pilotes ne souffrent pas du verrou global.
Je ne veux pas dire que le BKL n'est pas un sujet important. Si vous avez des accès parallèles à un sous-système ou à une fonction protégée par le verrou alors il y aura un goulet d'étranglement. Dans certaines situations, comme pour les noyaux temps réel, cela peut être encore plus pénalisant. Mais je soupçonne que pour la plupart des cas il n'y a plus de problème depuis longtemps parce que le BKL est déjà éliminé des chemins critiques du code.
La suppression complète du BKL n'est pas vraiment un pas de géant en avant pour Linux. C'est plus un geste symbolique... Et moi, je préfère laisser ce genre de trucs aux politiciens et aux prêtres».

Andi Kleen a évidemment raison de souligner que le retrait du BKL relève plus du nettoyage du noyau "pour le principe" que d'un souci de recherche de performances. Néanmoins d'autres développeurs persistent à penser que ces "gestes symboliques" sont importants et qu'ils sont le signe d'une communauté de développement active et en bonne santé.
Neil Brown, grand manitou de la couche RAID du noyau Linux, a ainsi tenu à tempérer les propos d'Andi Kleen :

«Je ne suis pas vraiment d'accord avec Andi. C'est vrai que ce n'est pas une grande avancée en termes techniques (toutefois je crois me souvenir que le retrait du BKL permet de simplifier un peu l'ordonnanceur et ça ne peut pas faire de mal).
Mais la force de Linux ce n'est pas seulement la technologie. Il y a aussi la communauté, l'attitude des développeurs, la perception de la qualité, etc.
En conséquence je pense que les gestes symboliques peuvent être très importants. Ces gestes disent "nous nous préoccupons de la qualité", "nous corrigeons nos erreurs", "nous supprimons les trucs pourris".
Bien entendu il se peut qu'en réalité nous introduisions plus de saletés que nous n'en enlevons (statistiquement c'est probable vu le rythme de développement) mais dans ce cas c'est encore plus important de faire ce geste symbolique comme ça nous avons un exemple concret à montrer pour encourager les autres à améliorer la qualité».

Quelle que soit l'opinion que l'on puisse avoir sur l'importance de la nouvelle option CONFIG_BKL dans le noyau 2.6.37 il est certain qu'elle est le fruit d'un très gros travail de la part de nombreuses personnes. C'est en quelque sorte l'aboutissement du projet "Kill the BKL" d'Ingo Molnar commencé il y a plus de deux ans et demi et qui a su fédérer les bonnes volontés. Qu'il s'agisse d'une vraie avancée technique ou seulement d'un geste symbolisant le dévouement des développeurs du noyau je pense que nous pouvons tous leur dire merci.

En bref (↑)

• L'ordonnanceur des processus CFS a modifié son comportement envers les tâches à haute priorité dans cette nouvelle version du noyau. Maintenant les processus RT resteront présents sur le processeur où ils s'exécutent et le noyau préférera migrer les processus RT concurrents sur d'autres CPU plutôt que de leur donner la main. Le patch de Steven Rostedt explique bien les enjeux et propose les résultats de plusieurs tests qui montrent qu'avec ce changement les situations de compétitions deviennent plus rares. L'exécution des processus RT est donc bien plus régulière, pour le plus grand bénéfice des tâches temps réel.


• Le système de fichiers Btrfs, destiné à devenir le système standard sous Linux dans quelques années, a été amélioré dans le noyau 2.6.37. Le message récapitulatif de Chris Mason liste les principales nouveautés comme par exemple l'option space_cache. Cette dernière permet de stocker dans un inode spécial la liste de tous les blocs libres du système. Ce patch permet donc, si le système est monté avec l'option -o space_cache, d'avoir un système de fichiers plus rapide puisqu'il n'a pas à scanner l'arbre de recherche (btree) pour trouver les blocs libres.
  Un article du site Phoronix a testé cette nouvelle option et a mis en évidence un gain assez notable (même si l'option de compression par zlib reste encore plus efficace).


• En relation avec Btrfs, puisqu'il utilise des parties de son code, le système de fichiers pour clusters Ceph a lui aussi beaucoup évolué. Le code a été complètement restructuré, puisqu'il existe maintenant une bibliothèque de bas niveau nommée libceph. Tout ce qui concerne le réseau, les clusters et les composants des entrées/sorties vit maintenant dans cette bibliothèque alors que le code spécifique du système de fichiers est maintenant découplé ce qui est plus propre et facilite la maintenance. Le pilote RBD (Rados Block Device) a également été incorporé, avec le statut EXPERIMENTAL, pour s'occuper du stripping des périphériques en mode bloc par dessus le dépôt distribué d'objets géré par Ceph. Cela permet toutes sortes d'usages bien sympathiques listés dans ce post de Sage Weil.


• Le système de fichiers réseau NFS a été amélioré par divers patchs. L'un d'entre eux réécrit entièrement le code "idmapper" du client NFS qui est utilisé pour faire la correspondance entre les identifiants numériques et les users ou groupes déclarées sur la machine. Le précédent "idmapper" était single-thread (ce qui empêchait plus d'une requête de s'exécuter au même moment) alors que le nouveau gère les multiples interrogations simultanées.
  Le code de readdir a aussi été revu afin d'accélérer considérablement le listage des répertoires qui contiennent de nombreux fichiers. Selon les tests effectués par Bryan Schumaker on passe de 56,7 secondes pour lister un répertoire ayant 100 000 fichiers à seulement 12,5 secondes avec le patch.


• Le pilote Nouveau qui gère les cartes NVidia permet maintenant de contrôler la consommation (power management) des GPU de type NV40 jusqu'à NV96. Après avoir effectué un long travail de rétro-ingénierie il est devenu possible de changer les réglages de tension et de fréquence.
  Martin Peres a résumé les avancées sur la liste de diffusion de Nouveau et signale que la gestion des ventilateurs n'est pas encore implémentée.
  Outre les habituels patchs d'amélioration des performances de Nouveau, des "crochets" logiciels ont également été inclus dans le code pour permettre un debogage plus facile avec KDB.


• Du côté d'AMD les cartes récentes de type Evergreen, c'est-à-dire les HD5xx0, ont maintenant la possibilité de combiner plusieurs bitmaps lors d'une opération de "rastérisation" (technique blit). Cela permet de mieux utiliser la mémoire vidéo quand de grandes quantités sont disponibles, par exemple sur les cartes professionnelles de la série FirePro qui gèrent jusqu'à 4 Go de VRAM.
  Comme pour Nouveau des hooks permettant le débogage avec KDB ont été ajoutées au code du pilote KMS Radeon.


• Le pilote Intel continue d'intégrer des patchs qui permettront une gestion sans faille du coeur graphique présent dans les processeurs Sandy Bridge. Cette fois c'est le ring buffer qui est concerné, puisque le code de Haihao Xiang introduit dans le noyau 2.6.37 la possibilité d'utiliser ce ring buffer pour les tâches de codage/décodage des flux vidéos.
  Les fonctions gérant la sortie audio automatique via les ports DisplayPort et HDMI sont également incorporées dans le pilote Intel. Enfin, même si l'infâme puce graphique Poulsbo n'est hélas toujours pas gérée par un pilote libre, le noyau 2.6.37 permet au moins de gérer nativement le rétroéclairage de l'écran. Le site H-Online a interrogé un employé de la firme Intel au sujet de Poulsbo et de Linux et la réponse officielle de la firme américaine est qu'ils sont au courant du problème et prévoient de le résoudre dans le futur. C'est certes bien vague mais plutôt encourageant.


• Le module de sécurité SELinux a été complété par deux nouveaux fichiers /sys/selinux/policy et /sys/selinux/status qui améliorent la connaissance de la politique de sécurité qu'ont les applications en espace utilisateur. Le fichier "policy" permet simplement à une application de lire la configuration SELinux qui est actuellement chargée dans le noyau. Le fichier "status" est plus intéressant puisqu'il permet de notifier d'un changement de politique de sécurité. Auparavant les applications en espace utilisateur devaient lancer un appel système pour consulter le noyau lors de chacun des accès pour savoir si l'Access Vector Cache (AVC) était toujours valable ou si une mise à jour avait eu lieu. C'est très pénible de devoir ainsi interroger le noyau à chaque fois alors qu'en réalité la politique de sécurité ne change presque jamais. À partir du noyau 2.6.37 il suffira d'utiliser mmap sur le fichier /sys/selinux/status dans l'espace mémoire de l'application qui n'aura plus à interroger le noyau systématiquement. C'est uniquement si le fichier "status" a changé que l'Access Vector Cache sera mis à jour.


• L'outil de traçage du noyau perf a reçu plusieurs améliorations lors de ce cycle. Une option -V (--vars) permet par exemple de lister toutes les variables locales sur un point de traçage. En ce qui concerne le tracing dynamique (perf-probe) il devient maintenant possible d'investiguer dans les modules grâce au patch de Masami Hiramatsu. L'option "--module " injecte des points de traçage dynamiques dans le module MODNAME à la condition que le module en question soit en cours d'exécution. Les versions futures de cette option permettront de gérer les modules non chargés.


• Le patch HWPOISON qui est entrée dans le noyau 2.6.32 et qui permet d'éviter les crashs de la machine en cas de barrette mémoire défectueuse, a été complété dans cette nouvelle version du noyau Linux. HWPOISON travaille en collaboration avec les processeurs compatibles pour invalider les zones mémoire corrompues. Cette invalidation peut entraîner une procédure dite de "soft-offlining" c'est-à-dire que le contenu de la page mémoire va être copié ailleurs et la page se trouvant sur la zone RAM défaillante ne va plus être utilisée par l'infrastructure de gestion de la mémoire du système d'exploitation. Jusqu'à présent HWPOISON ne pouvait utiliser le "soft-offlining" qu'avec les pages mémoires normales (4 Ko sur les architectures processeur les plus communes) mais en était complètement incapable sur les hugepages (les pages mémoires de grandes tailles). Le noyau 2.6.37 permet maintenant le "soft-offlining" sur les hugepages. Comme le signale Andi Kleen dans son e-mail d'annonce cette fonction permet d'améliorer grandement la fiabilité mémoire sur certaines machines de type grappe de serveurs et, avantage annexe, tout est complètement transparent pour les applications.


• La mise en hibernation d'un système GNU/Linux utilisant le noyau 2.6.37 va maintenant utiliser l'algorithme LZO pour compresser les données à écrire sur le disque dur avant l'endormissement de la machine. Comme cet algorithme est très efficace on réduit globalement le temps de passage en hibernation puisque le nombre d'opérations d'entrées/sorties est réduit. Le développeur Bojan Smojver a également écrit un patch qui permet, lors du réveil de la machine, de lire de façon asynchrone l'image compressée au lieu de la lire bloc par bloc.
  D'autre part la taille par défaut de l'image à écrire après un suspend-to-disk, qui était jusqu'à présent codée en dur à 500 Mo, est maintenant variable puisqu'elle est égale à 2/5 de la mémoire vive de la machine. Un patch bienvenu puisque, comme tout le monde le sait, le codage en dur "c'est le mal™".


• Alors qu'on pouvait penser que KVM l'avait définitivement emporté et que Xen en dom0 (en mode hyperviseur) ne rentrerait jamais dans le noyau, il semble que les patchs vont finalement déboucher sur une solution complète. Le nouveau noyau 2.6.37 permet déjà de booter en dom0 (sans pilotes pour les systèmes invités) et la stratégie mise en place par Jeremy Fitzhardinge et exposée dans cet e-mail va permettre de finir l'intégration dans le noyau 2.6.38. La clé du succès a été, comme toujours, de ne pas proposer un gigantesque patch "Xen dom0" mais plutôt une série de petits patchs distincts et non invasifs. Quand le code est logiquement bien découpé, qu'il n'empiète pas sur les plates-bandes des autres mainteneurs et qu'il n'a pas d'impact sur ceux qui n'utilisent pas cette fonction alors l'intégration en mainline est plus facile !


• Puisque nous sommes dans la virtualisation parlons de KVM (Kernel-based Virtual Machine). Le code présent dans le noyau 2.6.37 permet maintenant la paravirtualisation pour les processeurs de type PowerPC. Les processeurs AMD, quant à eux, profitent de la prise en charge directement dans KVM de la fonction de "nested paging" qui est incluse dans les modèles les plus récents. Enfin les développeurs de VMware ont retiré l'interface VMI (Virtual Machine Interface) qui avait été incluse dans le noyau 2.6.21 et qui permettait à un hyperviseur de dialoguer avec une machine virtuelle. Les nouveaux processeurs Intel et AMD ont tous des extensions matérielles qui accélèrent les opérations de virtualisation (Intel VT-X et AMD-V) et cette interface VMI n'a plus de raison d'être.


• Le protocole PPTP (Point-to-point tunneling protocol) qui est largement utilisé pour mettre en place des réseaux privés virtuels (VPN) n'existait jusqu'à présent que sous forme d'applications en espace utilisateur. Le noyau 2.6.37 propose maintenant une pile PPTP complète en espace noyau. Les avantages sont une franche amélioration de la vitesse des connexions et une baisse des besoins en termes de charge processeur. Pour l'instant l'option de configuration PPTP reste en statut EXPERIMENTAL mais le code étant issu du projet accel-pptp il peut être considéré comme mature et le module va certainement sortir d'EXPERIMENTAL assez vite.


• Comme prévu dans la dépêche sur le noyau précédent la firme Tilera continue son travail d'intégration de code dans la branche principale de Linux. Ayant jugé qu'il serait plus efficace de travailler directement en upstream pour réduire la charge de travail en termes de patchs noyau, les ingénieurs de Tilera ont envoyés sur la LKML le code des pilotes réseau Gigabit Ethernet de l'architecture Tile. Le patch ajoute donc l'option de configuration CONFIG_TILE_NET et il permet de prendre en charge dès maintenant les puces de nouvelle génération qui ne sont pas encore en vente auprès des clients.


• Il a souvent été remarqué que les "exploits" (c'est-à-dire les logiciels malicieux qui exploitent des trous de sécurité) reposaient souvent sur la connaissance des journaux système (syslog). Beaucoup d'informations sont accessibles dans ces journaux comme par exemple les adresses de la pile du noyau (kernel heap addresses) et d'autres données fort indiscrètes. Évidemment il n'est pas question de désactiver les journaux qui restent très utiles dans beaucoup de situations. Dan Rosenberg a donc choisi de s'inspirer de Grsecurity (GRKERNSEC_DMESG) et de proposer un patch qui permet de restreindre l'accès aux logs. Quand on écrit "0" dans /proc/sys/kernel/dmesg_restrict tout le monde a le droit de faire un dmseg pour voir les logs du noyau. En revanche si on écrit "1" dans /proc/sys/kernel/dmesg_restrict alors il faudra obligatoirement avoir la capacité CAP_SYS_ADMIN si on veut utiliser dmseg.
  J'ajoute que si vous voulez avoir toutes les dernières nouvelles concernant la sécurité du noyau Linux je vous recommande de lire cet excellent billet de Nicolas Bareil.


• Après l'intégration dans le noyau 2.6.33 de la variante "Tiny RCU" du mécanisme de Read-Copy Update le développeur Paul McKenney continue son travail et il ajoute une nouvelle variante. Le "Tiny RCU" existant est conçu pour être utilisé sur les machines monoprocesseur et il a une empreinte mémoire extrêmement réduite. La nouvelle option TINY_PREEMPT_RCU permet d'utiliser ce "Tiny RCU" en mode préemptible c'est-à-dire que le noyau peut "mettre en attente" (préempter) temporairement une mise à jour Read-Copy Update le temps qu'une tâche prioritaire s'exécute. Cette fonction de préemption est très utile pour le temps réel et elle n'existait que pour le RCU classique (avec TREE_PREEMPT_RCU). Le patch de Paul McKenney permet de combler ce manque et Paul a soigné son code pour exploiter pleinement le fait qu'un seul processeur est utilisé (économie de mémoire).


• Le patch ajoutant le module "speakup" dans la branche -staging du noyau a été accepté dans le 2.6.37. Speakup est un outil d'accessibilité permettant aux aveugles et malvoyants de brancher la sortie console sur un synthétiseur vocal (screen reader). Depuis les messages lors du démarrage jusqu'à Lynx et Mutt tout passe par le module speakup qui envoie les résultats à un démon en espace utilisateur relayant vers le synthétiseur (espeak par exemple). De nombreuses distributions patchaient le noyau pour ajouter le module speakup et cette intégration signifie une réduction de leur charge de travail.


• Le pilote btusb qui permet de faire fonctionner les périphériques Bluetooth attachés via USB a été revu dans ce nouveau noyau. Tout d'abord la coexistence pacifique avec les puces Atheros de type ath9k est maintenant possible mais on trouve également la mise en veille automatique via la fonction "USB auto-suspend" qui était déjà possible sous Fedora. Et hop ! Un patch externe de moins et plus besoin de scruter les résultats de PowerTOP et de changer la configuration par défaut pour économiser les watts. Enfin les portables Apple de type MacBookAir ainsi que MacbookPro 6.2 et 7.1 sont maintenant gérées par le pilote btusb ce qui permet de faire fonctionner leur controleur Bluetooth sans souci.


• L'infrastructure de gestion de l'énergie (power management) a vu l'inclusion de plusieurs nouvelles fonctions qui permettent d'offrir aux pilotes la possibilité de se mettre en veille automatiquement après un certain délai. Comme le fait de changer d'état pour passer d'une période de fonctionnement normal à une période d'endormissement n'est pas gratuit (en temps et en énergie) alors on comprend qu'il faut décider de faire le saut à bon escient. Les développeurs de pilotes de périphériques peuvent maintenant faire appel à la fonction pm_runtime_set_autosuspend_delay() pour fixer un délai (en millisecondes) avant la mise en veille. Ils peuvent également utiliser pm_runtime_mark_last_busy() juste après une opération d'entrée/sortie pour aider à calculer les périodes d'activité du périphérique, de façon à choisir judicieusement le moment où un périphérique doit être suspendu.


• Vous vous souvenez certainement que le tout nouveau système de notification/scan de fichiers fanotify, qui avait été évoqué dans la dépêche du noyau 2.6.36, s'était vu désactivé au dernier moment suite à un problème d'ABI incomplète. Eric Paris s'est donc remis à l'ouvrage lors de ce cycle et les patchs qu'il a proposé permettent maintenant la gestion de la priorité entre les divers "consommateurs" de données (stockage hiérarchique, anti-malware, indexeurs de fichiers, etc). Fanotify est donc réactivé dans le noyau 2.6.37 et, pour aider à son utilisation, un programme d'exemple qui utilise toutes les fonctions de ce nouvel outil est disponible.


• Les SoC (System on Chip), c'est à dire les systèmes complets qui sont embarqués sur une seule puce, peuvent maintenant bénéficier de la gestion complète de leurs "operating performance points" dans le noyau 2.6.37. Il faut savoir que ce genre de "System on Chip" est divisé en plusieurs modules logiques, des domaines, et que chacun d'entre eux peut fonctionner à des fréquences/tensions différents. C'est l'ensemble de ces couples fréquences/tensions pour chacun des domaines qui constitue les "operating performance points" du SoC en question. Nishanth Menon, qui travaille pour Texas Instruments, a proposé un patch pour le nouveau noyau qui ajoute une bibliothèque OPP_Library afin de gérer ces divers domaines de fonctionnement. La documentation complète explique comment ce patch s'interface avec l'infrastructure Power Management de Linux. Il est probable que l'intégration des futurs SoC sera accélérée par cette bibliothèque qui permet d'enregistrer facilement leurs caractéristiques.


• Bien connue pour ses puces Wi-Fi la société Broadcom a enfin vu la lumière puisqu'elle propose, pour la première fois de son histoire, un pilote Linux libre. Jusqu'à présent il fallait se contenter d'un pilote péniblement reconstitué par rétro-ingénierie et c'est pourquoi l'annonce datant de septembre dernier a surpris et a réjoui beaucoup de monde. Le nouveau pilote se nomme brcm80211 et il gérer les cartes 802.11n de type BCM4313, BCM43224 et BCM43225. Bien entendu il se base sur l'infrastructure mac80211 du noyau et Broadcom a déjà annoncé que ce pilote servira d'infrastructure pour prendre en charge les futures puces de la firme.
  Greg Kroah-Hartman a intégré ce pilote dans la branche -staging du noyau 2.6.37, ce qui explique la première position de Broadcom au classement des contributions en nombre de lignes lors de ce cycle. La documentation explique ce qui est déjà disponible tandis que le fichier TODO liste les fonctions manquantes qui seront développées lors des cycles suivants.
  Avec l'intégration de ce pilote on peut considérer que tous les "grands" fabricants de puces Wi-Fi ont maintenant un pilote libre dans la branche principale de Linux. Comme le disent John Linville et Luis Rodriguez cette réussite est à mettre sur le compte d'un lobbying intense qui a fini par porter ses fruits: « Cela a pris plus de cinq ans, mais nous y sommes ! ».
  
  
• Comme annoncé sur le blog du développeur Roland Dreier le protocole IBoE entre dans le noyau Linux 2.6.37 (intégration dans le pilote mlx4 qui s'occupe des adaptateurs InfiniBand Mellanox). Vous n'avez jamais entendu parler de ce protocole ? C'est normal car dans le monde merveilleux des comités de normalisations et des droïdes de marketing il se nomme RoCE (RDMA over Converged Ethernet). Roland a expliqué en quoi ce nom était particulièrement stupide. Il y a déjà un protocole qui fait du "Remote Direct Memory Access over Ethernet", c'est le protocole iWARP, donc choisir un nom comme RoCE ne rime à rien. Ensuite et surtout un nom devrait décrire succinctement ce que fait un protocole et c'est ce qu'ont choisi de faire les développeurs de Linux en choisissant la dénomination IBoE. En entendant "InfiniBand over Ethernet" on comprend tout de suite de quoi il s'agit.
  L'implémentation du nouveau protocole dans le noyau 2.6.37 est préliminaire et de toute façon il semble que la norme ait été écrite un peu vite puisqu'il manque pas mal de détails techniques (sur la résolution d'adresse ou sur le multicast). On pourrait penser que cette imprécision va nuire à l'adoption de cette norme mais, toujours selon Roland Dreier, il existe maintenant un acteur dominant qui peut imposer ses choix :
  «Ces deux points techniques montrent que la spec est vraiment un boulot à moitié fini et ce au détriment de l'interopérabilité entre les diverses implémentations... Heureusement tout le monde va juste copier ce que fait la pile réseau de Linux».

Le bilan en chiffres (↑)

Côté statistiques, l'article récapitulatif du site LWN pour le 2.6.37 ne sera disponible pour les non abonnés qu'à partir du jeudi 13 janvier. Pour les autres, il est tout de même possible de consulter le site remword dédié aux statistiques du noyau Linux pour trouver les chiffres clés de ce cycle (statistiques au 31 décembre).
Il semble que le noyau 2.6.37 marque un retour vers des niveaux de contributions particulièrement élevés puisque, pour la première fois depuis le noyau 2.6.30, la barrière des 11 000 patchs est dépassée. Quant au nombre de développeurs c'est tout simplement un nouveau record absolu (voir le graphique) avec 1 270 contributeurs différents enregistrés dans les logs de Git :

• 2.6.30 : 11 984 patches (1 145 développeurs)
  
• 2.6.31 : 10 881 patches (1 164 développeurs)
  
• 2.6.32 : 10 997 patches (1 245 développeurs)
  
• 2.6.33 : 10 869 patches (1 196 développeurs)
  
• 2.6.34 : 9 443 patches (1 152 développeurs)
  
• 2.6.35 : 9 801 patches (1 185 développeurs)
  
• 2.6.36 : 9 500 patches (1 172 développeurs)
  
• 2.6.37 : 11 391 patches (1 270 développeurs)

Sur ces 1 270 contributeurs il y en a 309 qui n'étaient pas enregistrés jusqu'à présent dans les statistiques et qui font donc leur toute première contribution au noyau Linux. C'est le plus fort nombre de primo-contributeurs depuis le vénérable noyau 2.6.25 datant d'avril 2008.
Si l'on s'intéresse aux statistiques depuis l'import initial des données dans Git (le 16 avril 2005) alors nous franchissons pour la première fois la barre des 200 000 commits (209 470 exactement). On peut s'amuser à calculer que, sur les 2 082 jours écoulés entre le 16/05/2005 et le 28/12/2010, cela représente 100,6 patchs par jour, y compris les weekends et les jours fériés.
Incroyable de voir un projet recevoir ainsi plus de 100 commits par jour pendant plus de cinq ans !

Enfin , et comme demandé explicitement par Linus lors du cycle précédent, les développeurs du noyau ont été plus vigilants sur le bon enregistrement des tags "Reported by". Leur nombre s'est accru puisqu'il est passé de seulement 284 pour le 2.6.36 à 458 pour le noyau 2.6.37. Ces tags sont très importants puisqu'ils matérialisent la reconnaissance des développeurs envers les contributions des personnes faisant des rapports de bug.

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.

Optimisations VFS

Le noyau 2.6.36 avait vu l'intégration de plusieurs patchs de Nick Piggin visant à optimiser la couche Virtual File System pour permettre une meilleure montée en charge. Ce travail avait été fort apprécié, mais il n'était pas terminé et tout le monde attendait l'arrivée de nouveaux patchs dans le noyau 2.6.37. L'ennui c'est que Nick a pris plusieurs jours de vacances et qu'en son absence le développeur Dave Chinner a proposé une solution alternative. Il en était déjà à la version 5 de son patch quand Nick est rentré de vacances... Tous les ingrédients étaient donc réunis pour une de ces confrontations techniques dont la LKML a le secret !
Malheureusement, alors que nous étions en droit d'attendre un bon vieux match de catch dans la boue, le débat s'est déroulé à un niveau de complexité tellement stratosphérique que les béotiens que nous sommes n'ont pas vraiment pu apprécier la bataille. Le site LWN a publié un article expliquant les différences entre les deux propositions et, dans son post introduisant son ensemble de 35 patchs, Nick a lui aussi résumé ses raisons pour rejeter l'approche de Dave Chinner.

En (très) gros, chacun des développeurs tente d'en finir avec les verrous inode_lock et dcache_lock qui protègent des opérations critiques du VFS mais qui limitent aussi beaucoup la montée en charge. L'approche de Dave est plus directe mais aussi plus risquée. Les verrous à grains fins qu'il introduit dès le début de sa série de patchs induisent des risques de régressions alors que Nick a opté pour une approche plus prudente. Pour lui il est important de ne pas déstabiliser un morceau de code aussi sensible et compliqué que le VFS. Nick utilise aussi beaucoup la technique du RCU (Read Copy Update) alors que Dave ne s'en sert pas du tout.
Le débat s'est encore compliqué quand Al Viro, mainteneur officiel du VFS, a critiqué les deux séries de patchs et proposé d'autres solutions envisageables.
Pour le 2.6.37 seuls quelques patchs non controversés de Nick (1 - 2) ont été intégrés dans le noyau. Cela devrait améliorer légèrement les capacités de montée en charge de la couche VFS mais, évidemment, le gros des bénéfices est encore à venir.
Nous pouvons être certains qu'une des deux options sera intégrée car Linus est intervenu en personne dans le débat en répondant à un e-mail de Nick Piggin :

«Bon, je dois dire que si nous n'avons pas cette série de patchs pour retirer le verrou du VFS lors de la prochaine période de merge, je serai personnellement très déçu. Au point que, si Al et Dave ne peuvent pas se mettre d'accord sur une solution, je prendrai juste la décision autoritaire de passer outre les blocages et de merger ta série.
Donc réveillez-vous les gars: les discussions vigoureuses c'est bien mais l'obstructionnisme ça ne marchera pas».

À la suite de cette annonce Nick s'est dépêché de publier une version mise à jour de ses patchs et a proposé une revue générale du code pour stabiliser la série et permettre son inclusion. Nul doute que les yeux perçants des développeurs Linux vont se pencher sur son code et sa documentation afin de nous proposer une couche VFS revue et améliorée dans nos futurs noyaux.

Aller plus loin

• Les nouveautés du noyau 2.6.37 (186 clics)
• Le bilan des ajouts partie 1 (27 clics)
• Le bilan des ajouts partie 2 (13 clics)
• Les prévisions pour l'avenir de Linux (28 clics)