Le noyau Linux 2.6.36 est disponible

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

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

Le sommaire...

• La phase de test
  
  • RC-2
    
  • RC-3
    
  • RC-4
    
  • RC-5
    
  • RC-6
    
  • RC-7
  
  
• Les nouveautés
  
  • AppArmor
    
  • OOM Killer
    
  • fanotify
    
  • wakeup_count
    
  • Concurrency-managed workqueues
    
  • Optimisations VFS
    
  • Attente optimiste sur les mutex
  
  
• En bref
  
  • Statistiques pour PowerTOP
    
  • Architecture Tilera
    
  • Pilote Intel
    
  • Pilote AMD
    
  • Configuration Ext3
    
  • Infrastructure LIRC
    
  • CIFS
    
  • NFS
    
  • SquashFS
    
  • DM et TRIM
    
  • Table TCP
    
  • Tegra
    
  • Ben NanoNote
    
  • KVM
    
  • Scripts Coccinelle
    
  • Module TOMOYO
    
  • Optimisations pour POWER7
    
  • USB
    
  • Compcache/Ramzswap/Zram
    
  • Patch Toshiba
  
  
• Le bilan en chiffres
  
• Pour la suite
• Un noyau sans BKL ?

La phase de test (↑)

RC-2

Linus a dérogé à ses habitudes puisqu'il n'a pas envoyé de mail pour commenter la première version candidate du noyau 2.6.36.
Il a fallu attendre la RC-2 du 22 août pour voir apparaître le message traditionnel :

« Je n'ai jamais vraiment trouvé le temps d'annoncer la RC-1 quand je l'ai mise à disposition. Nous avons eu un tas de petit soucis (comme une corruption mémoire dans la couche HID causant des problèmes aléatoires) et je n'ai jamais pu rectifier cette absence d'annonce. J'espère que la RC-2 est une bonne occasion pour corriger le tir.
Le commentaire principal est que je vais revenir en mode "super strict" à partir de cette RC-2. En d'autres termes ne m'envoyez que des corrections de bugs. Vraiment. J'ai déjà refusé des trucs qui étaient de façon évidente des demandes d'ajout de nouvelles fonctions après la fermeture de la période de merge. J'ai quand même accepté certaines choses (dans certains cas parce que je voulais vraiment ce code, comme pour les améliorations VFS). Mais maintenant c'est fini. Je vais être vraiment strict parce que je pense que ça nous a aidé lors de la période de stabilisation du 2.6.35 et donc je pense que ça vaut le coup de le faire aussi pour le 2.6.36. »

RC-3

Le 29 août, c'est la RC-3 qui est annoncée :

« Bon vous connaissez tous la routine maintenant : nouvelle semaine, nouvelle RC.
Rien de particulier n'émerge dont je puisse me souvenir. Comme d'habitude il y a surtout des corrections de pilotes (65%) dont la majeure partie (en terme de lignes) est simplement la suppression d'un pilote de staging puisqu'il n'était pas vraiment prêt et qu'il n'y avait pas de progrès. Sur le front du "vaguement susceptible de provoquer une certaine excitation", il y a également des mises à jour drm pour radeon/nouveau.
En dehors des pilotes il y a des mises à jour sur CIFS, Ceph et XFS et du côté de arch il y a des patchs pour sparc/blackfin.
De toute façon j'espère que ça va être une RC très ennuyeuse parce que je suis sur le point de partir au Brésil pour LinuxCon et, même si je suivrai les problèmes via email, je ne prévois pas d'appliquer le moindre pull la semaine prochaine. »

RC-4

De retour du Brésil, Linus a attendu le 12 septembre pour publier la RC-4:

« Du fait du voyage ça fait deux semaines au lieu d'une semaine d'habitude, mais la RC-4 est maintenant disponible.
Rien de particulier qui émerge bien qu'il y ait eu plus de bruit dans la partie GPU que ce que je voudrais à cette étape du cycle (que ce soit Radeon ou i915). À part ça, ce sont vraiment des tas de changements d'une seule ligne un peu partout.
Un truc qui vaut la peine d'être mentionné et qui n'a rien à voir avec cette version particulière, mais qui est apparue sur un thread cette semaine : ce serait bien si les gens qui créent les patchs se mettaient à essayer de fournir l'information au sujet de la personne qui a rapporté le bug. Nous avons un bon nombre de tags "Reported-by:" dans nos logs mais il devrait y en avoir bien plus que ça. Penser à reconnaître la contribution de tous les gens qui testent ou qui signalent les problèmes est une bonne pratique. Parfois la correction est triviale et le vrai travail a consisté à découvrir que le problème existait et à le signaler »

RC-5

Après huit jours d'attente, la version candidate RC-5 du nouveau noyau a été annoncée :

« J'aurais dû faire ça hier mais j'ai été distrait. Donc voici la RC-5 avec un jour de retard - comme ça elle a pu bénéficier de nouvelles mises à jour venant de Greg du fait de ma procrastination.
Rien de particulier. Excepté peut-être le fait qu'Al a visiblement jeté un coup d'œil au code sigreturn pour les différentes architectures et qu'il a trouvé des problèmes.
À part ça ? Des corrections un peu partout - avec quelques reverts au milieu pour pimenter un peu. »

Al Viro, développeur d'une grande virtuosité technique et qui est très respecté par Linus, a d'ailleurs ajouté un petit commentaire au mail d'annonce de la RC-5 pour exprimer tout le mal qu'il pensait du code passé en revue :

« Il y a encore d'autres patchs dans cette pile. J'en estime le nombre à 30-40 à moins que d'autres classes de bugs n'apparaissent au milieu de ce bordel. Dans ce cas tout est envisageable... Et oui, je suis sérieux. C'est vraiment pourri à ce point.
Ce que j'ai envoyé ce sont juste les corrections de bugs. Le vrai nettoyage devra attendre la prochaine période de merge. »

RC-6

Le 28 septembre c'est la RC-6 qui a été rendue disponible par Linus. Celui-ci a laissé entendre dans son mail, pour la plus grande horreur de votre serviteur très en retard dans la rédaction de la dépêche, qu'il n'était pas impossible que ce soit la dernière version candidate :

« Je ne sais pas pourquoi je me suis mis à penser que les semaines ont huit jours. C'est clairement une bizarre sorte de déficience mentale dont je suis atteint. Donc encore une fois la RC est en retard d'un jour.
J'aimerai que les développeurs jettent un coup d'œil à la liste des régressions compilée par Rafael car elle est raisonnablement courte.
D'un autre côté je n'ai pas vraiment de _grosse_ raison de retarder la sortie du 2.6.36 encore plus. Je pense que j'ai échoué à être aussi strict que j'aurai dû l'être et je vais voir comment se passe la semaine prochaine.
Cela dit je n'ai pas encore un bon feeling "chaud et rassurant" à ce stade, peut-être parce qu'il y a eu plus de commits dans cette RC que ce que je voudrais (non, le jour en plus n'est pas suffisant pour expliquer ça). Je suspecte que je vais encore sortir une RC-7 à moins que les choses ne se calment vraiment.
Donc, les gars, uniquement les régressions et en particulier les problème sérieux, OK ? »

RC-7

La version candidate, la RC-7, a été mise à disposition par Linus le 6 octobre dernier :

« J'ai décidé de rompre avec ma politique du une-semaine-ça-fait-huit-jours et de sortir la RC-7 après une vraie semaine de 7 jours. Ouhaou !
Cela devrait être la dernière version candidate, je ne vois aucune raison de continuer à retarder la livraison. Il y a toujours plus de changements dans drivers/gpu/drm que ce que j'avais espéré, mais ils ont l'air corrects et inoffensifs (dernières paroles célèbres).
Pour l'astuce Git du jour faire:
git log --stat --oneline --no-merges v2.6.36-rc6..v2.6.36-rc7
et vous aurez une vue densifiée des commits permettant de repérer visuellement ceux qui ne sont pas des changements triviaux d'une seule ligne. »

Enfin la RC-8 a été publiée par Linus le 15 octobre afin de corriger divers problèmes (voir le paragraphe sur fanotify) mais le mail d'annonce n'a été envoyé que tardivement et il ne décrit pas vraiment les changements. Linus se contente de pester contre son téléphone Android qui persiste à vouloir envoyer ses mails au format html et contre le serveur mail de la LKML qui mange ses mails.

Les nouveautés (↑)

AppArmor

Après plusieurs années à taper à la porte du noyau, le module de sécurité AppArmor fait finalement son entrée dans la version 2.6.36 de Linux.
Depuis 2003, le noyau Linux contient une infrastructure nommée LSM (Linux Security Modules) sur laquelle peut se brancher un module de sécurité pour proposer un mécanisme spécifique de contrôle d'accès. Historiquement c'est le module SELinux qui était le seul client de l'infrastructure LSM, mais tout a changé avec le noyau 2.6.25 en 2008 puisque le module SMACK a été accepté dans la branche principale par Linus Torvalds. Plus basique que SELinux, le module SMACK fonctionne lui aussi à l'aide de labels (des attributs étendus) qui sont attachés aux différents objets du système (les fichiers, les répertoires, les ports...etc).

Seconde nouveauté en juin 2009 avec l'arrivé dans le noyau 2.6.30 d'un troisième module de sécurité. TOMOYO est basé sur une technique différente puisqu'il n'utilise pas des labels. Au lieu de ça, il s'appuie sur le chemin d'accès (pathname) pour autoriser ou interdire les actions. Cette approche est réputée plus simple à utiliser que celle basée sur des labels (qui nécessite une recompilation après chaque changement).

Le nouveau noyau 2.6.36 voit maintenant arriver AppArmor qui est, comme TOMOYO, un module de sécurité utilisant le pathname.

Développé à l'origine par Crispin Cowan de la société Immunix, le projet a été incorporé à Novell lors du rachat d'Immunix. AppArmor a été ajouté aux distributions OpenSUSE et SUSE Linux Enterprise mais Novell a finalement décidé d'abandonner le projet et de se rallier à SELinux. Tous les développeurs ont alors été licenciés et on pouvait penser que c'était la fin d'AppArmor. C'était sans compter sur Canonical qui, utilisant AppArmor dans Ubuntu, a décidé de continuer le développement du module et à chercher à l'intégrer dans la branche principale du noyau. L'idée est d'avoir un patch externe de moins à maintenir (et peut-être de redorer le blason de la société en tant que contributeur du noyau).
L'annonce par James Morris de l'intégration d'AppArmor dans la version 2.6.36 est donc une belle réussite à mettre à l'actif de la société de Mark Shuttleworth.

C'est le développeur John Johansen et son équipe qui ont travaillé sur cette intégration, notamment en modifiant le code d'AppArmor pour qu'il utilise les nouveaux crochets logiciels (hooks) de LSM. L'infrastructure d'accueil des modules avait en effet été modifiée lors de l'arrivée de TOMOYO et des hooks spéciaux pour les modules basés sur le chemin avaient été ajoutés. Ces crochets de type "security_path" sont donc maintenant au cœur d'AppArmor alors que les précédentes versions se basaient sur des patchs VFS assez sales.
AppArmor fonctionne sur le principe d'une liste blanche. Les applications qui sont protégées par AppArmor ont chacune un fichier dédié contenant leur "profil" et ce fichier est stocké dans /etc/apparmor.d/. Bien entendu, on peut utiliser un mode permissif qui se contente d'enregistrer les violations des directives du profil (c'est le mode "complain"). C'est fort utile pour construire et corriger progressivement un profil.
Une fois ceci réalisé, on peut passer en mode "enforce" pour réellement interdire l'accès aux chemins non spécifiés dans le profil de l'application. Le noyau charge un profil spécifique grâce à l'outil apparmor_parser.

La syntaxe des fichiers de profils qui sont associés aux applications et assez simple à comprendre (c'est sans comparaison par rapport à SELinux). En gros on trouve le chemin d'accès vers une ressource qui est utilisée par l'application et le mode d'accès qui sera imposé par AppArmor. Ces divers modes sont représentés par des lettres (r pour read, w pour write, l pour link, etc). Si on néglige les includes initiaux, un profil (incomplet) pour Postfix pourrait donc ressembler à ceci :

/etc/postfix/main.cf r,
/etc/postfix/virtual.db r,
/proc/stat r,
/proc/sys/kernel/ngroups_max r,
/var/spool/postfix/pid/unix.flush rw,

En plus de ces restrictions basées sur le chemin, il est possible de confiner plus sévèrement un programme en déclarant dans son profil les "capabilities" POSIX auquel il a droit.
La documentation Novell qui est encore disponible est très complète et explique fort bien la syntaxe détaillée du profil d'une application (le wiki d'AppArmor offre également beaucoup de documents d'aide). Il est possible d'écrire ces profils "à la main" si on en a le courage et la compétence, mais il est plus facile d'opter pour l'utilitaire aa-genprof qui enregistre les actions de l'utilisateur et crée le profil associé.

En conclusion AppArmor semble être, tout comme TOMOYO, un module de sécurité moins difficile à utiliser que SELinux. Après la réécriture basée sur les crochets LSM de type security_path les critiques acerbes se sont faites plus rares même si, fondamentalement, les partisans d'une sécurité basée sur les labels continuent à dédaigner AppArmor. D'un autre côté il faut bien voir que SELinux bénéficie de la force de développement de Red Hat et que des outils graphiques simplifiant son utilisation sont disponibles pour tous.
Pour les utilisateurs, cette concurrence sera certainement bénéfique et le module qui sera choisi par défaut sera un élément de différenciation pour les distributions Linux.

OOM Killer

La fonction OOM killer (Out-Of-Memory Killer) a été entièrement réécrite dans le noyau 2.6.36 afin d'améliorer son fonctionnement.
Le mécanisme OOM killer est un mécanisme de la dernière chance qui est incorporé au noyau Linux en cas de dépassement de la capacité mémoire. Si le système n'a plus assez de mémoire à allouer aux processus et que le swap a été lui aussi entièrement rempli alors le noyau n'a pas d'autre choix que de faire appel à son tueur à gages préféré : OOM killer.
Ce dernier va, selon des heuristiques complexes, se choisir une victime parmi les processus s'exécutant sur la machine et il va mettre fin à ses jours. L'idée est bien entendu d'éviter un crash de la machine en essayant d'éliminer le processus glouton qui réclamait toujours plus de mémoire.
Évidemment il est critique de bien choisir le processus qui va être éliminé si on veut résoudre le problème de pression mémoire. Les versions précédentes de l'OOM killer n'étaient pas réputées pour leurs frappes chirurgicales et elles avaient quelque peu tendance à dégommer le passant innocent qui traversait la rue au mauvais moment plutôt que le vrai processus coupable.
C'est ce comportement fort peu civilisé qui a conduit David Rientjes, ingénieur chez Google, à réécrire OOM killer afin d'améliorer la phase de choix de la victime qui est le point crucial de ce mécanisme.

David s'est attelé à la tâche de revoir complètement le fonctionnement de la fonction badness() qui est chargée d'évaluer le degré de "culpabilité" d'un processus. Au lieu de chercher à empiler les tests divers et variées accumulés au cours du temps, le nouveau code se contente de regarder quel est le pourcentage de mémoire qu'utilise le processus (Resident Set Size + Swap) et cette valeur est traduite en un score de "badness". Si un processus utilise la totalité de la mémoire lui ayant été allouée alors son score est de 1000 (et de 0 si il n'utilise rien). Bien entendu les processus ayant un score de 1000 ont l'équivalent d'un rayon laser pointé sur le front et seront choisis en premier par l'OOM killer en cas de besoin. Les processus lancés par root bénéficient d'une soustraction de 30 à leur score de badness afin de diminuer leur chance de se faire assassiner à l'improviste en cas de situation Out of Memory.
Selon David Rientjes le fait de se baser sur le pourcentage réel de mémoire utilisé par rapport à ce qui est disponible (Resident Set Size + Swap) est un indicateur bien plus fiable et précis que les anciennes heuristiques :

« Cette technique est particulièrement utile sur les ordinateurs de bureau pour les cas dans lesquels KDE ou GNOME étaient choisis par l'OOM killer à la place du vrai processus coupable. »

Bien entendu l'administrateur de la machine peut indiquer ses préférences dans les cibles en utilisant la nouvelle interface /proc/pid_du_processus/oom_score_adj (d'ailleurs l'ancienne interface oom_adj ne doit plus être utilisée et sera retirée dans les futurs noyaux).
L'interface oom_score_adj permet à l'administrateur ayant des envies meurtrières d'ajouter au maximum 1000 points au score de badness d'un processus (OOM_SCORE_ADJ_MAX) tandis que les pacifistes pourront soustraire au maximum 1000 points au score des processus qui ne doivent à aucun prix être tués (OOM_SCORE_ADJ_MIN).

Après ce travail de fond sur la fonction badness() David a implémenté plusieurs corrections et améliorations diverses comme celle visant les processus fils. L'OOM killer des anciens noyaux était un vrai tueur sans pitié et sans remords. Quand il entrait en action, il essayait de tuer les processus fils plutôt que les parents avec l'idée que la stabilité du système en souffrirait moins puisque les démons systèmes seraient épargnés.
L'idée n'était pas mauvaise mais elle ne tenait pas compte du taux de "badness" du processus fils, ce qui entrainait de malencontreuses erreurs de cible et les processus parents éplorés n'avaient plus que leurs yeux pour pleurer.
Maintenant l'OOM killer va vraiment viser les enfants qui ne sont pas sages et qui auront le score de badness le plus élevé.

Le mécanisme d'OOM killer tient mieux compte des ensembles de processeurs (cpusets), et il applique également une large pénalité aux processus considérés comme des fork bombs (ayant plus de 1000 enfants en moins d'une seconde).
On peut aussi citer comme autre amélioration le fait que l'OOM killer attend maintenant que la mémoire du processus tué soit vraiment complètement libérée avant de se choisir éventuellement une nouvelle victime. Enfin, avec la réécriture de David Rientjes, le comportement du code de l'OOM killer est maintenant unifié pour toutes les architectures (la sémantique est identique), ce qui simplifie sa compréhension par les développeurs et sa maintenance ultérieure.

Évidemment tout ce travail pour une fonction très rarement utilisée et qu'on espère ne jamais avoir à déclencher peut sembler quelque peu superfétatoire. David Rientjes a travaillé très dur sur cette réécriture de l'OOM killer et pourtant ce morceau de code sera sans doute aussi détesté qu'auparavant.
Comme le dit excellemment Jon Corbet :

« Pour la plupart des utilisateurs cette fonction est probablement aussi enthousiasmante que de recevoir une brosse à WC comme cadeau d'anniversaire. Mais, si cela aide un système à traverser une situation OOM et à ressortir en bon état, alors ils finiront peut-être par apprécier ce travail. »

fanotify

L'outil fanotify, qui sert à générer des notifications concernant les évènements touchant au système de fichier, a été intégré au noyau 2.6.36.
Fanotify repose sur l'infrastructure fsnotify qui était entrée dans le noyau 2.6.31. La dépêche LinuxFr de l'époque explique en détail le contexte ayant conduit Eric Paris à se lancer dans la réécriture des anciens et vénérables systèmes de notifications qu'étaient dnotify/inotify.
Eric n'a jamais caché que son intention était, à terme, de créer un outil permettant de scanner les fichiers pour détecter des malwares ou des virus. Comme cette proposition n'a pas suscité un grand enthousiasme parmi ses pairs, il a décidé de procéder par étape et d'améliorer l'existant pour faire passer la pilule. Il a donc écrit fsnotify comme étant un remplaçant plus moderne et plus efficace que l'ancien duo dnotify/inotify et ce en conservant l'API d'accès au système de notification. Ce travail ayant été intégré dans le noyau 2.6.31, Eric Paris a pu s'en servir pour poursuivre son véritable but qui était le scan de fichiers. C'est l'infrastructure technique de cet outil modifié, fanotify, qui est ici ajouté dans le nouveau noyau.

Techniquement fanotify ajoute plusieurs nouveaux appels systèmes (fanotify_init ou encore fanotify_mark) et se sert de ces appels pour retourner un descripteur de fichier c'est à dire une clé pour accéder à un fichier. En gros l'idée est que fanotify va taguer les fichiers avec un flag (FAN_ACCESS, FAN_MODIFY, FAN_OPEN) et une application vivant en espace utilisateur va utiliser ces informations pour réagir aux divers évènements concernant ces fichiers (par exemple pour appliquer des règles de blocages d'accès). C'est de cette façon que le module de scan pourra être implémenté maintenant que toute cette infrastructure est en place. Actuellement les tags sont présents mais il n'est pas encore possible de réagir à ces informations et, par exemple, le module anti-malware ne pourrait pas bloquer une commande d'ouverture de fichier open(). Quand ces parties manquantes seront implémentées il suffira de compiler son noyau avec l'option de configuration FANOTIFY_ACCESS_PERMISSIONS et les modules de scan pourront décider d'accorder ou pas l'accès au système de fichiers.
Eric Paris a donc terminé sa réorganisation complète du système des notifications du noyau Linux et il va maintenant s'atteler à l'écriture des outils permettant de contrôler les accès au système de fichiers. Après cette remise à plat des notifications on pouvait s'attendre à une certaine stabilité puisque Linus a décrété qu'il aimerait que le calme revienne dans ce domaine:

« Je ne vais certainement pas accepter de fusionner une autre réécriture du système de notification avant quelques _années_ maintenant. Assez c'est assez. Et si le système actuel n'est pas encore assez bon, la personne qui voudra une fois de plus tout reprendre à zéro dans la couche de notification aura intérêt à avoir de sacrés pu*ains de bons arguments. »

La perversité de l'Univers étant sans limites, un problème est apparu tardivement dans le code de fanotify. Après la sortie de la RC-7 le développeur Tvrtko Ursulin de la société Sophos a fait remarquer que les nouveaux appels systèmes, et en particulier fanotify_init, ne permettaient pas la gestion de la priorité entre les différents clients. Pour Tvrtko cette gestion de la coexistence de divers clients en même temps est un impératif et Eric Paris a été prompt à reconnaître franchement le problème (Shit. Hrmph.... You could have a real interface issue here.... Shit).
Après une courte discussion sur la liste de diffusion il a été décidé de ne pas tenter de réparation de fortune à la dernière minute et de simplement désactiver les appels systèmes de fanotify.
Le code est toujours présent mais il ne peut pas être utilisé par des programmes en espace utilisateur ce qui évite de figer dans le marbre une ABI incomplète. Eric Paris travaille déjà sur la gestion de la hiérarchie des clients et le prochain cycle verra donc sans doute, pour la plus grande satisfaction de tous, la fin de la saga du nouveau système de notification du noyau.

wakeup_count

Le mécanisme de wakeup_count, destiné à répondre en partie aux besoins des systèmes Android, a été ajouté dans le noyau 2.6.36.
On se souvient qu'une des particularités du noyau Linux modifié qui est utilisé dans Android est le patch wakelock écrit par Google. Ce mécanisme (rebaptisé "suspend blockers" par la suite) permet à une application d'interdire la mise en veille automatique du système. Par défaut, le système est toujours endormi pour économiser la batterie, et ce n'est qu'après le déclenchement d'un verrou de type "suspend blocker" qu'une application peut bloquer cet endormissement par défaut pour ensuite s'exécuter tranquillement afin de satisfaire une demande quelconque.
Cette technique, et son implémentation particulière dans Android, ont toujours été vertement critiquées par les développeurs Linux (pas d'utilisation des infrastructures existantes dans le noyau, risque d'oubli du déblocage après la pose du verrou ce qui interdit à tout jamais la mise en veille, etc.).
Néanmoins, tout le monde était conscient que pour inciter Android à réintégrer le giron de la branche principale, il fallait que le noyau possède des mécanismes susceptibles de répondre aux besoins particuliers des périphériques sous Android.

Rafael Wysocki s'est donc attelé à l'écriture du patch wakeup_count afin de renforcer la fiabilité de la fonction d'endormissement intégrée au noyau Linux. En effet les ingénieurs Google avaient pointé du doigt une faiblesse potentielle des noyaux antérieurs : si un signal de réveil (wakeup event) est envoyé à un moment mal choisi, alors il peut être perdu et le système ne réagira pas comme il le devrait.
Rafael décrit dans un mail sur la liste de diffusion ce dysfonctionnement potentiel. Par exemple quand un système va s'endormir alors la valeur écrite dans /sys/power/state change. Si la valeur écrite est "standby" alors le système se met en veille simple. Si c'est "mem" alors on obtient un suspend-to-RAM, et un suspend-to-disk dans le cas de "disk".
Maintenant, imaginons qu'un signal de réveil (wakeup event) soit émis au moment précis où la valeur est écrite dans /sys/power/state. Si c'est le cas, alors l'application en espace utilisateur qui allait recevoir et traiter le wakeup event ne va rien pouvoir faire et le système va s'endormir.
Ce problème relève de ce qu'on appelle une situation de compétition (race condition en anglais). Il y a compétition entre l'écriture dans /sys/power/state et le traitement du wakeup event par l'application, et c'est le premier à réagir qui gagne. Comme le noyau n'a aucun moyen de savoir quand les programmes en espace utilisateur vont avoir terminé leur travail, la situation semble bloquée (à moins d'une très lourde réécriture de toutes les applications userspace).
Évidemment pour les ingénieurs Google un tel comportement est difficilement acceptable et ils voudraient avoir certaines garanties que le wakeup event soit bien traité au bon moment.

La solution de Rafael repose sur un nouvel attribut nommé /sys/power/wakeup_count et un nouveau compteur dans lequel seront enregistrés tous les wakeup events ayant été émis (les pilotes utiliseront la fonction pm_wakeup_event() pour incrémenter automatiquement ce compteur lors de l'émission d'un wakeup event).
Tout le monde peut lire la valeur dans /sys/power/wakeup_count, mais pour écrire dedans, il faut que la valeur soit égale à celle du compteur des wakeup event.
L'idée est qu'un programme en espace utilisateur, que Rafael nomme le "User space Power Manager", va aller lire la valeur dans le compteur wakeup events (disons 42 par exemple). Ensuite ce programme va vérifier auprès de tous les programmes utilisateurs susceptibles d'utiliser les wakeup events si l'un d'entre eux est en train d'en traiter un. Si c'est le cas (par exemple le pilote de l'écran tactile a envoyé un wakeup event pour informer les programmes en espace utilisateur qu'un gros doigt graisseux s'est posé sur l'écran et qu'il y a du boulot à faire), alors on attend simplement la fin du traitement.
Si aucun wakeup event n'est en cours de traitement alors le Power Manager va essayer d'écrire 42 dans /sys/power/wakeup_count. Cette écriture ne va réussir que si le compteur des wakeup events est toujours à 42. Si c'est bien le cas alors on sait qu'aucun wakeup event n'est en cours de traitement et le Power manager pourra sereinement lancer l'endormissement du système en écrivant dans /sys/power/state.
Si, au contraire, le compteur des wakeup events n'est plus à 42, alors l'écriture dans /sys/power/wakeup_count est interdite et le Power Manager saura qu'un wakeup event a été émis (puisqu'il a incrémenté le compteur) mais qu'il n'a pas encore été traité. Le Power Manager va donc s'abstenir d'endormir le système afin de laisser le temps aux applications de traiter le wakeup event.

La solution de Rafael semble donc conceptuellement assez simple. Il a pensé aux détails et à tous les cas spéciaux, par exemple on peut désactiver le système si un endormissement rapide est nécessaire en cas de surchauffe ou de batterie vide.
Les avantages par rapport au système Android actuel sont :

• Un code plus simple ne nécessitant pas toute l'infrastructure de "suspend blocker" ;
  
• Pas de nécessité de débloquer le verrou interdisant la mise en veille ;
  
• Pas besoin d'une interface avec l'espace utilisateur gravée dans le marbre.

Le développeur Google Arve Hjønnevåg a répondu sur la LKML en indiquant que ce patch ne répondait pas à tous les besoins d'Android. Ce qui l'ennuie, c'est la phase d'interrogation des programmes utilisateurs susceptibles d'utiliser les wakeup events pour savoir si ils sont en train d'en traiter. Il pense que la solution d'un timeout n'est pas viable puisque les besoins des applications sont tous différents (entre le temps de réaction à un paquet réseau, le temps de réaction d'un signal de batterie faible ou le temps de réaction d'un contact d'un doigt sur l'écran).
Sa conclusion est donc lapidaire :

« Je n'ai pas eu le temps de suivre activement cette discussion, mais je ne pense pas que cette solution soit la bonne. »

Du travail reste donc à faire côté noyau pour répondre pleinement aux besoins complexes d'Android avec une solution qui soit en même temps acceptables par les développeurs Linux. Le côté "quick and dirty" du patch suspend blocker d'Android continue à faire grincer des dents et cette technique ne sera jamais intégrée telle quelle dans la branche principale. La seule solution est de proposer une meilleure option technique et, même si il ne répond pas à toutes les demandes d'Android, le patch de Rafael Wysocki est sans doute un pas dans la bonne direction.

Concurrency-managed workqueues

Le patch de Tejun Heo implémentant le mécanisme des "concurrency-managed workqueues" a été intégré dans le nouveau noyau.
Pour comprendre de quoi il s'agit, il faut tout d'abord avoir une idée de ce qu'est une workqueue. En gros c'est une liste de tâches à effectuer avec un thread noyau associé (par processeur) qui va se charger d'exécuter ces tâches. Comme tout se passe dans le noyau, le thread peut s'endormir sans risque, ce qui est bien pratique.
Par contre, ce qui est moins réjouissant, c'est que le mécanisme de "shared workqueue" présent dans le noyau, et qui devrait être l'implémentation de référence pour gérer les workqueues, n'est pas très utilisé par les développeurs. Évidemment, comme ce mécanisme est partagé (shared), on se doute bien qu'une tâche de longue durée va monopoliser le processeur au détriment des autres tâches. La solution à ce problème a été d'implémenter des workqueues dans chacun des sous-systèmes du noyau de façon à ce que que chacun reste chez soi sans être envahis par les tâches du sous-système voisin.
À l'usage, cette solution s'est révélée être une mauvaise idée puisqu'on se retrouve avec des tonnes de threads noyau qui tournent et entrent en compétition pour accéder au précieux CPU (sans parler des risques d'interblocages entre les tâches mutuellement dépendantes).

Tejun Heo a décidé de prendre le problème à bras le corps et de réécrire entièrement le mécanisme des workqueues. Son idée est de proposer un outil unifié efficace qui incitera à l'abandon des implémentations diverses et variées qui pullulent dans le noyau.
Ce travail est de grande ampleur (le code a été fractionné en 43 patchs distincts) et il change fondamentalement le mécanisme des workqueues dans le noyau Linux.
Maintenant, chaque CPU ne sera plus associé à un seul thread noyau dédié, mais à un ensemble de threads prêts à l'emploi (c'est ce qu'on nomme un thread pool). Cet excellent schéma au format SVG issu de Wikipédia illustre bien ce concept de "thread pool" avec un ensemble de threads qui se chargent des tâches listées en amont (task queue) et qui régurgitent des tâches terminées en aval (completed tasks). La workqueue par CPU (nommée gcwq pour global cpu workqueue) va maintenir le juste nombre de threads actifs et, pour éviter les compétitions néfastes entre les tâches, Tejun Heo a écrit son code de façon à ce qu'il s'interface avec l'ordonnanceur du noyau (en créant une nouvelle scheduler class). Ainsi, dès qu'une tâche s'endort, l'ordonnanceur peut prévenir le mécanisme unifié des workqueues et lui dire qu'il est temps de lancer un nouveau thread sur une nouvelle tâche.

Selon la documentation les avantages de cette solution sont nombreux :

• On profite de la sagesse de l'ordonnancement en mode "workqueue class" pour gérer toutes ces sordides questions de compétitions qui empoisonnaient l'existence des développeurs auparavant et qui conduisaient à des interblocages (deadlocks).
  
• Au lieu d'avoir pleins de mécanismes différents de workqueues, on a un seul code unifié avec un thread pool par processeur, ce qui réduit le nombre total des threads noyau tournant sur le système.
  
• Comme les situations de compétitions sont réduites, on évite les changements de contextes et la pression sur la mémoire cache, ce qui conduit à une amélioration des performances.
  
• Ce mécanisme des "concurrency-managed workqueues" peut être utilisé pour les tâches asynchrones, ce qui permet encore une fois d'unifier en un seul outil les diverses implémentations des mécanismes asynchrones du noyau (slow-work, async, etc).

Les questions sur la LKML on été nombreuses et incisives puisqu'il n'est pas rare que divers cas tordus non envisagés par un développeur fassent capoter une belle idée. Cette fois-ci, Tejun a pu apporter une réponse satisfaisante à tous les cas. Par exemple, dans l'hypothèse d'une machine peu puissante et surchargée, il est possible que la création de nouveau thread devienne impossible...mais Tejun avait pensé à cela, et des "rescuer threads" sont gardés en réserve en cas de nécessité.
Et si on enlève un CPU, ce qui est possible avec le mécanisme d'hotplugging, que se passe-il ? Hop ! Tejun sort son "trustee manager" qui prend en charge la queue en cours d'exécution et la termine proprement.

Ayant brillamment passé la terrible ordalie qu'est la soumission d'un patch important sur la LKML, Tejun Heo a dû attendre que ses pairs vérifient son code et se convainquent de la pertinence de sa solution. Après plusieurs mois d'incertitude (sa soumission date d'octobre 2009), les patchs ont été acceptés par Linus et se retrouvent maintenant dans le noyau 2.6.36 tout chaud qui vient d'arriver.

Optimisations VFS

Une partie du travail de Nick Piggin consistant à améliorer la couche Virtual File System a été intégrée au noyau 2.6.36.
Ce travail d'optimisation du VFS est attendu avec curiosité par de nombreuses personnes depuis les commentaires élogieux que Linus Torvalds en a fait dans son mail d'annonce du noyau précédent:

« J'espère que lors de la prochaine période de merge nous allons pouvoir incorporer le super travail de Nick Piggin sur la montée en charge du VFS. Je l'ai utilisé sur ma propre machine et j'ai passé en revue tous les commits (même si je dois encore vérifier certains trucs) et personnellement je suis vraiment excité par tout ça. C'est rare de voir une amélioration majeure des performances dans le code au coeur de l'OS qui soit si notable. »

Cet espoir d'intégration rapide n'a, hélas, pas pu se réaliser complètement puisque Nick a indiqué que ses patchs n'étaient pas tout à fait assez mûrs pour rejoindre la branche principale :

« Je pense que conceptuellement tout est OK mais il y aura inévitablement quelques bugs qui restent ici et là et des trucs à corriger lors de l'étape de passage en revue. Je ne m'attends pas à découvrir un problème majeur mais je crois honnêtement que viser les noyaux postérieurs au 2.6.36 sera un peu plus sympa pour les gens du VFS. »

Linus a été quelque peu dépité et a même indiqué que les patchs qui sont entrés dans ce noyau cette fois-ci ne sont pas ceux qu'il attendait avec le plus d'impatience :

« Nous n'avons incorporé qu'une petite partie du travail de Nick sur la montée en charge du VFS et, malheureusement, ce n'est pas la partie la plus intéressante. »

En dépit de cette déception relative, Nick a tout de même fait entrer plusieurs patchs d'optimisation VFS pour ce cycle 2.6.36, et nous pouvons donc profiter dès maintenant d'une partie de ses améliorations.
Évidemment, ces patchs, destinés à tirer partie des machines ayant toujours plus de coeurs de calcul, sont très complexes. Comme la couche VFS est elle-même un morceau de code difficile à avaler, on comprendra que le travail de Nick Piggin est plus que délicat à résumer.
L'idée maîtresse est que pour améliorer le fonctionnement sur des machines massivement multi-coeurs, il faut que chaque coeur travaille au maximum dans son coin sans dépendre des ressources des autres (améliorer la "localité" des données). Pour cela, Nick a implémenté de nouveaux verrous spéciaux: lglock et brlock.

Le premier verrou, lglock (pour local-global lock), s'utilise pour avoir un accès rapide et exclusif aux données d'un processeur particulier. Un accès exclusif plus lent est possible pour les données d'un autre processeur et un accès très lent reste disponible si on s'intéresse aux données de tous les CPU à la fois.
Le second verrou, brlock (pour big reader lock), permet d'avoir des accès en lecture exclusifs par CPU (les accès en écriture sont interdits pour tous les autres processeurs). De façon à simplifier le code, Nick Piggin a implémenté techniquement le concept de brlock en se servant uniquement des lglock. Le brlock n'est en fait là qu'en tant que raccourci servant à faciliter le travail des développeurs et à leur éviter d'avoir à écrire tout leur code en utilisant les lglock.

Grâce à ce travail d'infrastructure Nick est parvenu à optimiser le fonctionnement du noyau puisque la fonction files_lock, qui était jusqu'ici un goulet d'étranglement sur les machines multicoeurs, est maintenant remplacée par un lglock. Cette fonction files_lock servait à protéger les accès concurrents sur la liste globale de tous les fichiers ouverts. Maintenant cette liste globale n'existe plus et on a une liste locale par CPU. Sur des machines ayant un grand nombre de coeurs de calcul, la montée en charge est bien plus efficace.
Bien entendu ce travail n'en est qu'à ses débuts et les vrais bénéfices ne se feront sentir que lorsque les autres patchs de Nick (notamment ceux portant sur le RCU pathname lookup) rejoindront la branche principale. Néanmoins les tests montrent que le fonctionnement du VFS est amélioré dès maintenant par ce patch incomplet et que, sur des machines gérant de nombreux CPU, le bénéfice est non négligeable (sans dégradation pour les machines plus modestes).

Tim Chen a conduit une campagne de benchmark sur un système Intel Nehalem à 64 threads effectuant une lourde tâche de compilation et il a obtenu les résultats suivants:

Noyau sans patch => user time :51.25 sec system time :28.25 sec idle time :17.25 sec
Noyau avec patch => user time :53.75 sec system time :18.50 sec idle time :19 sec

Pour effectuer le même travail qu'auparavant le temps CPU passé en espace noyau (system time) est donc significativement réduit, ce qui est révélateur du gain d'efficacité obtenu avec le patch de Nick Piggin. C'est de bon augure pour la suite, et nous attendons avec impatience l'arrivée des patchs complémentaires d'optimisation de la couche VFS.

Attente optimiste sur les mutex

Le patch écrit par Tim Chen, ingénieur Linux chez Intel, et qui permet de corriger les attentes optimistes sur les mutex, a été ajouté au noyau Linux.
Tout est parti d'une technique spéciale qui avait été introduite en juin 2009 dans le noyau. Ce "mécanisme d'attente adaptable", décrit dans la dépêche sur le noyau Linux 2.6.30, est conceptuellement assez clair. Quand une ressource quelconque est utilisée par un processus, celui-ci pose un "verrou" sur cette ressource afin d'être le seul à pouvoir l'utiliser. Ce verrou (nommé mutex pour mutual exclusion) interdit aux autres processus concurrents d'accéder à la ressource. Ces infortunés processus doivent alors "s'endormir" en attendant que la ressource soit libérée.
Les développeurs de la branche temps réel -RT s'étaient rendu compte que les performances pouvaient être améliorées en n'endormant pas tout de suite le processus en attente. Si on le laisse tourner un petit peu, il y a de fortes chances que le premier processus relâche son verrou et qu'on puisse ainsi éviter le coûteux cycle endormissement/réveil et le rechargement des données dans la mémoire cache.
Cette belle idée du "mécanisme d'attente adaptable" avait donc été implémentée dans le noyau 2.6.30 pour la plus grande satisfaction de tous. Depuis ce temps là, les processus attendaient un peu avant de s'endormir quand ils rencontraient un mutex pris par un autre processus.

Mais le temps passe vite dans le monde du noyau Linux. Les ordinateurs ont de plus en plus de coeurs de calcul et les développeurs doivent, dès aujourd'hui, penser à faciliter la montée en charge et à optimiser les performances pour les machines de demain.
C'est cette contrainte qui a conduit Tim Chen à se pencher sur le "mécanisme d'attente adaptable" et à voir si une nouvelle optimisation était possible.
Évidemment quand on travaille chez Intel on a accès à des machines qui sortent un peu de l'ordinaire et Tim a la chance d'effectuer ses tests sur un octo-processeurs Nehalem-EX. Si vous comptez bien cela fait 64 coeurs en tout et 128 threads simultanés !
Avec une telle machine les goulets d'étranglement de Linux deviennent plus visibles et Tim Chen s'est rendu compte que "mécanisme d'attente adaptable" était parfois exagérément optimiste en demandant aux processus d'attendre un peu avant de s'endormir. Quand plusieurs dizaines de processus tournent devant un verrou fermé cela consomme du temps processeur, donc de l'énergie, et cela augmente la compétition sur les ressources de la machine (lock contention).
Certes au bout d'un moment le verrou va être relâché et un processus qui était en attente pourra s'en emparer à son tour...mais les autres continuent d'attendre pour rien !
Comment garder les bénéfices du mécanisme d'attente tout en empêchant trop de processus d'attendre à la porte d'un mutex ?

La solution que Tim Chen a proposé sur la LKML est simple et astucieuse. Quand un processus tourne en attendant que le verrou se libère, il teste rapidement si le propriétaire du verrou a changé depuis la dernière interrogation. Si ce n'est pas le cas (c'est toujours le même processus qui tient le mutex) alors il continue d'attendre un peu dans l'espoir que le mutex va se libérer à brève échéance. En revanche si le propriétaire à changé cela signifie, outre qu'il s'est fait griller par un concurrent, qu'il n'est pas le seul à attendre et qu'il y a compétition pour l'accès au mutex. Dans ce cas il vaut mieux s'endormir tout de suite que de continuer à attendre en vain.

Ce patch est arrivé tard dans le cycle de merge du noyau 2.6.36 mais il est très court, 4 lignes, et les gains en performances sont tellement importants que Linus a accepté de l'inclure dans la RC-3 (troisième version candidate) en dépit de ses promesses de sévérité.
Nous ne pouvons que nous féliciter de cette décision puisque, selon les tests de Tim Chen, son patch de correction des "attentes optimistes sur les mutex" permet de gagner beaucoup en performances (si vous avez une machine avec de nombreux coeurs).
Le test s'est effectué à l'aide du programme spécifique test-mutex d'Ingo Molnar en créant et supprimant des fichiers avec 256 threads en même temps. Les résultats, en nombre d'opérations par seconde, sont les suivants:

2.6.34 sans patch => 62 864 Ops/sec
2.6.34 avec patch => 197 200 Ops/sec

Le benchmark AIM-7 fserver (plus généraliste que test-mutex) a également été utilisé et il exprime un résultat en nombre de jobs par minute:

2.6.34 sans patch => 91 657 Jobs/min
2.6.34 avec patch => 149 325 Jobs/min

Ingo Molnar a été impressionné par ces résultats, mais il a immédiatement demandé si une dégradation était observée sur des machines moins puissantes que celle utilisée par Tim. La réponse a été rassurante puisque sur un ordinateur Westmere à 12 coeurs un gain continue d'être enregistré et que sur un simple Core 2 Duo à quatre coeurs les performances sont indiscernables d'avec celles d'un noyau non patché.
Andrew Morton a exigé que Tim Chen ajoute un commentaire dans son code pour expliquer les raisons de ce changement. Le patch fait donc maintenant 8 lignes en tout et, même avec cette inflation par rapport aux 4 lignes initiales, on peut dire que le ratio lignes de code/gain en performances reste plus que correct !

En bref (↑)

• Arjan van de Ven, auteur de l'outil PowerTOP, a modifié l'interface de gestion dynamique de l'énergie (runtime power management) du noyau 2.6.36. De nouvelles statistiques sont disponibles dans sysfs afin de savoir quels sont les périphériques bons élèves qui utilisent runtime PM, depuis combien de temps le périphérique ne s'est pas endormi ou combien de temps en tout il est resté suspendu. La version 1.13 de PowerTOP exploite déjà ces statistiques mais Arjan a annoncé sur son blog qu'il allait travailler sur des changements radicaux dans le code. Une page de screenshots permet de voir que la quantité d'informations disponibles dans l'outil a beaucoup augmenté pour le plus grand bénéfice des utilisateurs voulant optimiser la consommation de leur machine.
  


• Le support des microprocesseurs Tilera entre dans la branche officielle du noyau Linux. Ces processeurs sont très particuliers puisqu'ils consistent en un ensemble massif de coeurs très simples dont le jeu d'instruction VLIW est basée sur l'architecture MIPS. La technologie est issue des recherches du Docteur Anant Agarwal au MIT qui a ensuite fondé Tilera pour faire fructifier ses travaux. L'innovation réside surtout dans la gestion de la communication de ces ensembles de 36, 64 ou même 100 coeurs. Ils sont reliés entre eux par un réseau utilisant une topologie maillée (mesh topology) et chacun d'entre eux est capable de faire tourner un OS à part entière.
  Jusqu'ici Tilera patchait le noyau Linux pour faire fonctionner ses produits, mais la firme a jugé qu'il serait plus efficace de proposer ses patchs directement sur la LKML afin de réduire sa charge de travail future. Le noyau 2.6.36 n'incorpore que le support des TILEPro et TILE64 ainsi qu'un support préliminaire du protocole réseau. Il est probable que les futures versions du noyau verront l'intégration de patchs supplémentaires venant de Tilera.
  


• En ce qui concerne le travail sur les pilotes graphiques on peut noter que du côté Intel, outre le patch de compression framebuffer qui permet de gagner un peu en consommation, la grande nouvelle est surtout l'intégration de l'infrastructure IPS (Intelligent Power Sharing). Cette entrée officielle dans le noyau est une petite revanche puisque le patch avait été rejeté sans ménagement par Linus lors du cycle précédent car soumis trop tard. Matthew Garrett et Jesse Barnes avaient donc rengainé leur code et cette fois ils ont bien fait attention à proposer l'Intelligent Power Sharing lors de la période officielle de merge.
  Il faut savoir que le fameux mode Turbo d'Intel ne permet d'augmenter automatiquement que la fréquence du CPU. Pour gérer de la même façon le GPU il faut que le pilote graphique soit modifié...et c'est ici qu'entre en scène IPS. Cette infrastructure concerne la gestion thermique des puces Core i3/i5 et permet de surveiller la température et la consommation du package complet (puce Nehalem+coeur graphique Ironlake). Cette surveillance rapprochée autorise Intel, quand le CPU n'est pas trop sollicité, à augmenter la fréquence de fonctionnement du GPU tout en continuant à respecter le TDP (thermal design point).
  


• Le pilote graphique AMD permet maintenant de lire le senseur thermique des dernières générations de puces (rv6xx/rv7xx/evergreen), il améliore ses capacités des reconnaissance des touches spéciales de basculement vidéo qu'on trouve sur certains laptops et il permet également la sortie du son via HDMI sur les cartes RS600, RS690 et RS740. Sur le plan des performances pures, les choses progressent aussi puisque la technique hyperZ est maintenant supportée sur les puces R300 à R500, et le tiling entre dans le pilote pour les puces r6xx/r7xx (voir ce mail d'Alex Deucher).
  


• Le système de fichiers ext3 est revenu à la configuration par défaut data=ordered au lieu du data=writeback qui avait été adoptée en 2009 dans le noyau 2.6.30. L'option data=writeback permet de n'inscrire que les méta-données dans le journal des transactions et pas les données. Cela élimine le temps de latence quand on fait un fsync mais au prix d'un risque accru sur les données. Ce risque a été jugé finalement trop élevé par les développeurs du noyau et data=ordered est à nouveau la configuration par défaut. Cela ne changera pas grand chose pour les utilisateurs puisque les distributions avaient de toute façon presque toutes choisi de rester en mode data=ordered.
  


• L'infrastructure LIRC (Linux Infrared Remote Control) entre enfin dans la branche -staging du noyau. Un grand nombre de distributions utilisaient déjà LIRC dans leurs noyau afin d'assurer le fonctionnement correct des télécommandes infrarouges et cette incorporation dans la branche principale va leur permettre d'économiser le travail de gestion d'un gros patch externe. L'interface LIRC, et les divers pilotes associés qui entrent également dans le noyau 2.6.36, s'occupe de passer les informations sur les trames infrarouges au démon LIRC (lircd) vivant en espace utilisateur et qui va décoder ces trames pour les interpréter et effectuer les actions correspondantes.
  


• Le code du protocole CIFS (Common Internet File System) permettant de dialoguer en réseau avec des machines Windows a été amélioré. L'option de configuration est encore marquée comme expérimentale, mais CIFS_FSCACHE sera sans doute fort utile pour augmenter les performances de vos partages SMB. Techniquement le code de CIFS a été revu pour utiliser l'infrastructure FS-Cache qui était entrée dans le noyau 2.6.30. L'idée est de sacrifier un peu d'espace disque pour interposer une couche qui va servir à mettre en cache les données. Ainsi un accès ultérieur à un fichier sera bien plus rapide puisque les données seront sur un disque dur local et non plus à l'autre bout d'un réseau comparativement très lent.
  


• Du côté du système de fichiers réseau NFS, cela avance également puisque le code du client NFSv4 n'est plus marqué comme expérimental. La fonction, après une longue période de tests divers, a été jugée comme suffisamment mûre et robuste pour qu'on puisse retirer ce tag. Le successeur NFSv4.1, qui promet un bond radical en performances du fait de la parallélisation de l'accès aux données, progresse également dans ce noyau 2.6.36. Le code est encore un peu "jeune" mais il n'est plus strictement réservé aux développeurs. L'option de configuration NFS_V4_1 gagne donc le tag "EXPERIMENTAL" qui est la dernière étape avant l'intégration pleine et entière.
  


• Après la gueulante particulièrement pittoresque de Linus au sujet de SquashFS lors du cycle 2.6.34 on attendait avec curiosité de voir qui aurait le courage de proposer des nouveaux patchs sur ce système de fichiers en lecture seule. Chan Jeong a eu cette audace et il a réussi à faire accepter son option de compression via l'algorithme LZO. Comme ce code permet une décompression plus rapide que l'algorithme deflate utilisé par gzip il est probable que les utilisateurs de LiveCD à base de SquashFS verront un petit bénéfice en temps d'accès. Le véritable gain en capacité pour les LiveCD devra toutefois attendre l'arrivée de l'algorithme LZMA. Le preux chevalier Phillip Lougher est au travail sur cette intégration et peut-être parviendra-il cette fois-ci à terrasser le dragon cracheur de feu qui garde le noyau ?
  


• L'infrastructure DM (Device Mapper) qui sert à mapper les volumes en mode bloc et qui est utilisée par LVM pour la gestion des volumes logiques, a été modifiée dans le noyau 2.6.36. Le code du Device Mapper permet maintenant d'utiliser la fameuse fonction TRIM (discard) qui est si utile pour les disques SSD puiqu'elle leur permet de savoir quels sont les blocs qui ont été effacés. Cette commande discard a été ajoutée aux différentes cibles de l'infrastructure DM (à l'exception de dm-crypt) : Linear, Delay, Stripe, Multipath.
  Si vous utilisez LVM avec des disques SSD, vous pouvez maintenant profiter à 100% de toutes les fonctions de cette couche de gestion des volumes logiques tout en étant certain que les performances de vos disques ne vont pas se dégrader avec le temps.
  


• Vous est-il déjà arrivé d'aller lire le contenu de /proc/net/tcp ? Ce fichier virtuel est utilisé pour permettre de retourner diverses informations au sujet des connexions TCP (TCP sockets table) qui sont actives à un moment donné sur une machine. Évidemment, sur ma machine comme sur la vôtre un petit cat /proc/net/tcp ramène instantanément les informations...mais ce n'est pas le cas pour tout le monde !
  Tom Herbert est ingénieur chez Google et il s'est aperçu que le code générant ce fichier virtuel était très loin d'être optimisé. En fait, ce code effectue des lectures séquentielles et à chacune des lectures, il faut rechercher quelle est la dernière ligne lue et il faut poser un verrou. La complexité de l'algorithme est quadratique en O(n^2) et on voit bien que cette opération devient extrêmement coûteuse quand on a une table de connexions TCP bien garnie comme peuvent en avoir les machines de Google. La solution implémentée par Tom Herbert est simple puisqu'elle consiste à stocker en cache la dernière information lue ce qui évite de scanner toute la table à chaque ligne et permet d'atteindre une complexité linéaire en O(n).
  Les tests démontrent un gain énorme puisqu'un time cat /proc/net/tcp > /dev/null sur une machine ayant 180 000 connexions dans sa table mettait 116,6 secondes avant le patch et ne met plus que 0.8 seconde après application du patch.
  


• La puce Tegra de NVidia est ce qu'on nomme un SoC (System on Chip) et elle est basée sur l'architecture ARM. Il est fort probable que de futurs terminaux Android utilisent ces SoC Tegra, aussi on assiste à un travail d'intégration de leur support dans la branche principale du noyau Linux.
  Les divers patchs d'Erik Gilling et de Colin Cross, tous deux ingénieurs Android chez Google, ajoutent la sous-architecture mach-tegra dans le répertoire /arch/arm qui devient particulièrement pléthorique du fait de la diversité des sous-architectures ARM.
  Bien entendu le support reste incomplet puisqu'il ne concerne que le coeur CPU ARM du Tegra et pas les blocs graphiques ou vidéos.
  


• Dans un registre décidément plus libre, on peut signaler l'intégration des patchs sur le support de la carte SoC JZ4740 qui se trouve au coeur du Ben NanoNote. Ce minuscule ordinateur en architecture MIPS a l'ambition d'être complètement supporté par des pilotes libres et les spécifications matérielles complètes sont également en libre accès. Ce sont ces pilotes qui intègrent la branche principale et qui permettront aux utilisateurs des machines de la société Qi Hardware de profiter encore mieux de leur matériel.
  


• Du côté de la virtualisation, pas de grosses nouveautés à part les habituelles corrections et nettoyages de code. Avi Kivity, le mainteneur de KVM, a quand même indiqué dans son mail d'annonce que le noyau 2.6.36 permettait désormais d'utiliser les commandes spéciales XSAVE/XRSTOR qui font partie des instructions des processeurs Intel destinées à faciliter la gestion des systèmes invités (guest). Ces commandes servent à sauver l'état d'un processeur dans une mémoire spéciale (XSAVE) puis à la restaurer à une étape ultérieure (XRSTOR) ce qui facilite la bascule d'un invité à l'autre.
  Dans le même registre la machine virtuelle KVM a été modifiée pour permettre au guest d'utiliser le nouveau jeu d'instructions vectorielles AVX (Advanced Vector Extensions) qui sera présent dans les processeurs Sandy Bridge d'Intel et Bulldozer d'AMD.
  


• Coccinelle est un projet universitaire d'analyseur statique qui permet, c'est son originalité, d'appliquer des patchs "sémantiques" sur le noyau Linux. Il a déjà permis de refactoriser plus facilement de nombreuses parties du noyau et il a également été utilisé pour corriger divers bugs (voir la liste des contributions). Ces patchs sémantiques sont écrits en SmPL (Semantic patch language) et vous pouvez en lire une excellente présentation par Valerie Aurora dans un article LWN. Avec le noyau 2.6.36 un nouveau répertoire scripts/coccinelle a fait son apparition dans les sources du noyau. Ce répertoire contient actuellement plusieurs scripts effectuant diverses vérifications dans le code du noyau mais il a vocation à en accueillir de nombreux autres. Il suffit d'un simple make coccicheck pour lancer l'analyse et Nicolas Palix explique dans son mail sur la LKML les diverses options de rapport offertes aux utilisateurs de cette nouvelle fonctionnalité.
  


• Le module de sécurité TOMOYO a été modifié pour permettre la modification "à chaud" des politiques de sécurité. Le problème auquel étaient confrontés les utilisateurs de TOMOYO était le suivant : En cas de mise à jour d'un paquet il arrive que certains chemins d'accès changent ou que les dépendances ne soient plus les mêmes, ou encore que les permissions d'accès nécessitent d'être revues. C'est facile à faire sur une machine de test puisqu'on passe TOMOYO en mode "learning" et on corrige la politique de sécurité. Mais avec une machine en production il n'est pas envisageable de sortir du mode "enforce" puisque cela signifierait que la machine n'est plus protégée. À partir du noyau 2.6.36, TOMOYO propose l'option "interactive enforcing mode" qui permet à un administrateur de visualiser les blocages d'accès générés par le système et d'autoriser ou non ces accès afin de mettre à jour en temps réel la politique de sécurité. Une démonstration de cette nouvelle fonction est disponible sous la forme d'une vidéo flash sur le site Youtube.
  


• Le POWER7 est un processeur extrêmement puissant construit par IBM pour ses serveurs haut de gamme et qui sera, dès 2011, au coeur du superordinateur pétaflop Blue Waters. Un POWER7 peut avoir jusqu'à 8 coeurs et chacun de ces coeurs peut faire fonctionner 4 threads (c'est la technique du Simultaneous multithreading). Bien entendu, quand plusieurs threads partagent les ressources d'un seul coeur on ne peut pas obtenir les mêmes performances que si on avait un nombre équivalents de vrais coeurs CPU. Le processeur POWER7 tient compte de cette asymétrie et il peut augmenter les performances d'un thread si celui-ci est le seul à s'exécuter sur le coeur. Le noyau Linux apporte le patch permettant le support automatisé de ces fonctions : Mode SMT1 si on a un seul thread et que les autres sont en idle, mode SMT2 si on a deux threads actifs et deux en idle, mode SMT4 si les 4 threads sont actifs. L'ordonnanceur du noyau a également été modifié pour tenir compte de ces raffinements.
  


• La pile USB du noyau Linux 2.6.36 a reçu un grand nombre de patchs parmi lesquels on peut citer le travail d'Alek Du sur la gestion de l'énergie et celui d'Alan Stern sur l'intégration avec l'infrastructure de runtime power management. La mise en veille automatique d'usb-storage fait d'ailleurs l'objet d'un autre patch d'Alan Stern mais cette fois le support n'est que préliminaire et il est annoncé que l'intégration avec HAL ou DeviceKit est délicate.
  Concernant la norme USB 3.0 (xHCI) la développeuse Sarah Sharp a travaillé sur les performances avec l'intégration de plusieurs patchs. Elle a utilisé l'outil perf du noyau pour trouver les goulets d'étranglements (la fonction xhci_triad_to_transfer_ring() a été corrigée) et ses tests montrent que les performances brutes d'un disque USB 3.0 passent de 186 Mo/s à 195 Mo/s.
  


• La fonction de compactage de la mémoire ramzswap (anciennement compcache) qui était évoquée dans la news du noyau 2.6.33 a été largement améliorée. Alors qu'elle était jusque-là limitée à la compression des pages mémoires dans une zone de swap, le patch de Nitin Gupta autorise désormais la gestion générique des requêtes d'entrée/sortie. En un mot, ramzswap peut jouer le rôle d'un RAM-disque ! Bien sûr, les performances seront un peu moins bonnes qu'un vrai RAM-disque à cause du temps de compression/décompression, mais on gagne beaucoup en capacité.
  Puisque cette fonction n'est plus limitée aux zones de swap, un autre changement de terminologie s'imposait et compcache/ramzswap porte donc désormais le fier nom de zram.
  


• Enfin, last but not least, comment ne pas citer le patch noyau écrit par Pierre Ducroquet (aka Pinaraf sur LinuxFR) et évoqué longuement dans ses deux journaux successifs du 24 juillet et du 17 août.
  Grâce à ce travail, le noyau Linux 2.6.36 permet maintenant le contrôle des diodes des touches multimedia sur divers portables Toshiba. Je vous invite vivement à lire les journaux de Pinaraf qui expliquent en détail sa démarche et la phase d'ingénierie inverse qui a été nécessaire pour comprendre le fonctionnement des touches, écrire le code, puis envoyer le patch sur la LKML.
  Les possesseurs de portables Toshiba, et les libristes en général, lui disent merci !
  

Le bilan en chiffres (↑)

Côté statistiques, l'article récapitulatif pour le 2.6.36 du site LWN est disponible et on pourra également se reporter site remword dédié aux statistiques du noyau Linux pour trouver les chiffres de ce cycle (statistiques du 10 octobre).

En matière de patchs et de nombre de développeurs cette version est complètement typique avec l'intégration de 9 441 patchs écrits par 1174 développeurs (9 771 patches et 1 188 développeurs pour le noyau 2.6.35). Ce qui n'est pas typique du tout c'est le fait que ce nouveau noyau a moins de lignes de code que le précédent ! C'est la toute première fois que cela arrive depuis l'origine des temps (c'est à dire depuis l'import initial dans Git en avril 2005 avec la version 2.6.12-rc2).
Le cycle du 2.6.36 a ajouté 604 000 lignes et en a supprimé 651 000 (ce qui fait donc un allégement de 47 000 lignes). Cela s'explique par le "nettoyage" des fichiers defconfig pour les différentes architectures du noyau (suite à la gueulante de Linus en juin dernier concernant ARM).

Comme Linus l'a souligné dans son mail d'annonce de la RC-4 le nombre de tags "Reported-by:" semble assez faible puisqu'il s'établit sur ce cycle à 284 alors qu'il tournait autour de 400 ou 500 pour les noyaux précédents. Un effort est certainement à faire de ce côté pour reconnaître les contributions des personnes faisant des rapports de bug.

Une question qu'on peut se poser, si on a l'amour du troll chevillé au corps, c'est de savoir si l'intégration d'AppArmor a réussi à booster les statistiques de Canonical lors de ce cycle ?
Il suffit de regarder les scores de cette entreprise en terme de lignes de code modifiées:

Noyau 2.6.30: 75 lignes (position 150 dans le classement)
Noyau 2.6.31: 1 760 lignes (position 65 dans le classement)
Noyau 2.6.32: 8 173 lignes (position 32 dans le classement)
Noyau 2.6.33: 287 lignes (position 106 dans le classement)
Noyau 2.6.34: 5 309 lignes (position 34 dans le classement)
Noyau 2.6.35: 3 338 lignes (position 42 dans le classement)
Noyau 2.6.36: 11 043 lignes (position 16 dans le classement)

Pour le cycle 2.6.36 c'est IBM qui est l'entreprise ayant modifié le plus de lignes (second du classement derrière la catégorie "Hobbyists") avec 157 731 lignes modifiées.
En regardant cette série, on peut noter que le travail de Canonical a été assez important sur le noyau 2.6.32 qui devait être celui retenu pour la version Lucid Lynx LTS. L'intégration d'AppArmor a effectivement réussi à remonter significativement les statistiques sur ce cycle et l'entreprise de Mark Shuttleworth entre pour la première fois dans le Top20.

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

Un noyau sans BKL ?

Le travail d'élimination du verrou global du noyau (BKL) continue à un rythme soutenu et, selon le site LWN, il y a une chance pour que le prochain noyau 2.6.37 puisse être configuré sans BKL pour les utilisateurs aventureux.
C'est le développeur Arnd Bergmann qui conduit cette croisade et le moins que l'on puisse dire, c'est qu'il ne chôme pas ! Regardez plutôt cet ensemble de 31 patchs rien que pour libérer du hideux verrou la couche TTY (mal de tête garanti en allant voir le schéma TTY disponible sur le wiki). D'autres séries de patchs existent pour la couche USB, le VFS ou encore le sous-système vidéo V4L2. La couche graphique DRM est elle aussi presque entièrement débarrassée du BKL (seuls les pilotes antédiluviens i830 et i810 continuent d'avoir besoin du verrou global).
L'appel ioctl() a quant à lui d'ores et déjà été retiré du noyau 2.6.36 et toutes ses occurrences remplacées par unlocked_ioctl() qui ne nécessite pas la pose du verrou global.

Avec tout ce travail déjà incorporé dans le noyau, ou en voie de l'être, les développeurs commencent à apercevoir le bout du tunnel. Il reste encore quelques gros morceaux puisque, par exemple, le démon NFS lockd utilise lui aussi le verrou géant. Une fois les futurs patchs de lockd incorporés les développeurs ajouteront sans doute une option de configuration permettant de compiler un noyau sans BKL. Ce jour-là il sera temps de sortir le champagne !

Aller plus loin

• Les nouveautés du noyau 2.6.36 (105 clics)
• Le bilan des ajouts partie 1 (9 clics)
• Le bilan des ajouts partie 2 (8 clics)
• Le bilan des ajouts partie 3 (6 clics)
• Les prévisions pour l'avenir de Linux (9 clics)