Le noyau Linux est disponible en version 2.6.38

La sortie de la version stable 2.6.38 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 : Merci infiniment aux bonnes âmes qui ont participé à la rédaction collaborative de la dépêche et qui ont ainsi traduit les annonces de RC de Linus.

Sommaire

• La phase de test
  • • RC-1
    • RC-2
    • RC-3
    • RC-4
    • RC-5
    • RC-6
    • RC-7
    • RC-8
• Les nouveautés
  • Transparent Huge Pages
  • Pathname lookup
  • Trusted keys
  • Group scheduling
  • Infrastructure LIO
• En bref
  • • Fitrim
    • Transmit Packet Steering
    • Améliorations de Btrfs
    • Tracing
    • LZMA dans SquashFS
    • Sécurisation du noyau
    • B.A.T.M.A.N
    • Sous-système NFC
    • Device-mapper
    • AES-NI
    • Hole punching
    • Pilote graphique AMD
    • Nouveau
    • Pilote graphique Intel
    • Gestion des médias externes
    • V4L1 passe à la trappe
    • BKL
    • Les ratés du noyau
• Le bilan en chiffres

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 18 janvier :

« Cela fait deux semaines, la période de “merge” pour le 2.6.38 est donc fermée.
Et ça a été une période d'intégration intéressante.

Cette période de “merge” voit l'introduction de deux de mes fonctionnalités préférées :

• l'utilisation de l'ordonnanceur de groupes pour permettre une meilleure interactivité lors de tâches UNIX “traditionnelles” (c-à-d un terminal avec une charge lourde comme un “make -j8” ou similaire) en donnant un groupe à chaque session tty (la variable de configuration “SCHED_AUTOGROUP”) ;

• la nouvelle (enfin, “nouvelle”, c'est en préparation depuis longtemps) recherche de chemin basée sur le mécanisme RCU de Nick Piggin.

La fonction “autogroup” est vraiment plus un gadget technique qu'autre chose, mais il fonctionne vraiment bien pour le genre de choses pour lequel il a été conçu. Si vous faites encore un “véritable travail” dans un terminal, vous l'apprécierez très certainement. Compiler en parallèle dans une fenêtre, regarder un film dans une autre, et la vidéo est vraiment fluide. C'est vraiment palpable dans les faits. Ce n'est pas la panacée, mais c'est agréable.

La recherche de chemin basée sur le mécanisme RCU est à l'autre bout du spectre : l'anti-gadget absolu. C'est du bon travail sérieux qui se débarrasse du dernier gros verrou global qui avait réellement tendance à réduire certaines performances du noyau. Le verrou “dentry” n'est maintenant plus un gros problème de sérialisation. Ce qui est vraiment agréable, à ce propos, c'est que ça améliore aussi beaucoup les performances pour des tâches à simple thread (sur un noyau SMP), parce qu'on débarrasse d'une des parties les plus coûteuses de la recherche de composant du chemin, le “d_lock”, sur tous les composants de la recherche. J'ai pu constater des améliorations de 30 à 50 % sur certaines tâches intensives de recherche de chemin. »

RC-2

La version RC-2 est sortie le 21 janvier avec une perle de langage comme seul Linus sait les faire :

« Ça fait clairement moins d'une semaine, mais je pars pour la LCA
demain, donc j'ai voulu (a) sortir une -rc avant ça et (b) vérifier
que le portable que je vais prendre avec moi est complètement préparé
avec les bonnes clés de signature et tous mes scripts de release, etc..
Donc, si vous voyez quelque chose de bizarre dans la release, braillez,
car je peux encore, avec un peu de chance, corriger les problèmes de script/config que je suis susceptible d'avoir.

En tout cas, la -rc2 est sortie et le seul motif expliquant sa taille si raisonnable c'est que le délai de sortie a été court. Quelques requêtes d'intégration que j'ai eues sont quand même un peu plus invasives que ce que j'aurais souhaité avoir.

Je dois aussi vous prévenir que le portable que j'ai pris avec moi est pitoyablement lent. Je prévois de passer en mode “anal” et de n'intégrer aucune nouvelle branche, sauf si elles ont clairement vocation à faire partie d'une -rc. Autrement dit : n'essayez pas de me faire intégrer de gros patchs. Je ne les prendrai pas et ils peuvent attendre le 2.6.39 (ce n'est pas plus mal, nous avons déjà suffisamment de choses excitantes dans le 38).

Bien entendu, il est parfaitement possible que les choses restent calmes puisque de nombreux autres mainteneurs seront certainement aussi à la LCA ; donc, espérons que l'alerte “Linus passe en mode anal” était totalement superflue. »

RC-3

La version RC-3 a été annoncée le 1^er février, soit 11 jours après la -rc2 en raison de la LCA (linux.conf.au) à Brisbane à laquelle Linus participait :

« À cause de la LCA, la -rc2 était disponible quelques jours en avance et,
pour équilibrer les choses, la -rc3 est en retard de quelques jours. Nous retournons maintenant vers un cycle hebdomadaire, puisque j'en aurai bientôt terminé avec mon voyage (je suis actuellement sur la route du retour - à l'aéroport de Cairns, fuyant le cyclone Yasi).

Rien d'extrêmement spécial dans cette -rc et je suis heureux de dire que la plupart des demandes d'intégration ont été de bonnes corrections de bogues et de régressions clairement identifiées. Merci à la plupart d'entre vous pour ça.

Maintenant récupérez-la et testez-la. Il semble que nous fassions de bonnes choses durant ce cycle de release. »

RC-4

La version RC-4 est sortie, comme prévu, le 7 février :

« Pas de voyage ou d'évitement de cyclone cette fois, donc comme promis, les -rc sont maintenant revenues à un cycle hebdomadaire normal.

Il n'y a rien qui ressort du lot ici. Quelques mises à jour d'archi (ARM et PowerPC), l'habituelle mise à jour des pilotes : DRI (radeon, i915), cartes réseau, son, média, iSCSI, quelques mises à jour de systèmes de fichiers (CIFS, Btrfs), et certains trucs, un peu partout, pour compléter le tout (réseau, “watchpoints”, “tracepoints”, etc.).

Assez petite, pour tout dire. J'aurais préféré évidemment qu'elle soit encore plus petite, et j'ai refusé dans cette -rc une ou deux requêtes d'intégration, mais pour une -rc4 ça n'a rien d'horrible. Tant que ça continue à diminuer, je suis content. »

RC-5

La version RC-5 est sortie le 15 février accompagnée par un message de Linus soulignant le faible nombre de modifications :

« Nouvelle semaine, nouvelle -rc.

Il n'y a pas grand chose à voir cette fois-ci : nous avons corrigé plusieurs régressions (y compris, j'espère, le bug que les développeurs d'Ubuntu ont rencontré et qui était causé par la nouvelle recherche de chemin via RCU) et d'autres choses relativement normales.

La plupart des changements sont courts et seuls les pilotes graphiques (pour Radeon et i915) sortent un peu du rang. Il y a aussi plusieurs déplacements de branches sur la documentation des périphériques qui peuvent paraître importants au regard des patchs habituels, mais ce sont juste des déplacements de fichiers hors du répertoire “powerpc” (puisque globalement la branche de développement sur les périphériques est devenue générique).

Globalement c'est une RC assez réduite.»

Ce que Linus ne précise pas dans son message accompagnant la RC-5, c'est que le faible nombre de patchs s'explique aussi par sa vigilance féroce. Il a l'habitude de scruter les patchs et il n'hésite jamais à hurler en cas de problème.

Prenez par exemple cet e-mail du 11 février dernier et qui concerne de menues corrections dans ext4:

« C'est un patch absolument dégoûtant et il provoque des tas de “warnings”. Ce n'est pas simplement un “oh, un warning !”. C'est plutôt un exemple de “oh, CE CODE EST UNE MERDE TOTALE !”.

Nom de Dieu, ne m'envoyez pas de la merde aussi tard dans le cycle. Clairement, il n'y a eu aucun contrôle qualité. »

Après un mea culpa contrit de Ted Ts'o le patch a finalement été corrigé.

RC-6

La version RC-6 est annoncée le 21 février par cette tirade de Linus au sujet de la clôture d'un bogue épineux :

« Hmm. Une nouvelle semaine, une nouvelle -rc. Celle-ci résout une corruption mémoire assez dérangeante (mais aussi très rare) avec laquelle nous nous battions depuis quelques semaines. Mais puisque je suspecte que seules deux personnes l'ont vu passer, je doute que la majorité d'entre vous en ait quelque chose à faire. C'était cependant un grand soulagement pour moi de voir ce bogue résolu ; je me permets donc de le mentionner. »

Par ailleurs, Linus précise qu'il n'y a pas beaucoup de gros changements à ce stade, ce qui semble le rassurer.

RC-7

La version RC-7 est sortie le 1^er mars, accompagnée du commentaire de Linus :

« Il n'y a là pas grand chose à annoncer. Des mises à jour de pilotes (une ligne par‑ci par‑là, quelques mises à jour de codecs audio pour SoC et d'encore plus petites mises à jour du DRI) et quelques mises à jour de systèmes de fichiers (en particulier le FIEMAP de Btrfs et la gestion d'ENOSPC), mais vraiment toutes petites pour la plupart. Des régressions corrigées, en espérant qu'aucune n'aura été ajoutée. »

RC-8

Enfin, la version RC-8 a été annoncée par Linus le 8 mars :

« J'aurais pu sortir cette version comme le 2.6.38 final, mais je vais être absent quelques jours la semaine prochaine, j'ai pensé que ça n'avait pas beaucoup de sens d'ouvrir la fenêtre de merge maintenant.

En plus, nous avons des régressions. J'espère que quelques-unes sont résolues dans cette RC-8, mais ça ne fera pas de mal d'ajouter une semaine de test. »

Les nouveautés

Transparent Huge Pages

Le nouveau noyau 2.6.38 permet maintenant le support transparent des « huge pages », c'est-à-dire l'utilisation des pages mémoires de grandes tailles par opposition au pages traditionnelles de 4 Kio.

Les processeurs que nous utilisons tous les jours sont dotés d'une unité de gestion mémoire qui leur permet d'établir une correspondance entre les pages de la mémoire physique (RAM) et les pages de la mémoire virtuelle manipulée par le système. Cette table de correspondance, la page table, est hiérarchique avec plusieurs niveaux d'indirections à traverser avant d'obtenir l'information voulue. Pour éviter de perdre du temps à interroger cette table de correspondance et ses multiples niveaux d'indirections, on se sert d'une mémoire cache, le Translation Lookaside Buffer. Cette unité du processeur est importante pour les performances, et les constructeurs rivalisent d'imagination afin d'améliorer le TLB sur leurs puces.

Héritage de l'architecture x86, la taille typique des pages mémoire de la plupart des processeurs est de 4 Kio, ce qui est vraiment insuffisant avec les tailles mémoire des machines modernes.

Intuitivement, on voit bien que plus les pages mémoires sont petites et plus il faudra stocker d'informations dans la table de correspondance entre les pages physiques et les pages virtuelles. Évidemment, cela accroît la pression sur le TLB. Si j'ai un million de pages de 4 Kio, alors je dois « mapper » plus de choses que si je n'ai que quelques milliers de pages de 1 Mio. Dans le premier cas, j'ai de fortes chances de rencontrer un défaut de cache du TLB, alors que dans le second cas, les défauts de cache seront rares.

Encore plus important que la pression sur le TLB, les pages de 4 Kio obligent à traverser les multiples niveaux d'indirection de la « page table » alors que des pages plus grandes permettraient un accès quasi direct.

C'est donc pour résoudre ces deux problèmes que les « huge pages » ont été inventées. Au lieu de se contenter de pages physiques de 4 misérables kilo-octets qui induisent une forte pression sur le TLB et qui nécessitent de traverser de multiples niveaux d'indirections dans la table des pages (page table), on peut, depuis le Pentium Pro, opter pour des pages de 2 Mio ou de 4 Mio.

Pour les plus goulus d'entre vous, les machines x86-64 permettent même d'utiliser des huge pages de 1 Gio, tandis que l'architecture POWER va jusqu'à 16 Gio !
Certaines applications, en particulier les bases de données, profitent pleinement de ces huge pages et peuvent voir leurs performances augmenter de près de 10 %, comme c'est le cas avec Oracle ou DB2. Mel Gorman, dans sa magnifique série explicative sur les huge pages (1 - 2 - 3 - 4 - 5) indique même que certaines applications scientifiques enregistrent des gains de 45 % !

Tout va donc pour le mieux dans le meilleur des mondes et les huge pages sont disponibles pour ceux qui en ont besoin… Mais, il y a toutefois un petit problème. Certes, Linux supporte les huge pages depuis fort longtemps (2003) mais leur support est contraignant et difficile à configurer.

L'outil standard se nomme hugetlbfs et pour utiliser les huge pages il faut typiquement allouer un gros espace mémoire au boot et avoir des applications modifiées pour tirer parti de ce « réservoir » en passant par la fonction « get_huge_pages() ». Ce n'est pas très pratique et cette difficulté d'utilisation a d'ailleurs été soulignée par Mel Gorman à la fin de sa série d'articles :

En dépit du fait que de nombreuses tailles de pages sont disponibles depuis plus d'une décennie, leur support sous Linux a historiquement été délicat à utiliser. Même les administrateurs systèmes doués évitaient de se lancer là-dedans.

L'idéal ce serait que Linux permette l'utilisation complètement transparente des huge pages quand il le peut. Au lieu de devoir modifier péniblement toutes les applications existantes et devoir réserver un gros tampon au démarrage de la machine, il faudrait que le noyau soit suffisamment malin pour utiliser les pages mémoires de grandes tailles automatiquement.

Coup de chance, c'est exactement le but du patch d'Andrea Arcangeli qui a été intégré dans ce noyau 2.6.38 !

Première étape du patch THP (Transparent Huge Page), il faut modifier le noyau pour lui permettre de gérer simultanément plusieurs tailles de pages. Alors qu'avant Linux présupposait que toutes ses pages avaient la même taille dans chaque région de l'espace d'adressage virtuel (les VMA pour Virtual Memory Area), il est maintenant possible de mixer des pages de 4 Kio avec des pages de 2 Mio.

Lors d'une allocation mémoire, et si un espace contigu suffisamment grand est trouvé, le noyau 2.6.38 pourra fusionner plusieurs petites pages dans une seule huge page (coalescing). En cas de nécessité de swap alors le noyau relâchera automatiquement la huge page qui se retransformera en une multitude de petites pages (splitting). Magique !

Pour augmenter les chances de pouvoir allouer des huge pages, il faut avoir ces fameux espaces mémoires non fragmentés disponibles au bon moment. Andrea a trouvé une solution ingénieuse, puisqu'un thread noyau spécifique, nommé « khugepaged », va s'occuper de ce travail en tâche de fond. Dès qu'il trouve un tel espace libre, alors il s'empresse de scanner la mémoire pour remplacer plusieurs petites pages de 4 Kio par une seule huge page.

Le patch actuel n'est pas encore tout à fait complet, puisqu'il ne permet d'exploiter que des huge pages d'une taille de 2 Mio. De plus, il ne fonctionne que sur les pages anonymes, c'est-à-dire celles obtenues à la suite d'un « malloc() ».

En dépit de ces limitations provisoires, les tests ont montré que les performances étaient au rendez-vous. Un gain allant jusqu'à 10 % a été mesuré par Mel Gorman dans ce benchmark. C'est un peu moins bien qu'avec hugetlbfs, mais on gagne énormément en facilité d'utilisation, puisqu'il n'y a rien à faire pour en profiter.
On peut choisir d'activer cette nouvelle fonction en permanence et pour toutes les applications :
text
echo always >/sys/kernel/mm/transparent_hugepage/enabled


Mais il est également possible de n'activer les huge pages que pour certaines zones mémoires spécifiques indiquées par la fonction « madvise() » :
text
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled


Une documentation complète est disponible, qui explique en détail tout le mécanisme du patch THP. Andrea Arcangeli a déjà indiqué qu'il allait continuer à travailler sur son patch, afin de gérer les pages de 4 Mio et 1 Gio, ainsi que la mémoire non-anonyme du cache de page.

Pour nous, simples utilisateurs, le code actuel présent dans le noyau 2.6.38 nous permet déjà de mieux exploiter les unités MMU de nos processeurs et d'augmenter les performances de nos applications.

Pathname lookup

Selon Linus Torvalds la plus importante nouveauté de ce noyau 2.6.38 est le patch de Nick Piggin qui optimise la fonction de résolution de chemin (pathname lookup) de la couche VFS.

Ce code est extrêmement complexe et Linus s'est même senti obligé d'envoyer un e-mail de mise en garde en plein milieu de la période de merge :

Je voudrais juste signaler le fait que j'ai intégré aujourd'hui le patch effrayant (mais très impressionnant) de Nick à propos du pathname lookup.

C'est effrayant parce que c'est du code qui est vraiment au cœur de l'OS, et parce que le nouveau modèle de lookup RCU est vraiment plus intelligent et subtil que le vieux spinlock dentry_lock.

Mais c'est aussi impressionnant et je voulais vraiment intégrer ce patch parce que ses résultats en termes de performance sont étonnants. Par exemple, une recherche de type « find . -size » sur mon répertoire home (ce qui revient à faire des name lookups pour récupérer les stats sur chaque fichier récursivement) devient 35 % plus rapide. Et tout ça dans un contexte « non-threadé » !

Ici, on n'a pas un truc de montée en charge réservée aux machines haut de gamme, il ne s'agit pas de binaires recompilés qui profiteraient d'une nouvelle fonction. C'est juste que le pathname lookup est carrément plus rapide.

Même si la tâche n'est pas facile, essayons donc de décrire ce fameux patch que Linus lui-même trouve « scary ».

Tout d'abord un peu de contexte. Quand un processus en cours doit agir sur un fichier, ce qui arrive assez souvent dans un système UNIX, vous en conviendrez, alors il envoie le chemin (pathname) de ce fichier à la couche VFS pour qu'elle en gère l'accès.

Ainsi, chaque fois qu'est invoqué un appel système de type « open() », « read() » ou encore « rename() », il faut donc utiliser le VFS pour retrouver l'inode du fichier sur lequel on va agir. En effet, c'est l'inode qui, en tant qu'identifiant unique du fichier, va indiquer les droits d'accès et plus généralement toutes les métadonnées associées.

Donc, le problème est clair : nous avons un chemin de fichier (pathname) et il nous faut trouver l'inode correspondant. C'est ce que l'on nomme le problème du « pathname lookup », c'est-à-dire la résolution du chemin.

Comment allons-nous procéder ? Et surtout, comment faire pour que ça aille vite ?

Le code du VFS effectue cette opération en séparant les différentes composantes du chemin. Après tout, quand on voit un chemin comme « /home/patrick/linuxfr/2.6.38.txt », on comprend bien qu'il est possible de le découper en morceaux séparés par « / », puisqu'il s'agit d'une suite hiérarchique de répertoires qui aboutit à un fichier unique.

On pourrait imaginer de parcourir le répertoire racine pour lire sur le disque tous les noms jusqu'à trouver le répertoire suivant, et recommencer ainsi de suite, jusqu'au fichier final. L'ennui, c'est que ce serait très long et qu'il vaut mieux stocker quelque part les relations hiérarchiques qui existent entre les répertoires, ainsi que les correspondances entre les inodes et les noms de fichiers.

La structure qui s'occupe de ça se nomme un « dentry » (pour directory entry) et, outre l'inode du répertoire, elle contient le nom du répertoire parent et les noms des répertoires enfants. Le dentry est donc la structure qui est utilisée pour faire la correspondance tant désirée entre le nom du fichier et son inode.

La fonction du VFS qui s'occupe de la tâche de résolution du chemin se nomme « path_lookup() » et elle va utiliser le dentry pour faire son travail.

Cette fonction s'occupe, en outre, de tous les horribles petits détails techniques à considérer quand on veut arriver au but (la vérification des droits d'accès, le problème des liens symboliques et le risque associé de références circulaires, les points de montage, etc.).

On voit que la notion de dentry est très importante, centrale même, et qu'il faut pouvoir lire les informations contenues le plus vite possible, pour que la résolution du chemin soit la plus véloce possible.

Les dentry sont des structures de données contenues en mémoire et non sur le disque, ce qui permet un accès rapide. Le noyau maintient ainsi un cache de ces dentry (un cache de leurs empreintes) puisqu'il ne peut pas assurer la correspondance complète de la structure du système de fichiers dans la mémoire. Ce cache des dentry (le dcache) doit donc gérer les accès simultanés (on dit « concurrents ») des différents processeurs, et l'on voit bien que le contenu du cache va évoluer en permanence.

Chaque fois qu'une composante d'un chemin n'est pas présente dans le cache des dentry, il faut demander au système de fichiers d'envoyer les informations permettant de le créer. Il y a aussi le cas où le chemin contient une composante qui n'existe pas dans le système de fichiers. Là aussi, on stocke dans le dcache un « dentry négatif », pour éviter de perdre du temps à rechercher ce répertoire ou fichier inexistant lors d'une prochaine recherche.

Donc, si nous résumons ce que nous avons pour le moment :

• pour résoudre les chemins, le noyau se base sur la notion de dentry ;

• ce dentry fait la correspondance entre le nom du fichier qui est présent dans le chemin et l'inode du fichier ;

• afin d'aller le plus vite possible, un cache des dentry est maintenu : le dcache ;

• le dcache est sous la pression permanente des processeurs de la machine, et il faut optimiser son temps d'accès.

La solution simple et lente pour éviter les conflits sur le dcache est de poser un gros verrou dessus. Cela évite les problèmes du type retrait d'un dentry du cache par un processeur, alors qu'un autre processeur en a besoin au même moment. Ce gros verrou, le « dcache_lock », a été la première solution adoptée par Linux.

Depuis les noyaux de développements de la série 2.5.x, les codeurs du noyau ont remplacé dans certains cas le dcache_lock par un mécanisme optimisé. Pour s'assurer qu'un dentry utilisé ne sera pas retiré inopinément, on va poser un spinlock dessus, le d_lock, et l'on va incrémenter un compteur (refcount) le temps d'utiliser ce dentry. L'idée, c'est de ne verrouiller les dentry successifs des composantes du chemin que les uns après les autres, en séquence.

Cet algorithme, nommé « ref-walk », est, bien entendu, plus compliqué que le bon vieux verrou dcache_lock, mais il est aussi plus efficace, puisque le blocage est bien plus fin.

Comme souvent, quand un bond en performance est effectué, on découvre de nouveaux goulets d'étranglement qui étaient masqués par le code antérieur.

Un problème qui subsiste ici, est que l'utilisation permanente des compteurs (refcount) va souvent invalider le contenu de la mémoire cache des processeurs, et va donc limiter fortement les performances sur des machines multiprocesseurs.

C'est ici que commence le travail de Nick Piggin, puisqu'il incorpore un nouvel algorithme, nommé « RCU-walk », qui va permettre de faire sauter le goulet d'étranglement qui existait avec l'algorithme ref-walk. L'opération de « Read-Copy-Update », initiée par l'appel à « rcu_read_lock() », se fait maintenant sur la totalité du chemin, au lieu de s'effectuer sur chacun des composants du chemin. On fait le pari que tous les dentry seront présents dans le dcache, et ce pari est payant la plupart du temps. De cette manière l'opération d'incrémentation du compteur refcount ne se fait plus que sur le dentry final, au lieu d'avoir lieu sur les composants successifs du chemin parcouru.

Quand, par malheur, un dentry n'est pas présent dans le dcache, alors l'algorithme RCU-walk s'efface gracieusement et laisse opérer son prédécesseur ref-walk comme avant. Nick Piggin s'est aussi occupé du cas où un dentry est renommé par un processeur, alors que le chemin est parcouru. Le conflit est évité grâce à l'emploi d'un verrou spécial de type « seqlock ». Ce type de verrou ne bloque pas l'accès, mais permet de détecter qu'il y a eu un changement.

En (très) résumé, le travail de Nick a donc consisté à changer complètement la façon dont travaille le cache des dentry, afin d'optimiser ses performances. Il a également nettoyé tout le code de recherche de chemin d'accès (pathname lookup), en restreignant encore plus l'emploi du verrou dcache_lock qui était encore employé dans certaines zones. On retrouve également un verrou fin, le dcache_lru_lock, qui est posé sur la liste des dentry (LRU) et des changements sur l'interfaçage entre les systèmes de fichiers et le VFS.

On voit donc bien que cette série de patches est très complexe et touche de nombreuses zones de la couche VFS qui est au cœur du noyau. La promesse du travail de Nick Piggin c'est une amélioration des performances de montée en charge dans les opérations sur les fichiers. Par exemple, on peut imaginer que sur un gros serveur Web de nombreux processus tentent d'ouvrir des fichiers en même temps en se gênant les uns les autres. Dans ce cas de figure et dans bien d'autres, il est probable que le noyau 2.6.38 permettra d'améliorer sensiblement les performances.

Trusted keys

Le mécanisme « Trusted and encrypted keys », qui constitue une brique de base renforçant la sécurité et l'intégrité des systèmes GNU/Linux, a été intégré dans le noyau 2.6.38.

Le développeur Mimi Zohar de la firme IBM travaille depuis plusieurs années sur son patch EVM (Extended Verification Module) sans avoir pu le faire intégrer, jusqu'à présent, dans la branche principale du noyau. EVM est une protection cryptographique destinée à vérifier si une modification a eu lieu sur certains fichiers ou exécutables du système. Pour cela, une empreinte (un hash SHA-1) de ces fichiers est stocké dans les attributs étendus (xattr) du système de fichiers.

Linux possède déjà un mécanisme de vérification des fichiers et programmes qui a été intégré dans le noyau 2.6.30. Nommé IMA, pour Integrity Measurement Architecture, ce mécanisme ne permet une vérification efficace que contre les attaques en ligne (online attacks), puisqu'il effectue ses vérifications lors de l'ouverture des fichiers ou lors de l'exécution des programmes. Si un attaquant a un accès physique à la machine, alors il peut contourner la protection en démarrant sur un live-CD et en changeant les attributs étendus (offline attack) avant de redémarrer la machine.

Le mécanisme EVM, proposé par Mimi Zohar, a pour but de corriger cette faiblesse en générant une clé cryptographique qui va servir à signer les empreintes (hashes) des fichiers. Cette clé sera stockée dans le module de sécurité TPM (Trusted Platform Module) qui est un composant cryptographique matériel présent sur la carte mère de la machine.

Si un petit malin ayant accès à la machine s'amuse à la redémarrer après avoir changé les hashs présents dans les attributs étendus, il sera amèrement déçu. Lors du démarrage de la machine, la signature des hashs qui est présente dans le TPM sera vérifiée par la fonction « evm_verifyxattr() », et le résultat indiquera clairement que les hashs ont été modifiés et qu'une tentative d'entourloupe a eu lieu. En représailles, le noyau ne démarrera pas et le petit malin sera bien feinté.

Pour que tout ceci fonctionne bien et qu'aucune faiblesse ne subsiste dans cette gymnastique cryptographique, il faut être certain que la clé maîtresse d'EVM ne sera jamais accessible depuis l'espace utilisateur. Cette objection a été soulevée sur les listes de diffusion, et c'est en partie ce qui explique le blocage d'EVM pour l'intégration dans la branche principale.

Quand on veut faire intégrer un patch en « mainline », il ne sert à rien de se lancer dans des récriminations contre les opposants. Cela ne marche jamais, et il vaut mieux s'atteler à répondre à leurs objections techniques et à proposer des solutions. C'est ce qu'a fait Mimi Zohar en écrivant le patch « Trusted and encrypted keys » qui entre dans ce nouveau noyau 2.6.38.

Pour arriver au but à long terme qui est l'intégration d'EVM dans une prochaine version, il faut donc tout d'abord sécuriser les clés maîtresses. Le patch qui a été retenu ajoute deux nouvelles sortes de clés au trousseau de clés du noyau Linux. La première, la « trusted key », est générée par le TPM et elle est chiffrée avec la clé interne du module « storage root key » RSA 2048 bits, de façon à la protéger (sealing). L'accès à la clé (unsealing) ne se fait que si la configuration complète de la machine n'a pas été modifiée, c'est-à-dire si le BIOS, le chargeur et le système d'exploitation, sont conformes à ce qui a été enregistré au sein du TPM dans son « Platform Configuration Register ».

Bien entendu, une fois que la protection est déverrouillée par un utilisateur légitime, il est possible de changer le PCR pour mettre à jour sa machine.

La seconde sorte de clé, « encrypted key », ne repose pas sur les capacités du TPM, mais est tout simplement chiffrée avec l'algorithme AES présent dans le noyau, ce qui est plus rapide que d'utiliser le TPM et son mode de chiffrage asymétrique à clé publique. Cette encrypted key peut elle-même être chiffrée avec une clé maîtresse qui est souvent une clé de type « trusted ».

L'e-mail envoyé sur la liste de diffusion du noyau donne de nombreux détails au sujet de ces clés et explique comment les utiliser. Une documentation complète du mécanisme d'intégrité du noyau est également disponible.

Avec ces deux nouveaux types de clés protégées (activées par les options « CONFIG_TRUSTED_KEYS » et « CONFIG_ENCRYPTED_KEYS » lors du build), il est possible de tout garder en espace noyau et de ne faire passer aux applications qu'un « blob » complètement opaque (ASCII hexa) qui n'augmentera pas la surface d'attaque. C'est une garantie que le futur système EVM ne sera pas sensible aux éventuels problèmes et défaillances se trouvant en espace utilisateur, et c'est donc un pas de plus vers son inclusion.

Group scheduling

Le patch de group scheduling, qui a tant fait parler de lui à la fin de l'année dernière, a été intégré dans le noyau 2.6.38. Ce patch permet d'améliorer sensiblement l'interactivité dans certains cas particuliers, et il est très attendu par les utilisateurs ayant lu l'article de Phoronix qui a popularisé ce travail.

Depuis la dépèche LinuxFr de Victor en novembre dernier, le code de Mike Galbraith a été quelque peu modifié, mais l'idée générale est toujours la même.

Si l'ordonnanceur du noyau Linux se nomme CFS (Completely Fair Scheduler), c'est bien parce qu'il est vraiment équitable. Il divise strictement le temps de processeur disponible entre tous les processus qui s'exécutent sur la machine. Imaginons que vous lanciez une grosse compilation en mode « -j64 » (c'est-à-dire avec 64 jobs simultanés) et que vous ayez en plus un processus mplayer en train de s'exécuter, car vous regardez un film. L'ordonnanceur CFS va simplement diviser les ressources processeur en 65 morceaux, c'est-à-dire qu'il va choisir d'attribuer une tranche (slice) de temps processeur à mplayer, seulement une fois sur 65. Il y a fort à parier que mplayer ne va pas être content d'avoir si peu de ressources, et qu'avec cette méthode, l'interactivité de votre bureau Linux va souffrir.

L'idée de Mike Galbraith, qui, en fait, lui a été soufflée par Linus, consiste simplement à utiliser la notion de « cgroups » (Control Groups) pour isoler certains processus. De cette façon, l'ordonnanceur CFS affectera équitablement les ressources de calcul entre les cgroups et non pas directement entre les processus. Dans l'exemple évoqué ci-dessus, on aura un cgroup pour les 64 jobs de make et un autre cgroup pour mplayer. Les besoins de votre lecteur vidéo auront bien plus de chance d'être satisfaits, puisque, à chaque attribution d'une nouvelle slice, mplayer aura une chance sur deux d'être le gagnant.

Cela ne veut pas dire qu'il va s'attribuer en permanence 50 % des ressources et ne jamais les relâcher ; c'est juste que chaque fois que mplayer aura besoin d'avoir du temps processeur, il sera servi à égalité avec le cgroup des jobs lancés par make.

À l'origine, le code de regroupement des cgroups se faisait en fonction des « TTY », c'est-à-dire des terminaux virtuels. Depuis le code a évolué et il a été décidé de faire une ségrégation des cgroups en fonction de l'identifiant de session des processus. Ces sessions se lancent classiquement avec l'appel « setsid() » et permettent de définir des groupes de processus. Par exemple, vous pouvez faire un petit « ps axgj » sur votre machine et la colonne « SID » vous indiquera les groupes de sessions qui existent.

L'approche basée sur les TTY fonctionnait bien, mais elle semblait trop limitée puisque, pour la grande majorité des utilisateurs, ce sont les applications graphiques qui comptent et pas les terminaux virtuels. Avec le partage des ressources en fonction de l'ID de session, on a une solution un peu plus générale et donc potentiellement plus utile. Il faut quand même garder à l'esprit que cette nouvelle fonction, accessible via l'option « CONFIG_SCHED_AUTOGROUP », n'est que la configuration de base (et désactivée par défaut, qui plus est). Il est tout à fait possible, comme cela a été suggéré dans le monstro-thread de la LKML, d'effectuer une ségrégation des cgroups selon d'autres critères.

En dépit de toute la publicité qui lui a été accordée sur le web, ce patch de « group scheduling » avec le critère d'ID de session n'est pas d'une utilité transcendante pour les utilisateurs normaux. Certes, Linus aime beaucoup le patch, parce qu'il n'y a rien à configurer (it just works!) et parce que les gains sont réels pour son mode d'utilisation particulier. Ingo Molnar a lui aussi chanté les louanges de ce patch et l'a décrit comme étant :

L'une des plus importantes et des plus visibles améliorations de l'interactivité qui a été incluse dans l'ordonnanceur de Linux.

On peut là-aussi s'interroger sur ce qu'Ingo considère comme une utilisation « typique » de son système d'exploitation :

J'ai essayé quelques charges de travail typiques, comme faire un _build du kernel avec “make -j20” tout en lançant le test hackbench. L'interactivité de Firefox n'a pas été affectée de façon mesurable._

Lennart Poettering de son côté s'est empressé d'intervenir pour répondre à Linus et pour critiquer ce patch. Il propose une approche basée, vous vous en doutez, sur son nouveau démon d'init « systemd » :

Tout ça est complètement inutile pour les utilisateurs normaux. Le noyau porte ton nom, mais cela ne veut pas dire que ta propre utilisation soit typique ou qu'elle soit représentative pour plus qu'une poignée de _hackers comme toi.
J'ai juste préparé un patch pour systemd qui met tous les services et toutes les sessions utilisateur dans leurs propres cgroups. Si on active par défaut cette fonction dans systemd, alors cela voudra dire que les utilisateurs n'auront rien à configurer, parce que les distributions utilisant systemd auront ce comportement par défaut._

Il semble évident que pour généraliser complètement la fonction de « group scheduling » et pour la rendre vraiment utile aux utilisateurs classiques des interfaces graphiques modernes, il faudra en passer par la solution en espace utilisateur prônée par Lennart. En attendant, le noyau 2.6.38 permet déjà de bien s'amuser avec cette nouvelle fonction.

Infrastructure LIO

L'infrastructure de Target iSCSI LIO (Linux-Iscsi.Org) fait son entrée dans le noyau 2.6.38, après une longue compétition qui l'a opposée à son concurrent SCST.

Le protocole iSCSI (Internet Small Computer System Interface) est une norme officielle de l'IETF qui permet d'encapsuler des commandes SCSI pour les faire passer dans un réseau TCP/IP. De cette façon, on peut relier une machine cliente (nommée « initiator ») à un périphérique distant comme un disque SAN (nommé « target »). Cette norme iSCSI est intéressante à utiliser parce qu'elle est moins coûteuse à mettre en œuvre que le Fibre Channel et qu'elle réutilise les réseaux Ethernet classiques.

Dans la plupart des cas, on se sert du code iSCSI présent dans le noyau quand on a besoin d'accéder au disque distant. On agit donc en tant qu'initiateur, et le code qui permet de jouer le rôle de cible (target) ne nous concerne pas vraiment. Néanmoins, dans certaines configurations particulières, il peut être utile d'installer un système GNU/Linux qui jouera le rôle de cible, et le noyau permet aussi cette configuration grâce à l'infrastructure TGT (Linux SCSI target framework) et son option de configuration « CONFIG_SCSI_TGT ».

Cette solution TGT existe depuis des années, mais, vivant en grande partie en espace utilisateur, elle n'est pas sans poser quelques problèmes, notamment en termes de performances. Les développeurs de Linux étaient donc à la recherche d'un remplaçant crédible à intégrer dans le noyau, et ils ont évalué les deux projets les plus prometteurs.

Dans le coin droit du ring, le champion SCST (SCSI target subsystem for Linux) qui propose une multitude de fonctions complexes et un grand nombre de pilotes. Dans le coin gauche, LIO (Linux-Iscsi.Org) qui est plus simple et possède moins de fonctions, mais dont le code est considéré comme un peu plus « propre ».

La bataille a été âpre entre les deux compétiteurs, au point que l'article de LWN qualifie les discussions de « ugly », et les comparaisons plus ou moins biaisées n'ont pas manquées. La tension est d'autant plus grande que les enjeux économiques ne sont pas négligeables. Derrière ces deux solutions, il y a, certes, l'ego des développeurs, mais il y a aussi des entreprises qui voudraient bien que leur code entre dans la branche principale du noyau Linux. Pour SCST, on trouve le développeur Vladislav Bolkhovitin et la société ID7 qui finance les développements, tandis que dans le cas de LIO, c'est le développeur Nicholas Bellinger qui est employé par la société RisingTide Systems.

L'arbitre de cette dispute n'est autre que James Bottomley, le mainteneur du sous‑système SCSI dans le noyau Linux, qui s'est bien gardé d'entrer dans les querelles non techniques qui ont émaillées la saga du choix de la nouvelle infrastructure de Target iSCSI. Finalement, la situation a fini par se décanter au fil des mois et des sommets du noyau et, après une dernière passe de relecture et de nettoyage du code, James Bottomley a annoncé en décembre dernier que LIO allait intégrer la branche principale :

OK, je pense que nous avons atteint le point ou tout a été suffisamment rodé en dehors de la branche principale. Nous pourrons compléter les derniers items de la « todo list » directement sur le code intégré.

Même s'il manque encore quelques fonctions dans LIO qui arriveront plus tard, nous pouvons profiter dès maintenant de cette nouvelle infrastructure moderne de Target iSCSI (voir le graphique) :
- l'architecture est non-bloquante, complètement « multithreadée » et elle profite des unités vectorielles SIMD des processeurs ;
- fonction de « persistent reservations » pour faire de l'isolation (fencing) au cas où un nœud se met à avoir des problèmes ;
- mode d'accès ALUA (Asymmetric Logical Unit Assignment) pour choisir un chemin optimisé et performant vers les baies partagées sur le réseau de stockage ;
- multiplexage des connexions et répartition de charge (MCS) ;
- correction complète des erreurs (ERL0, ERL1 et ERL2) ;
- indépendance complète du média de stockage avec différents « backstores » adaptés.

Malheureusement, comme cela arrive parfois dans le monde très darwinien du développement de Linux, la décision technique prise par un mainteneur de sous‑système n'a pas été appréciée par les promoteurs de l'infrastructure concurrente. Le choix de LIO a fait réagir Vladislav Bolkhovitin qui a immédiatement crié au complot et demandé des explications :

Est-ce que quelqu'un peut expliquer quels sont les avantages de LIO par rapport à SCST ?

LIO est évidemment inférieur, que ce soit en termes techniques (voir la comparaison http://scst.sourceforge.net/comparison.html), ou en termes d'utilisateurs et de taille de la communauté. Les tentatives frénétiques pour essayer de lui donner meilleure allure par rapport à SCST n'ont rien changé. Dans les échanges récents, combien de gens ont voté pour LIO ? Personne. Combien ont voté pour SCST ? Un paquet. Est-ce que des vrais utilisateurs de LIO ont participé aux échanges ? Pas un seul.

Est-ce tout ça ne compte pas pour toi ? Que le code soit le meilleur ne signifie plus rien pour la communauté Linux ?

Ou alors, il y a des raisons secrètes ?

En dépit des accusations de Vladislav (« Undercover games » que j'ai traduit maladroitement mais sans trouver mieux par « raisons secrètes »), James Botomley a pris les choses calmement et a répondu point par point :

voir la comparaison

Pour être honnête, je me fiche des comparaisons point par point sur les fonctions respectives. Chacun des produits a des fonctions spécifiques de niche que l'autre n'a pas. Les fonctions de base sont disponibles dans les deux cas et sont solides.

combien de gens ont voté pour LIO ?

Ce n'est pas une démocratie. Il s'agit de choisir le projet qui est le plus réceptif aux besoins de la communauté et qui est le plus maintenable et facile à adapter. Ces six derniers mois LIO a fait des effors sincères pour répondre aux besoins des utilisateurs, pour nettoyer son code et pour s'adapter aux autres projets qui vont s'interfacer au‑dessus et autour de l'infrastructure. De l'autre côté, tu as passé ton temps à te disputer avec le mainteneur de _sysfs, en expliquant que c'était toi qui avait raison et lui tort._

Bien entendu, comme la personnalité de Vladislav le laissait soupçonner, le leader de SCST n'a pas été convaincu et a continué à protester bruyamment :

James, je suis désolé, mais ta position est absurde. En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur, et pas celui qui promet de devenir le meilleur dans un futur indéterminé.

Pourquoi ne pas comparer toi‑même, au lieu de te reposer sur les mensonges déclarations de « NicholasB » et de ses supporters ? Dans la communauté du noyau, il n'y a qu'une seule personne qui soutient LIO, c'est Christoph Hellwig. Il est autoritaire et les gens n'osent pas le contredire. Mais son avis est aussi biaisé ; il y a plusieurs années, il a préféré TGT au lieu de choisir SCST qui existait déjà.

Évidemment, ces arguments assez paranoïaques n'ont fait que renforcer l'opinion de James Bottomley. Comme cela a été souligné plusieurs fois par Linus Torvalds et par d'autres mainteneurs, ce n'est pas seulement le code qui compte, mais surtout la capacité à travailler au sein de la communauté. C'est ce que lui a expliqué James Bottomley :

En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur.

Exactement ! Tant que le choix s'oriente vers le projet qui est le plus orienté vers la communauté, alors les manques techniques seront comblés. Inversement, il est possible de détruire complètement un projet simplement en s'aliénant la communauté. C'est pour ça que la communauté est plus importante qu'une liste de fonctions supportées.

Des tonnes d'améliorations potentielles du noyau ont échoué à cause de problèmes avec le mainteneur.

Nous avons là une sorte de cas d'école pour analyser le mode de développement très spécifique de Linux.

Tout d'abord, comme le rappelle fermement James Botomley, il ne s'agit pas d'une démocratie ; les décisions des mainteneurs de sous‑systèmes et, en dernière analyse, les décisions de Linus, sont souveraines. Si un des gardiens du noyau vous indique qu'il faut modifier votre code pour qu'il soit accepté, alors il ne sert à rien de pester et de récriminer ; mieux vaut se retrousser les manches, car, en acceptant les remarques des autres, vous prouvez votre bonne volonté et votre intégration dans la communauté.

D'autre part, en acceptant les changements et en assurant la maintenance de votre ensemble de patches pendant des mois, vous donnez une indication que votre code ne sera pas abandonné à son sort après son intégration. Les mainteneurs de Linux ont encore en mémoire le système de fichiers Reiser3 qui a été complètement délaissé par Hans Reiser au profit du futur Reiser4. Ce cuisant souvenir explique le fait qu'ils exigent d'avoir l'assurance d'une maintenabilité correcte, et c'est un facteur très important dans leur choix d'une solution à long terme.

Enfin, cela va sans dire, mais cela ira mieux en le disant, les personnalités « difficiles » et « abrasives », comme Hans Reiser ou Vladislav Bolkhovitin, sont difficilement compatibles avec le mode de développement collaboratif du noyau Linux. Quand on voit des complots partout, quand on refuse d'entendre les critiques et qu'on se dispute en permanence avec tout le monde, il est fort improbable de voir son code intégré dans la branche principale.

En bref

Fitrim

À la fin de la section sur FITRIM dans la dépêche sur le noyau 2.6.37, il était précisé que cette fonction n'était activée que sur le système de fichiers Ext4. Rappelons que FITRIM permet d'informer le système de fichiers des pages qui ont été effacées sur un disque SSD, et cet effacement se fait en mode batch (batch discard) plutôt qu'à la volée pour le TRIM classique (on-the-fly TRIM).

Le nouveau noyau 2.6.38 permet maintenant de profiter des avantages de FITRIM sur les systèmes de fichiers Ext3 et XFS. Attention toutefois, car le lancement d'une passe globale FITRIM peut dégrader les performances et Christoph Hellwig conseille plutôt d'utiliser cette fonction en dehors des périodes d'utilisation normale de la machines (on peut configurer FITRIM au démarrage du sytème par exemple).

Transmit Packet Steering

Après le patch Receive Packet Steering qui était entré dans le noyau 2.6.35, voici maintenant que les hackers de Google ont réussi à faire intégrer leur nouveau patch Transmit Packet Steering.

La première fonction découpait le flot de paquets réseau entrant (receive queue) pour les affecter à des processeurs particuliers, tandis que la nouvelle fonction (patch XPS) fait exactement l'inverse. Elle part d'un CPU spécifique et elle lui affecte une queue de paquets réseaux sortants. Cette affectation se fait par le biais d'un masque CPU pour chaque queue qui est stockée dans « /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus ».

Cette association entre un processeur et une queue d'envoi de paquets permet d'améliorer la « localité » des données et donc de mieux profiter des caches de chacun des processeurs. Tom Herbert a procédé à de nombreux tests, et il a démontré un gain assez sensible d'environ 20 % apporté par ce patch de guidage de transmission des paquets (Transmit Packet Steering).

Test netperf TCP_RR avec carte de type bnx2x sur machine 16 cœurs AMD :

• sans le patch XPS : 996 000 transactions/s avec 100 % d'utilisation des CPU.
• avec le patch XPS : 1 234 000 transactions/s avec 100 % d'utilisation des CPU.

Améliorations de Btrfs

Le système de fichiers Btrfs, qui a vocation à remplacer la série classique des Ext2/3/4, propose de nombreuses fonctions fort sympathiques. Parmi celles-ci, il existe la possibilité de compresser les données à la volée de façon transparente avec l'algorithme « deflate » de la bibliothèque zlib. Le hacker Li Zefan, employé par la société Fujitsu, a écrit un patch qui permet d'utiliser également l'algorithme LZO avec Btrfs. Selon ses tests, ce nouvel algorithme est un peu moins efficace en termes de compression de données, mais il est, en contrepartie, beaucoup plus rapide. Comme nous sommes dans le cas d'une compression à la volée effectuée par le système de fichiers, cet argument de la rapidité est très important à prendre en compte.

Voici, par exemple, les résultats d'une extraction d'une archive tar des sources du noyau sur une partition Btrfs :

• Nocompress : extraction en 66,6 secondes pour une taille finale de 381,21 Mio ;
• Compression zlib : extraction en 94,4 secondes pour une taille finale de 132,36 Mio ;
• Compression LZO : extraction en 70,1 secondes pour une taille finale de 193,80 Mio.

Tracing

L'infrastructure de traçage du noyau continue d'être améliorée, version après version. Cette fois-ci, on trouve la possibilité, développée par notre ami Frédéric Weisbecker, d'utiliser les points de traçage sans être utilisateur privilégié. Cela s'effectue grâce à une macro « TRACE_EVENT_FLAGS() » qui est appliquée aux points de traçage. Actuellement, il n'existe qu'une sorte de drapeau (TRACE_EVENT_FL_CAP_ANY) qui est actif sur les appels système, mais d'autres sont envisageables.

Toujours en ce qui concerne le tracing, on trouve le patch d'Arjan van de Ven qui rend conditionnels les points de traçage. Alors qu'auparavant, un point de traçage était assez binaire (soit actif, soit inactif), il est maintenant possible de le faire travailler seulement si certaines conditions sont remplies. C'est un gros gain en termes de souplesse d'utilisation, mais l'objection qui vient immédiatement à l'esprit, c'est le coût en ressource de ces « IF » qui évaluent la condition. Pour éviter la surcharge (overhead), une nouvelle macro de définition des points de traçage a été créée. « TRACE_EVENT_CONDITION() » s'ajoute ainsi à la macro « TRACE_EVENT() » et elle permet de tester la condition sans que le point de traçage ne déclenche son mécanisme. Si la condition est remplie, alors le travail de traçage sera déclenché, mais si elle n'est pas remplie, ce sera comme si le point n'avait pas été activé du tout.

LZMA dans SquashFS

Le preux chevalier Phillip Lougher, qui avait essuyé un échec cinglant lors du cycle du noyau 2.6.34, a enfin pris sa revanche sur le dragon cracheur de feu.

Phillip avait essayé d'ajouter le support de l'algorithme de compression LZMA dans le système de fichiers SquashFS, mais son patch incorporait tout le code directement dans le header « unlzma_mm.h ». Après le refus horrifié de Linus, la seule solution a été de se remettre au travail et de proposer un patch propre. Le noyau 2.6.38 accueille donc maintenant cette nouvelle possibilité de compression (algorithme XZ) qui est bien plus efficace que le classique gzip. Les développeurs de Fedora ont d'ores et déjà annoncé qu'ils allaient utiliser ce mode par défaut pour leur Live-CD Fedora 15. Une comparaison effectuée avec l'ancien système a montré un gain allant de 8 % (game spin) à 18 % (desktop spin), ce qui permettra de stocker plus de programmes dans l'espace limité du disque.

Sécurisation du noyau

L'effort de sécurisation renforcée du noyau continue avec cette version 2.6.38. Grâce au lobbying incessant de Kees Cook et de Dan Rosenberg plusieurs patchs, qui recouvrent souvent des fonctions présentes dans GRSecurity, ont trouvé leur chemin vers la branche principale.

On peut citer l'affichage des adresses mémoire du noyau qui est maintenant masqué par défaut. Alors qu'avant vous pouviez aller fureter librement dans /proc pour lire ces adresses mémoire, ce qui facilitait les tentatives de prise de contrôle, il vous faudra maintenant la (nouvelle) capacité CAP_SYSLOG pour y accéder. Cette fonction se paramètre via /proc/sys/kernel/kptr_restrict.

Le nouveau noyau propose également un travail d'amélioration de l'option CONFIG_DEBUG_RODATA effectué par Ingo Molnar. Cette option permet de marquer en Read Only certaines pages mémoires du noyau et, avec le noyau 2.6.38, nous bénéficions maintenant d'une protection contre l'exécution sur les données. Le bit NX (No eXecute) est mis pour les sections BSS (Block Started by Symbol) et un second patch protège le chargement des modules noyau en mettant le bit RO/NX sur les données et le bit RO+X sur le code.

Grâce à kptr_restrict, au renforcement de l'option CONFIG_DEBUG_RODATA et à l'ajout de l'option CONFIG_DEBUG_SET_MODULE_RONX le noyau Linux 2.6.38 sera mieux à même de résister aux exploits et les différences qui existent avec GRSecurity vont en se réduisant.

B.A.T.M.A.N

Le protocole de réseau B.A.T.M.A.N (Better Approach To Mobile Adhoc Networking) est un type de réseau ad hoc qui a été intégré à la branche -staging lors du cycle du noyau 2.6.33. Ces réseaux qui s'auto-organisent sont très à la mode en ce moment du fait des menaces qui pèsent sur le contrôle d'Internet dans des pays non démocratiques. Techniquement il n'est pas certain que ces réseaux ad hoc pourront "passer à l'échelle" mais B.A.T.M.A.N est certainement très intéressant sur un plan conceptuel et pour expérimenter des solutions innovantes.

Dans le noyau 2.6.38 ce protocole réseau a été considéré comme suffisament stable pour sortir de la branche -staging et intégrer la pile réseau de la branche principale. Une documentation complète est disponible pour permettre aux utilisateurs d'expérimenter les avantages et les inconvénients de ce type de réseau.

Sous-système NFC

Toujours dans le domaine des réseaux le pilote pn544 écrit par Nokia inaugure le nouveau répertoire drivers/nfc. Ce nouveau sous-système du noyau est destiné à accueillir les pilotes supportant la norme de communication NFC (Near Field Communication). De nombreux téléphones sont équipés de ces puces qui permettent d'échanger des informations à très courte distance par exemple pour effectuer des micro-paiements ou pour échanger des cartes de visites.

Bien entendu on ne peut que se réjouir de l'arrivée dans la branche principale de ce pilote libre pour le contrôleur NXP Semiconductors PN544 qui semble être la puce de référence choisie par Google pour ses smartphones Android.

Device-mapper

Une nouvelle interface permet au device-mapper (la couche qui est en charge de la gestion des volumes logiques) d'accéder au sous-système MD pour faire du RAID 4/5/6. La documentation écrite par Neil Brown explique comment utiliser cette nouvelle fonctionalité. D'autre part les performances de device mapper ont été améliorées par deux patchs de Mikulas Patocka (1 - 2) et les chiffres publiés sont très prometteurs.

Toujours en ce qui concerne le device-mapper on peut noter le patch d'Andi Kleen qui modifie dm-crypt pour permettre l'utilisation de multiples liste de tâches (workqueues). Auparavant il n'y avait qu'une seule workqueue de chiffrage/déchiffrage par mapping dm-crypt et cela constituait un goulet d'étranglement. Avec ce patch il y aura une workqueue par processeur pour permettre de travailler en parallèle et d'augmenter les débits.

Enfin, plus anecdotique, vous pouvez maintenant chiffrer les blocs de votre disque avec des clés différentes. Cette capacité "multi-clés" est utilisé pour permettre un mode spécial de compatibilité avec Loop-AES qui est un patch bien connu vivant en dehors de la branche principale du noyau.

AES-NI

En parlant de l'algorithme de chiffrage symétrique AES le noyau 2.6.38 propose une implémentation améliorée de la fonction AES-NI qui est présente dans les processeurs Intel récents et les futurs AMD Bulldozer.

AES-NI est une extension de l'architecture x86 qui ajoute sept nouvelles instructions permettant d'accélérer considérablement les opérations de chiffrage/déchiffrage de l'algorithme AES. Alors qu'auparavant le support n'existait que pour les x86-64 le nouveau noyau apporte maintenant la compatibilité avec l'architecture traditionnelle x86 32 bits. Evidemment, comme à chaque fois qu'on peut profiter d'une accélération matérielle, le gain en performances est énorme. Le développeur Mathias Krause a posté le résultat de ses tests dm-crypt effectués sur une machine Core i7 M620 tournant à 2.67GHz :

x86 | i586 | aes-ni | delta

------------|-----------|---------|----------

chiffrage ECB | 93.8 Mo/s | 123.3 Mo/s | +31.4%

chiffrage CBC | 84.8 Mo/s | 262.3 Mo/s | +209.3%

chiffrage LRW | 108.6 Mo/s | 222.1 Mo/s | +104.5%

chiffrage XTS | 105.0 Mo/s | 205.5 Mo/s | +95.7%

En plus de ce support des instructions AES-NI pour l'architecture x86-32 le code spécifique x86-64 a été optimisé et le débit des opérations de chiffrage/déchiffrage augmente un peu (voir le tableau des performances dans le message de commit).

Hole punching

Les systèmes de fichiers XFS et OCFS2 possédent une caractéristique intéressante puisqu'il permettent de désallouer un espace se trouvant au beau milieu d'un fichier déjà existant. Cette fonction porte le nom très imagé de "creuser un trou" dans le fichier (punching a hole). Cela parait franchement bizarre de vouloir faire ça mais c'est utile dans certaines configurations virtualisées. Par exemple si le système invité (guest) est alloué globalement sur un espace discontinu alors le fait de désallouer les zones non utilisées au sein du fichier permettra de récupérer facilement de l'espace.

Le développeur Josef Bacik, qui travaille pour Red Hat, a logiquement considéré qu'il n'était pas optimal de trouver cette fonction dans des systèmes de fichiers individuels. Pourquoi ne pas rendre le code plus générique afin que les autres systèmes puissent utiliser cette possibilité ? C'est le rôle du patch qu'il a proposé sur la LKML et qui a été accepté par Linus dans ce cycle 2.6.38. L'idée est simplement d'ajouter un mode FALLOC_FL_PUNCH_HOLE à l'appel système fallocate() qui sert déjà à manipuler l'espace disque des fichiers. Maintenant que cette option est disponible il est fort probable que les systèmes de fichiers Btrfs et Ext4 vont bientôt vous permettre de "creuser des trous" dans les fichiers !

Pilote graphique AMD

En ce qui concerne les cartes graphiques AMD, le noyau 2.6.38 permet la reconnaissance du coeur graphique présent dans les puces "Fusion" (en particulier le processeur Ontario). Du côté des cartes externes on trouve le support de la norme PCI-Express 2.0 dans le pilote Radeon et surtout l'arrivée du support 2D/3D des cartes Radeon "Northern Islands" (ce sont les cartes série 6000 portant les noms de code Barts, Turks et Caicos).

A partir de cette génération de cartes seul le fonctionnement via KMS (Kernel Mode Setting) sera possible et UMS (User-space Mode Setting) n'est plus utilisé. La carte Radeon HD 6970 (Cayman) qui est disponible depuis mi-décembre n'est pas encore supportée par le noyau Linux mais le travail est en cours et on peut s'attendre à la voir arriver dès le prochain cycle.

Nouveau

Le code de Nouveau, qui gère les cartes NVidia, a lui aussi été amélioré dans cette nouvelle version du noyau. On trouve le support des puces "Fermi" nvc0 (c'est à dire les GeForce 400/500). Le noyau 2.6.37 avait juste permis leut détection mais maintenant nous disposons d'une accélération 2D/3D avec un pilote mis à jour. Le point noir c'est que cette accélération dépend encore d'un firmware qui n'est pas présent dans les sources du noyau.

Pour les cartes un peu plus anciennes (c'est à dire la prolifique famille NV50) on trouve une amélioration du code d'allocation mémoire ainsi qu'une meilleure gestion de la mémoire vidéo.

Pilote graphique Intel

Dans le domaine des cartes Intel le noyau 2.6.38 apporte surtout des patchs permettant de mieux contenir la consommation et de gérer plus intelligement l'énergie. Jesse Barnes a indiqué que sur son laptop le patch de rafraichissement mémoire (actif sur les puces Ironlake et Sandybridge) lui permettait d'économiser 0.5W par rapport aux anciens noyaux. On trouve également l'intégration du mode d'économie en sommeil ultra-profond C6 et la possibilité d'overclocker automatiquement le coeur graphique Sandybridge en cas de faible activité du processeur. Enfin Keith Packard, bien connu du monde du développement X.org, est l'auteur d'un patch qui permet de détecter automatiquement les changements d'écran (automatic hotplug detection) sans avoir à lancer de coûteuses interrogations en permanence (polling).

Gestion des médias externes

Puisque nous parlons du polling il est bon d'évoquer le patch de Tejun Heo qui change la façon dont sont gérés les médias externes par le noyau Linux. Jusqu'à maintenant il n'y avait pas le choix et les applications en espace utilisateur devaient faire directment du polling pour savoir si un évènement était intervenu sur un périphérique (insertion ou éjection d'un disques optique ou d'une carte mémoire par exemple). Pour ça le périphérique en question était interrogé par la commande TEST_UNIT_READY mais cette façon de faire pose plusieurs problèmes.

Tout d'abord l'interrogation depuis l'espace utilisateur est une opération lourde et coûteuse et il y aurait avantage à faire le travail directement dans le noyau. Ensuite les pilotes Windows utilisent la commande GET_EVENT_STATUS et le firmware des disques tend a être testé uniquement pour cette commande ce qui pénalise Linux qui passe par TEST_UNIT_READY. Enfin le polling depuis l'espace utilisateur est une opération risquée puisqu'il n'y a pas vraiment de moyen de savoir si l'interrogation ne va pas provoquer un conflit. Tejun signale que le polling durant une session de gravage de données peut provoquer une erreur.

Pour résoudre tous ces problèmes d'un coup il a été décidé d'implémenter le polling des disques directement dans le noyau. L'avantage c'est que ce polling est bien plus léger (plus besoin d'ouvrir le périphérique) et surtout qu'on peut retarder une interrogation pour qu'elle coincide avec un autre évènement pour que le coût soit encore plus dilué.

Tous les pilotes vont devoir être changés et ils utiliseront désormais la fonction check_events() au lieu de la fonction media_changed(). Les "events" qui sont associés à cette nouvelle fonction sont au nombre de deux: DISK_EVENT_MEDIA_CHANGE et DISK_EVENT_EJECT_REQUEST. Il est possible d'indiquer la périodicité de polling en millisecondes dans "block.events_dfl_poll_msecs". Actuellement la valeur est positionné à zéro ce qui signifie que la fonction n'est pas active et que les applications userspace actuelles vont continuer à fonctionner comme avant. C'est maintenant aux développeurs de ces applications de profiter de cette nouvelle fonction pour nous permettre d'économiser des Watts sur nos machines.

V4L1 passe à la trappe

L'infrastructure de gestion V4L2 (Video4Linux seconde génération) est présente dans le noyau depuis la série des 2.5.x. Une émulation était jusqu'à présent proposée pour gérer les périphériques qui utilisaient encore la vieille interface V4L1.

Jugeant que la comédie avait assez duré il a été décidé qu'à partir du noyau 2.6.38 cette API d'émulation serait complètement retirée du noyau. Les applications V4L1 restantes devront soit passer par une bibliothèque en espace utilisateur pour les récalcitrantes, soit être convertie manu militari à l'API V4L2. Quelques pilotes V4L1 sans utilisateurs (cpia, stradis) ont été retirés du noyau 2.6.38. Les pilotes dépréciés ibmcam, konicawc et ultracam ont aussi été supprimés puisque ces derniers sont maintenant supportés par les pilotes GSPCA.

BKL

Le système de fichiers UDF (Universal Disk Format) est utilisé pour écrire des données sur divers média enregistrables de type DVD-R, CD-R, CD-RW, etc. Ce système de fichiers était l'un des derniers sous-systèmes assez importants du noyau à utiliser le verrou global (Big Kernel Lock) mais ce n'est plus le cas à partir de cette version 2.6.38. Un effort de nettoyage a été entrepris et Linus a accepté d'intégrer la branche UDF libérée du BKL.

Le développeur Arnd Bergmann a déjà annoncé son plan à long terme pour en finir complètement avec le BKL même dans les recoins les plus obscurs et poussiéreux du noyau Linux. Certaines sous-parties jugés inutiles seront envoyées vers -staging puis carrément supprimés à partir du noyau 2.6.41. On peut citer appletalk ou hpfs qui sont promis à la disparition à brève échéance. D'autres secteurs de Linux seront nettoyés au karcher de leurs appels intempestifs au verrou géant (Work around in an ugly way, but keep alive). C'est le cas des par exemple d'ufs, du pilote i810 ou encore d'IPX. Enfin un vrai travail de correction approfondi sera entrepris sur certaines parties qui le méritent (norme adfs ou protocole X.25).

Les ratés du noyau

Enfin un dernier point qui n'a pas spécifiquement de rapport avec le noyau 2.6.38. Je voudrais signaler la remarquable présentation de Jon Corbet (éditeur du site LWN) lors des dernières conférences Linux.conf.au et FOSDEM. Certes son accent est un peu difficile à comprendre mais les slides aident bien à la compréhension et puis ça vaut le coup puisque la vidéo est passionnante (lien vers la version FOSDEM). Au lieu de classiquement parler des réussites il a décidé d'évoquer les échecs, parfois retentissants, qui se sont produit lors du développement du noyau. Quels ont été les patchs rejetés, pourquoi ça n'a pas marché et surtout quelles leçons en tirer pour les développements futurs.

Hmm…finalement peut-être que cela à quand même un rapport avec le noyau 2.6.38 (cf la controverse LIO-SCST évoquée plus haut).

Dans cette conférence vous entendrez ainsi parler des systèmes de fichiers Tux3 et Reiser4, de l'ordonnanceur deadline de Con Kolivas et de l'infrastructure de tracing SystemTap. Un véritable cimetière des éléphants des patchs noyau et une mine d'or de bons conseils pour éviter les embûches !

Le bilan en chiffres

En matières de statistiques ce noyau 2.6.38 retrouve des niveaux de contributions typiques par rapport à la déferlante qu'avait été la version précédente. Comme d'habitude L'article de synthèse du site LWN permet de faire le point et on pourra également se reporter site remword dédié aux statistiques du noyau Linux pour trouver les chiffres de ce cycle.

En matière de patchs et de nombre de développeurs cette version est dans la moyenne avec l'intégration de 9 432 patchs écrits par 1 201 développeurs (chiffres du 10 mars).

Red Hat est toujours la première entreprise en terme de patchs avec plus de 11% des contributions (mais derrière la catégorie fourre-tout des "hobbyists" qui ne sont pas payés pour coder le noyau et qui fournissent plus de 15% des patchs). On trouve ensuite Intel, Novell et IBM qui sont des habitués du haut du tableau. Oracle est en douzième position avec 154 patchs et Canonical en vingt-deuxième position avec 101 patchs. Pour les curieux la liste complète des entreprises est disponible sur le site remword. On y trouve même, en cherchant bien en bas de la liste, des noms assez inattendus comme General Electric et Volkswagen ou encore des amis sincères du libre comme Apple et Sony.

Un chiffre toujours intéressant à regarder est celui des primo-contributeurs. Il s'agit des personnes postant un patch pour la toute première fois lors d'un cycle donné et ce depuis le 2.6.12-RC2 (date de l'import initial dans Git en avril 2005). Ces primo-contributeurs sont importants puisqu'ils représentent un apport de sang neuf dans l'écosystème du développement Linux. Bien entendu tous ne continueront pas à proposer des patchs mais certains d'entre eux deviendront sans doute des contributeurs réguliers du noyau.

Voici le tableau des primo-contributeurs sur les 10 derniers cycles:

Noyau 2.6.29 : 279 primo-contributeurs

Noyau 2.6.30 : 256 primo-contributeurs

Noyau 2.6.31 : 275 primo-contributeurs

Noyau 2.6.32 : 292 primo-contributeurs

Noyau 2.6.33 : 276 primo-contributeurs

Noyau 2.6.34 : 248 primo-contributeurs

Noyau 2.6.35 : 300 primo-contributeurs

Noyau 2.6.36 : 269 primo-contributeurs

Noyau 2.6.37 : 319 primo-contributeurs

Noyau 2.6.38 : 289 primo-contributeurs

Comme avec le nombre de patchs on voit que le cycle du 2.6.37 a été un peu exceptionnel avec pas moins de 319 primo-contributeurs. Le noyau 2.6.38 revient à des chiffres plus classiques mais toujours élévés. Très rares, pour ne pas dire inexistants, sont les projets libres qui voient arriver des patchs écrits par plus de 250 nouveaux venus tous les trois mois !

Aller plus loin

• Le bilan des ajouts partie 1 (1349 clics)
• Le bilan des ajouts partie 2 (781 clics)