Sortie du noyau Linux 3.3

Posté par patrick_g (site web personnel) le 19 mars 2012 à 09:51. Édité par baud123, Davy Defaud, detail_pratique, laurent wandrebeck, samo, claudex, gillux, ndv, Benoît, Benoît Sibaud, Nils Ratusznik, Christophe Turbout et NeoX. Modéré par j. Licence CC By‑SA.

Étiquettes :

110

mar.

2012

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

PS. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction: laurent wandrebeck, Christophe Turbout, ndv, detail_pratique, samo, gillux et Benoît.

Sommaire

La phase de test

RC-1

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

Cela fait deux semaines (et un jour), et la 3.3-rc1 est maintenant disponible.
Il y a quelques dépôts que je n'ai volontairement pas fusionnés, et peut-être quelques-uns que j'ai omis par erreur. Les rejets volontaires sont ceux qui me semblaient peu familiers et où je n'avais pas la bande passante pour les vérifier. Les « omis par erreur » sont des choses que j'ai ratées car j'étais trop occupé.
Ce fût une période de merge bien chargée. Néanmoins je ne saurais dire pourquoi je l'ai ressenti ainsi. Côté chiffres, cette période de merge est assez typique.
Ceci dit, la RC-1 est dorénavant disponible, et je décolle tôt pour une fin de semaine bière, ski et poker (pas nécessairement dans cet ordre : « Boire ou skier, il faut choisir »). Je n'aurai pas accès à mes mails.
Donc si vous pensez que votre demande de merge a été ignorée par erreur (ou intentionnellement, mais néanmoins qu'elle n'est pas si effrayante et que vous pensez que je pourrais m'en occuper facilement), vous avez quelques jours pour aiguiser vos arguments.
Et si vous n'avez pas envoyé votre demande de merge en temps et en heure : « Phhhthrthtpt ! ». Inutile d'argumenter.
Quelques statistiques pour ceux qui aiment : 20% de mises-à-jour dans arch (arm, power, mips, x86), 60% de pilotes (réseau – particulièrement sans fil, staging, media, dri, son, divers – y compris se débarrasser de « struct sysdev »), et 20% de modifications diverses (systèmes de fichiers, réseau, perf, etc).

RC-2

Linus a envoyé avec un peu de retard la version RC-2 puisqu'elle n'est apparue que le 31 janvier dernier :

OK, sans véritable raison – excepté le fait que je sois désorganisé et que je n'y ai pas pensé – la rc2 est en retard de plusieurs jours. C'est plus proche des deux semaines que de l'habituelle semaine à laquelle j'essaie de me tenir entre les rc.
Du coup, cette rc2 est un poil plus grosse que ses prédécesseurs historiques, mais c'est simplement dû au retard qui fait que c'est plutôt une rc3. Et dans ce cas, elle correspond bien aux tendances, elle est même un poil petite.
Cependant, en dehors de ce trou de mémoire, il n'y a rien de bien particulier. Les statistiques sont assez communes – la plupart sont des petites modifications réparties un peu partout. C'est cela que j'apprécie, et nous ne voyons pas si souvent cela à un tel point d'avancement. Il y a quelques mouvements du côté des fichiers (port série utilisant un 8250, fusion arm mx5 et imx), mais en dehors de cela rien de bien excitant. C'est bien.
Une chose que j’apprécie, c'est de voir que les messages de demande de merge qui me sont arrivés l'ont été avec des tags signés. J'ai donc décidé d'essayer d'écrire davantage d'explications, y compris pour les merges n'ayant pas eu droit à ce genre d'attention de la part de leurs mainteneurs. Certains (David avec le réseau en est un bon exemple) tendent à écrire de bonnes explications dans leurs requêtes de merge, et j'essaie dorénavant de les incorporer dans mes messages.
Donc faire entendre votre contentement – si vous ça vous semble important – pourrait être une bonne idée afin de me convaincre que l'effort en vaut la peine sur le long terme. Je dois avouer que regarder les logs (qui est une chose que je fais très régulièrement) est ce qui m'a convaincu de m'y mettre, je soupçonne donc que j'essaierai de continuer à le faire même si personne n'y prête attention.
D'autres commentaires à propos de rc2 ? Pas tant que ça. J'ai refusé une ou deux demandes de merge parce qu'elles ne semblaient pas appropriées à ce stade d'avancement, mais je suis bien évidemment ouvert au débat (même si parfois j'ignore tout simplement vos arguments, voire même j'en arrive à vous insulter - ces deux situations étant juste révélatrices de mon humeur du moment).
Dépêchez-vous de tester.

RC-3

Revenant à son rythme habituel, c'est le 9 février que la version RC-3 a été taggée :

Une autre semaine, une autre -rc.
Pas de grosses surprises, ce que j’apprécie. Environ un tiers des modifications se trouvent dans ARM, mais c’est principalement dû au retrait du code inutilisé d’accès direct à la mémoire pour le matériel bcmring. Je ne m’en plains donc pas.
Le reste est assez lisse selon les statistiques (== divers petits changements répartis un peu partout), bien qu’il s'agisse principalement des pilotes. Pas mal de mises à jour du côté son/hda (et associés), quelques mises à jour IB et plates‐formes, etc., etc.

RC-4

La version RC-4 du noyau 3.3 est apparue le 18 février :

Cela devient presque une habitude : à nouveau, une -rc qui est en retard de quelques jours. Cependant, cette fois j'ai une excuse. Enfin, une autre excuse que mon habituel « poursuivez-moi en justice, je ne suis pas organisé et j'ai oublié ».
La raison du retard cette fois est que nous avons passé plusieurs jours à traquer un vilain bug de corruption d'état en virgule flottante qui se produit sur les x86 32 bits – mais seulement si vous disposez d'un processeur moderne (pourquoi utilisez-vous des noyaux 32 bits ?) capable d'exécuter les instructions AES-NI. Vous devez en plus ajouter la prise en charge de ces instructions et avoir un pilote sans fil qui les utilise. La raison la plus probable du bug est l'utilisation de l'infrastructure mac80211 avec WPA et le chiffrement AES (càd habituellement WPA2).
En tout cas, si vous utilisez le réseau sans fil, avez un processeur moderne que vous castrez en utilisant le mode 32 bits, et que vous avez vu d'étranges plantages dûs à la virgule flottante (le symptôme habituel semble être des soucis avec flash dans le navigateur ou la souris dans X se mettant dans un coin ou quelque chose de similaire, ou n'importe quoi d'autre, en fait), cela pourrait être dû à ça.
La solution est de simplement compiler le noyau en 64 bits (hé, vous pouvez laisser les programmes utilisateurs en 32 bits si vous êtes si sentimentalement attaché au siècle passé) ou mettre à jour en 3.3-rc4.
Évidemment, nous rétro-porterons les modifications vers -stable pour les raseurs qui ne veulent pas aider à tester les noyaux de développement. Mais est-ce que ce ne serait pas sympa d'avoir le bogue corrigé tout en sachant que vous aidez le développement en testant les beaux noyaux -rc tout neufs ?
Vous savez que c'est ce que vous voulez.
En tout cas, pendant que je papote à propos du correctif virgule flottante (parce que c'est ce que je faisais), d'autres ont travaillé sur d'autres choses aussi. Ainsi -rc4 propose le retrait du vieux code non maintenu gma500 remplacé par le pilote staging mergé proprement. Ou enlever le vieux code staging de pohmelfs, puisqu'il sera complètement réécrit.
Ou, si les grosses modifications ne vous intéressent pas, il y a diverses mises à jour de pilotes réseau, ecryptfs et XFS, des correctifs ARM, les corrections sur l'utilisation de la pile par sha512, etc., etc. Il y a quelque chose pour presque tout le monde, j'en suis persuadé.
Courrez l'essayer.

RC-5

La version RC-5 est disponible depuis le 25 février :

Hé, ponctuel cette semaine.
Et rien de particulier à signaler. Peut-être les choses sont-elles enfin en train de se calmer.
Évidemment, j'aurais aimé que cela soit encore plus calme, car il y a du mouvement dans diverses zones : mises à jour de btrfs, accompagnées de mises à jours de pilotes scsi et media. Et quelques babioles de-ci et de-là. Mais globalement, c'était assez ennuyeux, juste comme j'aime.
Une paire de correctifs étaient directement liés à mon annonce concernant -rc4, où je disais aux gens qu'ils pouvaient utiliser un noyau 64 bits pour éviter le problème de sauvegarde/restauration de l'état virgule flottante que nous avions. Cela a amené quelques rares problèmes de compatibilité qui pouvaient rendre la solution caduque. Espérons que c'est vraiment bon cette fois.
Maintenant que le problème d'état en virgule flottante est corrigé, si vous avez un processeur 64 bits mais utilisez encore une distribution 32 bits, il serait vraiment intéressant de vérifier qu'un noyau 64 bits fonctionne sans problème pour vous. Parce cela aurait dû toujours être le cas, et cela ne l'a pas été. Il serait très intéressant d'avoir un retour des gens qui ont peut-être essayé et échoué auparavant et qui n'ont peut-être pas pris la peine de faire remonter l'erreur ? Peut-être cela vaut-il le coup d'essayer de nouveau ?

RC-6

La version candidate, la RC-6, a été annoncée par Linus le 4 mars :

Hmm. Rien de particulier à dire à propos de cette -rc : il ne s'agit vraiment que de petits correctifs et de nettoyages.
En fait, cela a été suffisamment calme pour que cela puisse être la dernière -rc, mais nous verrons comment se passera la semaine à venir. Si ça reste paisible (et avec un peu de chance ça s'apaisera encore plus), il n'y aura pas de raison majeure d'allonger davantage le cycle de parution.
Mais bon, cela implique que les gens qui ont repéré des régressions vérifient de nouveau et braillent bruyamment s'ils voient toujours des problèmes.
Donc merci de tester.

RC-7

On peut parier que des braillements ont effectivement été émis puisque Linus a publié une ultime version candidate RC-7 le 10 mars :

J'avais espéré que la rc6 serait la dernière version candidate, mais finalement, pas de chance.
Les choses ne se sont pas suffisamment calmées pour que je me sente assez confiant pour annoncer la version finale 3.3. Donc voilà, la 3.3-rc7 est disponible.
Ceci dit aucune des corrections n'est effrayante en elle-même. C'est juste qu'il y en avait trop et à travers tous les sous-systèmes. Le réseau, la gestion de la mémoire, les pilotes, etc. Au lieu d'avoir moins de changements que dans la rc6, nous en avons eu plus.
Je préférerais vraiment ne pas avoir à faire une rc8. Donc, avec un peu de chance, celle-ci sera vraiment la dernière rc.

Les nouveautés

Deux contrôleurs cgroups de plus

Les contrôleurs « Network Priority » et « TCP buffer limit » ont été intégrés dans le noyau Linux 3.3. Ils permettent à l'administrateur de la machine de limiter les ressources réseaux de façon plus fine qu'auparavant.

L’infrastructure générique des groupes de contrôle (cgroups) a été ajoutée dans le noyau Linux 2.6.24 en janvier 2008. Ce mécanisme cgroups est utilisé, via des contrôleurs spécifiques, pour gérer les ressources disponibles de la machine et pour définir des quotas d’utilisation. Depuis cette inclusion en 2008 on voit régulièrement apparaître de nouveaux contrôleurs dédiés à des ressources différentes dans le noyau (mémoire, temps de CPU, etc.).
Le noyau 3.3 voit ainsi l’inclusion de deux nouveaux contrôleurs qui concernent les ressources réseau.

Le premier se nomme « Network Priority » et il est l'œuvre de Neil Horman.
Ce développeur a décidé de se servir de cgroup pour gérer les priorités de trafic réseau de chacune des applications. Habituellement, la priorité de ces paquets réseau issus des applications peut être manipulée via l'option SO_PRIORITY (voir la page de man de socket) mais, comme Neil l'indique dans la documentation, cette technique pose deux problèmes.

Tout d'abord l'application en question peut ne pas se préoccuper le moins du monde de l'option SO_PRIORITY. Auquel cas, plus moyen de gérer la priorité.
Ensuite, même si l'application a été codée pour permettre de gérer SO_PRIORITY, il est relativement inefficace de gérer les priorités à ce niveau de granularité.
En fait, il serait bien plus utile de définir des politiques de priorité entre divers cgroups et de rattacher simplement les applications à l'un ou à l'autre de ces groupes.

Pour cela, le nouveau contrôleur « Network Priority » intégré dans le noyau 3.3 permet de créer des groupes de contrôle dans le répertoire /sys/fs/cgroup/net_prio et d'y rattacher des processus. Pour définir alors la priorité (paramétrable pour chacune des interfaces réseau), il suffit d'écrire dans le fichier net_prio.ifpriomap de chaque cgroup.
Par exemple, je peux créer le cgroup toto et y rattacher divers processus. Si ensuite je décide que tout le trafic réseau sortant sur l'interface eth0 et généré par ces processus du groupe toto devra avoir une priorité de 6, alors il me suffira de faire :

echo "eth0 6" > /sys/fs/cgroups/net_prio/toto/net_prio.ifpriomap

À noter que le répertoire /sys/fs/cgroup/net_prio contient lui-aussi un fichier net_prio.ifpriomap ce qui permet de fixer une priorité par défaut pour tout le système.
C'est simple et efficace. Une belle démonstration de la puissance de cgroup.

Le second contrôleur qui entre dans ce noyau se nomme « TCP buffer limit » et il concerne également la gestion du réseau.
Ici, l'idée est de gérer la consommation mémoire et de placer des quotas sur cette ressource. Bien entendu, il existe déjà un contrôleur dédié à la gestion de la mémoire (Memory Resource Controller) alors, quelle est la nouveauté ?

Et bien, en fait, « TCP buffer limit » est juste un raffinement du contrôleur de la mémoire qui est déjà présent dans Linux. Ce contrôleur ne gère que la mémoire des processus en espace utilisateur et il ne prend pas en compte la mémoire du noyau qui est très différente (non swappable, pas d’overcommit, etc.). Si cette limitation existe, c’est donc parce qu’il est incomparablement plus facile de poser des quotas et des limites sur la mémoire en espace utilisateur. S’attaquer à la mémoire noyau est un véritable challenge technique et les développeurs avaient donc décidé de ne pas s’en préoccuper dans l’immédiat.

Glauber Costa, qui travaille pour la société Parallels, était d'un autre avis et ses patchs représentent un premier pas vers le but ultime qui est de placer des quotas et des limites sur toute la mémoire noyau.
Ce hacker a eu l'idée astucieuse de réutiliser une partie de l'infrastructure de la pile réseau Linux. Après tout, la pile TCP incorpore déjà une logique qui permet de gérer la taille des tampons mémoire d'accueil des paquets réseau. Quand la pression mémoire est trop grande, alors le noyau fait de son mieux pour éviter tout débordement (il jette des paquets, il refuse d'augmenter la taille des fenêtres de réception TCP, etc.).
Pourquoi ne pas réutiliser tout ça afin de gérer, dans un cgroup, les allocations mémoires des buffers TCP ? Certes, cela ne représente pas toute la mémoire noyau, mais c'est un début.

Bien entendu, ce mécanisme ne doit en aucune façon diminuer les performances pour ceux, nombreux, qui choisiront de ne pas l’utiliser. Glauber s’est d’ailleurs fait violemment taper sur les doigts par David Miller, responsable du code réseau de Linux, parce qu’il n’avait pas assez travaillé sur cet aspect :

À chaque nouvelle version les gens me demandent « Mais ou sont passés mes performances ? » et tout ça à cause de patchs terrifiants comme celui-là. Ce cgroup qui gère les sockets est un exemple parfait qui explique cette situation.
Je deviens vraiment irritable quand les gens me disent « Oh, mais c'est juste un appel de fonction indirect » ou bien « Oh, mais c'est juste un nouveau pointeur dans struct sock ».
Nous travaillons vraiment très dur pour enlever des éléments, pour les rendre plus compacts, pour retirer les opération coûteuses des chemins d'exécution rapides.
Cela peut prendre des semaines ou même des mois pour écrire le code qui va regagner ce qui a été perdu lors de l'inclusion de ce patch.

Après cette diatribe, David a annoncé qu'il refusait purement et simplement l'intégration dans le noyau de ce code et qu'il fallait revoir profondément le concept avant de proposer une nouvelle version.
Glauber Costa ne s'est pas découragé et il s'est attelé à une réécriture complète pour minimiser les impacts en termes de performances. Comme il l'explique dans le message de commit, son nouveau patch utilise la fonction de « jump label », introduite dans le noyau 2.6.37.
Après un passage en revue du code et ayant l'assurance que le surcoût étant vraiment devenu négligeable, David Miller a finalement accepté ce patch réécrit en profondeur.

L'option CONFIG_CGROUP_MEM_RES_CTLR_KMEM permet d'activer ce contrôle de la mémoire noyau mais, comme indiqué plus haut, cela ne gère pour l'instant que la pression mémoire s'exerçant sur le socket TCP.
Le fichier kmem.tcp.usage_in_bytes permet de connaître la quantité de mémoire utilisée par le cgroup tandis que c'est le fichier memory.kmem.tcp.limit_in_bytes qui fixe les limites des tampons mémoire TCP.

Naturalisation du contrôleur mémoire memcg

Toujours en ce qui concerne la gestion de la mémoire via un groupe de contrôle, les patchs de « naturalisation » écrits par Johannes Weiner ont été intégrés dans le noyau 3.3.

Nous avons vu au chapitre précédent que le contrôleur de gestion de la mémoire (Memory Resource Controller) a été amélioré pour prendre en compte les tampons TCP. C’est certainement un ajout bienvenu, mais il faut le reconnaître, ce n’est pas une amélioration radicale de ce contrôleur.
En revanche, avec les patches de « naturalisation » d’Andrew, nous avons là une refonte globale du fonctionnement de ce contrôleur, pour le plus grand bénéfice du noyau.

De nombreux hackers du noyau critiquent depuis longtemps le mécanisme général des groupes de contrôle, car ils estiment que ce code a été greffé dans Linux sans souci d’élégance ou d’intégration. On lit même parfois que ce mécanisme a été simplement boulonné dans le noyau (bolted), comme si c’était le résultat des expériences du docteur Frankenstein !
Ces hackers appellent donc de leurs vœux un travail de refonte générale qui permettrait de fusionner complètement ce code dans l’architecture du noyau.

C'est à une petite partie de cette noble mission que s'est consacrée Johannes Weiner dans sa série de patchs de naturalisation proposés en mai 2011 sur la LKML.
Le terme naturalisation est utilisé parce qu'il s'agit de rendre naturelle l'intégration du contrôleur mémoire memcg. Entre parenthèses, on note qu'il n'est donc pas encore question de la fusion harmonieuse du mécanisme global des « control groups ». Ce travail ne concerne que le contrôleur spécifique dédié à la gestion mémoire.

Alors, en quoi consiste ce travail ?
La gestion de la mémoire dans Linux étant une affaire notoirement complexe, pour comprendre le gain apporté par la version 3.3 du noyau, il est nécessaire de faire un petit aparté sur le fonctionnement des versions antérieures.

En temps normal, le noyau essaie de tirer parti de toute la mémoire qui est disponible sur la machine. Pour cela, il laisse en cache dans cette mémoire toutes les données sur lesquelles il y a déjà eu un accès. Cela accélérera les choses, si jamais il y avait besoin d’accéder à nouveau à ces données.
Le noyau garde deux sortes de listes : celle des pages actives et celle des pages inactives qui n’ont pas été réclamées par un processus depuis un certain temps (le choix se fait à l’aide de l’algorithme LRU pour Least Recently Used).
Quand il est nécessaire de trouver de nouvelles pages mémoires disponibles, le noyau parcourt la liste des pages inactives afin de choisir celles qui devront libérer la place (on parle d’éviction) en étant écrites sur le disque (dans le swap). Linux utilise ainsi l’espace libéré par ces pages pour charger en mémoire vive les nouvelles pages mémoires.

Comme le décrit très bien cet article du site LWN, la situation est encore plus complexe, puisqu’en réalité, cette notion de page active et inactive n’est pas la seule qu’il faut prendre en compte. Il y a aussi les pages anonymes (celles qui sont liées aux processus) et les pages de fichiers (file pages). Chacune de ces catégories maintient elle‐aussi une séparation entre pages actives et inactives.
Si vous avez suivi jusque‐là, on a donc les pages anonymes actives et inactives et les pages de fichiers actives et inactives.
Tout ceci représente quatre listes différentes, mais il faut encore y ajouter les pages qui sont marquées comme ne pouvant être évincées (avec l’appel système mlock()) et qui doivent absolument rester en mémoire vive.

Cet ensemble intimidant de cinq listes est nommé le « global LRU » du noyau, et on comprend qu’à la création du groupe de contrôle, les développeurs du contrôleur mémoire memcg ont pu hésiter au moment de plonger la tête la première dans ce code afin de modifier en profondeur ce « global LRU ».
La solution qui avait été adoptée à l’époque a plutôt été de ne pas toucher au global LRU et d’ajouter simplement des listes supplémentaires spécifiques. Cet ajout s’explique facilement : le « control group » de la mémoire doit gérer des informations supplémentaires pour chaque page mémoire, puisque son travail consiste à réclamer ces pages en fonction des limites fixées dans chaque groupe de contrôle.
Ces informations supplémentaires (page_cgroup) sont placées dans des listes spécifiques qui dupliquent largement les listes classiques (ce que Jonathan Corbet a qualifié de « shadow memory map »).

On comprend bien que cette duplication de listes, ce suivi en double de la mémoire, est une situation sous‐optimale et qu’il fallait revoir profondément ce processus pour mieux intégrer le mécanisme de « control group » dans Linux. C’est ce qu’a annoncé Johannes Weiner dans son courriel de mai 2011 où il présentait son travail :

L’idée à long terme est de ne plus avoir memcg boulonné sur le code de gestion de la mémoire, mais intégré autant que possible, de façon à ce qu’il y ait une gestion native des conteneurs.

L’idée est d’en finir avec la duplication absurde des listes LRU et de tout stocker dans une seule liste LRU par groupe de contrôle.
Le mécanisme d’avant mettait les cinq listes du « global LRU » au centre du jeu et les listes de memcg n’étaient qu’un ajout disgracieux et redondant.
Le noyau 3.3 renverse complètement la perspective puisque le « global LRU » n’existe plus et que la liste du « control group » est maintenant devenue l’objet central. Même un système ayant complètement désactivé memcg verra simplement sa mémoire gérée dans un seul groupe de contrôle qui contiendra toute la mémoire.
Bien entendu, les algorithmes de réclamation de la mémoire ont dû être adaptés à cette refonte du code. Le choix des pages inactives se fait par cgroup et non plus globalement (avec un algorithme de parcours en profondeur pour traverser les groupes). Selon Johannes :

Cela devrait permettre d’avoir un processus de reclaim plus équitable pour les systèmes ayant des memcgs de tailles différentes. La pression devrait également se distribuer de façon proportionnelle entre les memcgs, au lieu d’avoir des reclaims uniquement sur ceux qui ont les pages les plus vieilles à un niveau global.

Outre cette amélioration de l'équité entre les cgroups, les avantages apportés par cette refonte radicale sont de plusieurs ordres. Tout d'abord, et c'est très important, le code est plus simple à comprendre et plus compact (400 lignes en moins par rapport aux noyaux précédents). On sait que Linus Torvalds et Andrew Morton se sont inquiétés à plusieurs reprises de la complexité grandissante du noyau. Il est donc rassurant de constater que des simplifications sont encore possibles sans impact sur les performances.

Autre avantage non négligeable, la surcharge mémoire (overhead) qui était induite par le doublonnage de listes est maintenant éradiquée :

Comme les pages LRU sont maintenant dans une liste unique cela permet d’économiser deux listes de pointeurs pour chaque page dans le système.

Voici les résultats des tests effectuées par Johannes sur une machine ayant 4 Gio de RAM :

Taille du page_cgroup avant le patch = 31 457 280 octets (30 Mio)
Taille du page_cgroup après le patch = 15 728 640 octets (15 Mio)

Bien entendu, c’était une des conditions pour l’intégration des patches, que ces gains en termes de simplicité du code et en termes d’occupation mémoire n’impliquent pas de régressions sur les temps de réclamation de la mémoire. Le message de commit détaille plusieurs bancs d’essai. En voici un exemple parmi d’autres.

Fichier de type « sparse file » de 100 Gio géré dans un cgroup de 1 Gio (pour stresser le code de reclaim) :

Temps avant le patch = 96,84 secondes
Temps après le patch = 94,45 secondes

On voit qu’il n’y a aucune différence significative en termes de performances.

En définitive, tout ce travail de « naturalisation » du contrôleur mémoire memcg est un bon exemple du mode de développement du noyau Linux, qui se base sur les besoins de la communauté des hackers. L’insatisfaction des développeurs envers le caractère peu élégant des groupes de contrôle a joué le rôle d’un aiguillon.
Après l’ajout initial non‐intégré, un travail de fond a donc été accompli pour fusionner harmonieusement cette fonctionnalité memcg dans le noyau. Le code de réclamation de la mémoire a été complètement repensé et les patches ont été postés par Johannes sur la LKML, afin d’obtenir l’assentiment des ses pairs. Après plusieurs mois de tests et de relecture rigoureuse (voir les tags « Reviewed-by » dans Git), ce travail a été finalement intégré dans la branche principale du noyau, et nous pouvons maintenant tous en profiter.

Bien entendu, cette refonte ne concerne que le contrôleur mémoire et pas l'intégralité du mécanisme des groupes de contrôle. S'attaquer à ce chantier ne sera pas facile, mais les développeurs Linux réfléchissent déjà aux options disponibles.

Byte queue limits

La nouvelle infrastructure de « byte queue limits » est entrée dans le nouveau noyau Linux 3.3. Elle vise à combattre les problèmes de latence causés par l'engorgement des paquets réseau.

Tout a commencé avec une alerte lancée en décembre 2010 par Jim Gettys. Pour ceux qui ne connaîtraient pas ce programmeur il s'agit d'un des développeurs originels de l'environnement X Window System au MIT (récipiendaire du USENIX Lifetime Achievement Award) et il a travaillé au W3C en endossant le rôle d'éditeur de la spécification HTTP/1.1 auprès de l'Internet Engineering Task Force. Autrement dit, c'est quelqu'un qu'on écoute quand il signale un problème !

Il y a quelques années, alors qu'il était chercheur dans les Bell Labs d'Alcatel-Lucent, Jim Gettys a découvert un problème d'engorgement réseau d'un nouveau type qu'il a nommé « bufferbloat ». Selon ses tests, le fait d'avoir des tampons mémoires (buffer) de taille excessive conduit à une latence généralisée dans les réseaux. Ce problème est resté inaperçu lors des phases de conception des différentes architectures réseau et la baisse du coût de la mémoire n'a fait que l'aggraver, puisque les ingénieurs ajoutent des tampons mémoire à tire-larigot sans penser aux conséquences.
Tout cela vient du fait que les protocoles se basent sur l'idée qu'une congestion va être détectée automatiquement parce que les paquets réseaux ne seront plus traités. Les algorithmes de gestion de la congestion se servent de ce nombre de paquets perdus (dropped) et c'est comme ça que le réseau s'auto-régule en signalant aux divers émetteurs que le lien est saturé et qu'il faut réduire le débit d'envoi de paquets.
Dans le monde réel, le chemin que parcourt un paquet réseau d'un point A vers un point B est bourré de tampons mémoires en cascade à toutes les étapes. On en trouve dans les piles réseaux des OS, dans les pilotes réseaux eux-mêmes et dans tous les routeurs et serveurs intermédiaires sur le chemin. Et puis, toujours à cause du prix ridicule de la RAM, la situation tend à s'aggraver et les systèmes d'exploitation sont conçus pour gérer des tampons réseaux de plus en plus démesurés.
La conséquence, c'est que l'abandon des paquets en cas de saturation (packet dropping) ne se fait plus immédiatement. Il faut d'abord que le tampon se vide avant que le mécanisme de rétroaction s'enclenche et ce délai perturbe les algorithmes de gestion de la congestion :

Les algorithmes de gestion de la congestion dépendent de l'abandon des paquets réseau juste au bon moment. Le fait d'avoir des tampons saturés invalide ce présupposé architectural.

Après avoir découvert ce mécanisme diabolique d'amplification des latences, Jim Gettys a décidé de partir à l'assaut, flamberge au vent, et il consacre désormais tout son temps à informer les gens et à tenter de trouver des solutions. Cela s'est traduit par une masse impressionnante de posts sur son blog (voir, entre autres, 1 - 2 - 3 - 4), d'articles officiels (celui d'ACMQueue et aussi celui d'IEEE Internet Computing), de conférences, d'entretiens, d'entretiens croisés avec des sommités (voir la discussion avec Vinton Cerf). Un site web spécifique a été mis en place, des vidéos démontrant le problème ont été réalisées.
Cette débauche d'énergie est nécessaire parce que le problème est grave, parce que les algorithmes qui existent, comme RED, ne sont pas efficaces et surtout parce qu'il faudra la coopération de tous les acteurs pour le résoudre. Comme chaque relais sur un chemin réseau est susceptible d'aggraver la latence, il faudra corriger les différentes couches de traitement de tous les systèmes d'exploitation de tous ces routeurs et serveurs !

La solution qui a été retenue pour Linux est un nouveau mécanisme de « byte queue limits ». Comme son nom l'indique, il s'agit de gérer une queue réseau en se basant sur la taille en octet (byte) plutôt que de se baser sur le nombre de paquets.
Évidemment, on ne pouvait pas vraiment se passer de la mise en tampon du flux réseau dans une queue d'attente. Si les développeurs avaient fait ça, le remède aurait été pire que le mal et les performances se serait effondrées car il y aurait eu pénurie de données à traiter (starvation). Les développeurs ont donc choisi d'avoir une queue d'attente dynamique en fonction de la charge de la machine. Cette infrastructure se compose de deux modules :

La bibliothèque DQL (Dynamic Queue Limits) qui gère le caractère adaptatif d'une queue d'attente. Il s'agit d'un mécanisme très générique qui n'est pas spécialement dédié au réseau.
Le mécanisme BQL (Byte Queue Limits) qui s'appuie sur la bibliothèque DQL pour implémenter la gestion dynamique du flux réseau en fonction de la taille mémoire.

Tom Herbert, l'ingénieur Google à l'origine de ces patchs, s'est aperçu qu'il était bien plus facile d'estimer le temps de vidage d'un tampon si on se basait sur la taille mémoire plutôt que sur le nombre de paquets :

The amount of queuing required to prevent starvation of the transmitter is much more dependent on the serialization time of the bytes as opposed to the number of packets being transmitted.

Ce mécanisme dynamique est réglé de façon à ce que le tampon ne contienne que le strict minimum de données pour éviter la pénurie. Si une situation de famine (starvation) est détectée, alors c'est que le tampon de gestion était trop petit et il est donc agrandi. En revanche, si le nombre d'octets du tampon ne descend jamais sous une certaine limite, alors cela veut dire qu'il est possible de diminuer le tampon d'autant.
Ainsi, on conserve les performances tout en réduisant au maximum les latences de type « bufferbloat ».

Tom Herbert a effectué de nombreux tests qui sont résumés dans son message sur la liste de diffusion linux-netdev. Voici par exemple les résultats d'un test netperf ayant lancé 100 flux TCP_STREAM pour saturer le lien et un flux TCP_RR en haute priorité.

Sans BQL: 453-454 Ko dans la queue et 234 transactions par seconde pour le test TCP_RR.
Avec BQL: 66 Ko dans la queue et 914 transactions par seconde pour le test TCP_RR.

Avec cette infrastructure de « byte queue limits », le noyau Linux 3.3 semble donc bien armé pour combattre la redoutable hydre découverte par Jim Gettys et qui hante nos réseaux. Toutefois, il serait dangereux de crier victoire trop tôt et il faut bien rester conscient des problèmes qui subsistent.
Tout d'abord, cette infrastructure est toute nouvelle et, en dépit des benchmarks, il faudra vérifier sur le terrain qu'elle est effectivement capable de réduire les latences. Le problème des réseaux sans fil 802.11 est particulièrement complexe, avec son partage de bande passante entre différents acteurs, et il est probable qu'il faudra encore travailler pour résoudre complètement le problème.

Ensuite, il faut bien voir que ce mécanisme DQL/BQL constitue un changement dans l'API des pilotes réseau Linux et que cela signifie qu'il faudra adapter tous ces pilotes pour qu'ils puissent exploiter cette infrastructure. Certes, dans le monde du logiciel libre, et avec les pilotes incorporés nativement dans le noyau, ce n'est pas un très gros inconvénient… mais il faudra faire ce travail !
Pour l'instant, seuls les pilotes bnx2x, forcedeth, e1000e, tg3 et sfc ont été adaptés.

Enfin, problème bien plus grave, le mécanisme développé par les hackers Linux ne concerne que notre noyau préféré !
Certes, une solution adaptée aux routeurs personnels est en cours de construction (Cerowrt) mais quid de toutes les autres machines présentes sur Internet ? Puisque tous les systèmes d’exploitation, tous les routeurs et tous les serveurs sont à modifier, il faudra une coopération globale des constructeurs, des communautés développant les autres OS libres et aussi des éditeurs commerciaux d’OS (Cisco, Microsoft, Apple, Oracle, etc.).
Dans l’entretien entre Jim Gettys et Vinton Cerf, ce dernier évoque une situation qui s’apparente au dilemme du prisonnier :

Tant que tout le monde ne coopère pas pour réduire les tampons mémoires partout où ils se trouvent, alors la bonne stratégie est, pour chaque constructeur, d'accroître la taille de ses tampons. Vous pouvez rendre plus rapide votre routeur WiFi en lui ajoutant de la mémoire tampon.

Si Vinton Cerf à raison et que chacun des acteurs trouve un intérêt égoïste à accroître encore plus la taille des buffers de ses machines pour avoir des performances supérieures, alors on peut vraiment s'inquiéter du « bufferbloat ».
La coopération et le sens de l'intérêt général pourront-ils s'opposer à cette tendance ?

DMA Buffer

Après plusieurs itérations et réécritures, le mécanisme de « DMA buffer » a finalement été intégré dans le noyau 3.3.
Il s'agit d'offrir la possibilité aux divers pilotes de périphériques de partager directement entre eux leurs tampons mémoires DMA (Direct Memory Access).
Cela n'a l'air de rien mais en réalité il est très intéressant de permettre ainsi aux périphériques de partager leurs buffers. Cet article du site LWN cite l'exemple d'un périphérique d'acquisition vidéo qui génère plusieurs images qui sont ensuite partagées directement avec un circuit d'encodage (pour compression) puis avec la carte graphique (pour affichage), sans qu'à aucun moment les données ne soient dupliquées à un autre endroit.

Le patch a été écrit par Sumit Semwal, après un travail intitial de Marek Szyprowski. Cette fonction s'active lors du build avec l'option DMA_SHARED_BUFFER et elle repose sur la notion « d'exportateurs » et « d'utilisateurs ».
Cette terminologie est utilisée quand un pilote de périphérique veut utiliser les buffers créés par un autre pilote. Dans ce cas, le premier sera l'utilisateur et le second sera l'exportateur qui permettra l'accès à sa mémoire via l'API de dma_buf. Après la première phase d'annonce de l'exportateur (dma_buf_export), un descripteur de fichier (dma_buf_fd) sera renvoyé au pilote utilisateur et lui permettra d'enchaîner les phases de connexion (dma_buf_attachment), d'utilisation (map_dma_buf) et de déconnexion (dma_buf_detach).
Toute cette gymnastique est bien expliquée dans la documentation écrite par Sumit.

Pour l'instant, aucun pilote n'a encore été converti dans le noyau 3.3 pour profiter de ce mécanisme générique de partage des tampons DMA. On peut toutefois parier que les futurs versions du noyau verront une utilisation intensive de cette possibilité. Les constructeurs de System On Chip ARM ont le vent en poupe et ce mécanisme de « DMA buffer » va leur faciliter le travail pour faire communiquer les divers pilotes. D'ailleurs, le consortium Linaro est impliqué dans ce travail.
On peut également penser aux systèmes ayant plusieurs cartes graphiques et qui bénéficieront de cette nouvelle possibilité.

À ce sujet il faut noter qu'une petite empoignade a eu lieu sur la liste de diffusion du noyau. Les fonctions de dma_buf sont exportées vers les pilotes en étant marquées avec EXPORT_SYMBOL_GPL. Cela signifie que seuls les pilotes sous licence GPL peuvent s'interfacer avec ce mécanisme et que les pilotes binaires sont interdits de séjour.
Robert Morell, un développeur travaillant pour NVidia, a envoyé un mail pour demander qu'on change ce marquage et que les fonctions de dma_buf soient simplement exportées avec EXPORT_SYMBOL (ce qui autorise l'interfaçage des pilotes binaires). Selon lui, le mécanisme dma_buf a été introduit pour permettre l'unification des différents systèmes de gestion de la mémoire utilisés dans les SoCs ARM. Restreindre ainsi l'utilisation de dma_buf aux pilotes GPL ne permettra pas de satisfaire cette ambition unificatrice :

Ce serait regrettable si cette restriction aux modules sous licence GPL devait limiter l'adoption de dma-buf.

Le représentant de NVidia ne s'est pas contenté de son mail et il a envoyé sur la LKML un patch convertissant les marquages des fonctions.
Bien entendu, un tel patch a été reçu assez fraîchement par les développeurs Linux. Les messages indiquant « NAK » (refus du patch) se sont multipliés (voir les mails d'Arnd Bergmann ou de Mauro Carvalho Chehab). Sur les conseils de son avocat et pour faciliter de futures actions en justice, Alan Cox a même réitéré ses déclarations indiquant qu'il refusait que son code soit couplé avec des binaires non libres. Enfin, Pekka Enberg a ironiquement proposé à NVidia de libérer son pilote ce qui leur permettrait d'avoir un accès instantané à toutes les fonctions couvertes par EXPORT_SYMBOL_GPL !

Robert Morell ne s'est pas laissé décourager par cette levée de boucliers. Il a d'abord expliqué pourquoi le pilote graphique NVidia ne pouvait pas être ouvert et intégré au noyau Linux:

Le pilote binaire de NVidia est la meilleure solution que nous ayons pour supporter tous nos utilisateurs avec un ensemble de fonctionnalités compatibles entre tous les systèmes d'exploitations. Pour des raisons techniques, nous avons choisi de tirer parti de tout le code générique qui a été écrit en interne. Cela nous permet d'offrir un support pour les nouveaux matériels bien plus rapidement que si nous devions travailler sur des pilotes Linux/FreeBSD/Solaris écrits spécifiquement.

Il a ensuite développé son argumentation en expliquant quels seraient les bénéfices potentiels de son patch retirant tous les EXPORT_SYMBOL_GPL:

Cela permettrait de couvrir le cas d'utilisation des portables Optimus avec une carte graphique Intel intégrée et un GPU NVidia. Nous utiliserions l'interface dma-buf lors des interactions avec le périphérique Intel.
Ce genre de matériel hybride va devenir de plus en plus commun. Par exemple, dans le futur, si nous ne pouvons pas nous mettre d'accord sur l'utilisation de EXPORT_SYMBOL, alors si quelqu'un sort un laptop ayant un GPU Tegra utilisant un pilote Linux sous GPL, et un GPU Geforce fonctionnant avec notre pilote binaire, nous serons forcés soit de réimplementer un mécanisme libre de gestion des buffers pour Tegra qui pourra être utilisé entre les deux cartes, soit de continuer à utiliser notre code actuel nvhost.
Ce genre de prolifération, avec toutes les différentes versions de SoCs, est précisément ce que le projet dma-buf devait remplacer.

Rob Clark, un développeur Linaro, a soutenu cette position et à même annoncé qu'il était arrivé à cette conclusion à la suite du du sommet ELC (Embedded Linux Conference) :

Nous avons discuté de ce sujet lors de la réunion kernel-gfx à ELC. À la suite de cette discussion, je dois reconnaître que dma-buf a été conçu comme une interface entre les divers pilotes des sous-systèmes. Et parce que (pour le moment) toutes les autres piles graphiques des SoCs ARM impliquent des programmes non libres en espace utilisateur, je ne pense pas que nous puissions arguer d'une supériorité morale dans ce domaine. Donc, je ne peux pas m'opposer au passage vers EXPORT_SYMBOL au lieu de EXPORT_SYMBOL_GPL.
Ceci dit, je m'attends à ce que l'infrastructure dma-buf continue d'évoluer et ce sera de la responsabilité des pilotes non présents dans le noyau (GPL ou pas) que de s'adapter à ces changements d'API.

En dépit de ce soutien apporté à la position de Robert Morell, le code de dma_buf n'a pas été modifié dans cette version 3.3 du noyau et les fonctions sont toujours marquées avec EXPORT_SYMBOL_GPL.
Dans les mois qui viennent, les discussions vont sans doute continuer sur la LKML et il sera intéressant de voir qui aura le dernier mot.

PAE pour ARM et mode de développement du noyau

Les nouvelles générations de processeur ARM sont sur le point de sortir et elles proposent une fonction controversée de gestion de la mémoire. La prise en charge de cette fonction dans le noyau 3.3 va nous donner l'occasion de nous pencher sur le mode de développement pragmatique qui est utilisé dans le monde Linux. Vous découvrirez que, loin d'être un dictateur inflexible, Linus lui-même peut céder devant les demandes de la communauté.

Annoncés en septembre 2010, le puissant Cortex-A15 et l'économe Cortex-A7 ont la possibilité d'utiliser la technique d'Extension d'Adresse Physique (PAE).
Un processeur 32 bits permet normalement de mapper une mémoire physique d'une taille limitée à 2³² valeurs soit 4 Go de mémoire. Le mécanisme PAE, utilisé depuis longtemps dans le monde x86, permet de contourner cette limitation et autorise un processeur 32 bits à gérer des tailles mémoires supérieures à ces 4 Go. Pour cela, les processeurs ont un espace d'adresse physique supérieur à 32 bits, par exemple 40 bits pour les nouveaux ARM Cortex, tandis que le système d'exploitation continue de gérer un espace mémoire virtuel de 32 bits (via la page table).
De cette façon, les applications sont bernées, elles tournent individuellement dans leur espace d'adressage normal limité à 4 Go, mais l'OS peut adresser une bien plus grande quantité de mémoire.

Il faut bien le reconnaître, ce tour de passe-passe est techniquement fort douteux. Certes, il a pu être utile quand les puces 64 bits n'étaient pas disponibles mais, à l'heure actuelle, son utilisation fait froncer les sourcils des hackers du noyau. En cas de besoin de grandes tailles mémoires, il est bien plus propre et plus rationnel d'utiliser nativement un processeur 64 bits.
Linus Torvalds n'étant pas homme à se limiter au fronçage de sourcils nous avons eu droit, en 2007, à l'une de ses furieuses diatribes contre le mécanisme de PAE. J'en extrais ici la substantifique moelle, mais vous êtes invités à lire l'intégralité du brûlot sur cette page:

PAE c'est vraiment, vraiment pourri.
La raison principale pour utiliser un processeur 64 bits c'est l'espace d'adressage physique. Il est nécessaire d'avoir un espace d'adressage virtuel plusieurs fois plus grand que l'espace physique.
PAE a inversé ce simple fait et a royalement foutu la merde. Celui qui a inventé cette idée était totalement incompétent et avait oublié tous les problèmes de HIGHMEM DOS. Il y avait une putain de bonne raison pour que nous laissions tomber les 286 et que nous passions aux 386, plutôt que d'avoir cette saleté de HIGHMEM avec ces petites fenêtres virtuelles au sein d'un espace physique plus grand.
Répétez après moi : l'espace virtuel doit être plus grand que l'espace physique. Pas « aussi grand ». Pas « moins grand ». Il doit être plus grand, d'un facteur deux au moins, mais c'est encore mieux d'avoir un facteur dix.
Quiconque ne comprend pas ça est un abruti. Fin de la discussion.
Oui Linux a supporté ça, et probablement mieux que tous les autres. Mais même « mieux que tous les autres » ce n'était vraiment pas terrible. Fondamentalement PAE n'a jamais rien corrigé. C'était une erreur. C'était juste un échec total, le résultat du travail d'ingénieurs hardware qui ne comprenaient rien au logiciel.

En dépit de sa virulente intervention envers cette technique PAE, il est remarquable de constater que Linus Torvalds a quand même accepté de l'intégrer dans le noyau. C'est en 1999, au moment du 2.3.23, que le patch HIGHMEM a été ajouté. Linus n'aimait pas cette technique, mais il y avait clairement un besoin qui était exprimé de pouvoir gérer plus de 4 Go avec des processeurs x86 classiques.
On peut penser que le leader du noyau regrette maintenant cette inclusion (C'était une erreur) mais cela n'explique pas pourquoi nous voyons arriver aujourd'hui dans le noyau 3.3, 13 ans plus tard, la gestion de PAE pour les processeurs ARM modernes.
Linus a beau détester la technique PAE, il est tout à fait conscient que le noyau Linux doit pouvoir gérer les configurations matérielles qui sont utilisées dans le monde réel, aussi baroques soient-elles. Les processeurs ARM 32 bits ambitionnent de rivaliser avec les x86 sur le marché des serveurs et ils doivent donc gérer de grandes quantités de mémoire. C'est bien pour cette raison que la capacité PAE, et aussi une extension permettant la virtualisation, leur a été ajouté récemment.

Les patchs de Catalin Marinas introduisent la page table à trois niveaux permettant de mapper les 40 bits d'adressage physique, ils modifient l'unité de gestion de la mémoire qui gère cette page table et enfin ces patchs ajoutent l'option de configuration ARM_LPAE qui active cette option.
Linus a certes grogné :

Croyez-moi, nous avons plus d'une décennie d'expérience avec cette merde sur x86. C'était une erreur. Le fait que les fanboys ARM essayent maintenant de dire que c'est une bonne idée d'avoir ça sur ARM est triste. Ce n'était pas une bonne idée sur x86 et ce n'est certainement pas une bonne idée sur ARM.

Mais le leader du noyau est avant tout un pragmatique. Il a donc accepté sans barguigner de « puller » les patchs de la branche Git de Russel King, son lieutenant chargé de l'architecture ARM.
Il peut toutefois se consoler en arguant du fait que les futurs processeurs ARM, ceux issus de l'architecture v8, auront enfin un jeu d'instruction 64 bits complet. Dès 2013, il ne sera plus obligatoire d'utiliser l'extension d'adresse physique pour gérer plus de 4 Go sur une puce ARM.
Ce sera l'occasion rêvée pour maudire les récalcitrants de façon pittoresque et pour les enjoindre fermement à utiliser un noyau 64 bits tout propre !

En bref

Pilote réseau « team »

Le pilote réseau « team », qui permet de faire de l'aggrégation d'interfaces réseau, a été ajouté dans Linux 3.3. Le but est de proposer une solution plus simple et plus légère que le bonding classique.

Depuis plusieurs années, le noyau Linux propose un module permettant de faire du « bonding ». Sous ce drôle de terme se cache tout simplement le fait d'appliquer une politique spécifique sur un ensemble de liens réseaux, regroupés en un seul. Par exemple, l'administrateur d'une machine va pouvoir agréger les interfaces réseau eth0 et eth1 et il va activer le mode d'équilibrage de charge (round-robin) entre ces deux interfaces. Le noyau va alors envoyer les paquets réseau sur une interface puis sur l'autre, tour à tour.
Bien entendu, ce mode d'équilibrage de charge n'est qu'une possibilité parmi d'autres (voir la liste complète). Avec le module de « bonding » on peut également faire de la tolérance de panne, du load-balancing adaptatif, etc.

Le nouveau pilote réseau « team », développé par Jiri Pirko qui travaille chez Red Hat, offre la même fonction d'agrégation des interfaces mais la majeure partie du code a été transportée en espace utilisateur. Ce pilote « team » n'est donc qu'une interface minimale avec le noyau et tout le vrai travail se fait, via un lien netlink, dans la bibliothèque libteam.
Cette solution se veut plus simple, plus souple et très adaptable par rapport au bonding classique. En plus, comme un binding Python a été développé pour libteam, il est probable que vont apparaître de nombreux démons spécialisés avec des fonctions inédites.
En attendant, l'utilisation du pilote « team » semble effectivement très simple. À titre d'illustration, si on veut reproduire le mode round-robin décrit plus haut il suffit de faire appel au démon d'exemple team_daemon.py avec ce genre de syntaxe : team_daemon.py --port eth1 --port eth2 -m roundrobin.

Architecture C6X

Une nouvelle ligne s'ajoute dans la très vaste liste des architectures prises en charge par le noyau Linux. En effet, la version 3.3 intègre l'architecture C6X créée par Texas Instruments et qui vise le marché de l'embarqué.

Ce processeur ressemble un peu à l'architecture Hexagon qui a été intégrée dans le noyau précédent puisqu'il s'agit d'un processeur de signal numérique (un DSP). La différence, c'est que la lignée C6X est bien plus limitée qu'Hexagon. Il n'y a pas d'unité de gestion de la mémoire (MMU) ni de modes sophistiqués de contrôle de cohérence (voir le patch d'Aurelien Jacquiot). Il est donc impossible d'utiliser la glibc classique et il faut se rabattre sur la µlibc.
En dépit de ces limitations, les cœurs C6X intégrés dans les DSP KeyStone de TI sont puissants. Le jeu d'instructions est de type 256 bits VLIW et si on regarde, par exemple, le TMS320C6670 gravé en 40nm, on voit qu'il contient 4 cœurs C6X cadencés à 1,2 GHz avec une performances totale de 153 GigaMAC.

Le site linux-c6x.org a été mis en place pour centraliser toutes les informations à propos de la gestion de cette architecture. Le travail est sponsorisé par Texas Instruments qui assure vouloir travailler avec la communauté et continuer à travailler directement avec les projets amonts (upstream) :

Pour aider à l'intégration avec les projets amonts, nous avons engagé des participants connus de chaque communauté upstream. Cela veut dire CodeSourcery pour GCC et des développeurs Linux bien connus de la communauté du noyau.

Un Serpent plus rapide

Le développeur Jussi Kivilinna continue son travail sur les primitives cryptographiques entamé dans le précédent noyau.
Cette fois, c'est l'algorithme de chiffrement symétrique Serpent qui fait l'objet de toutes ses attentions. Cet algorithme est arrivé en finale au moment du concours AES et il n'a perdu contre Rinjdael que du fait d'une moindre rapidité. Son niveau de sécurité était pourtant jugé meilleur, mais c'est l'argument de la vitesse qui l'a finalement emporté.

En plus de son vigoureux nettoyage du code classique en C, Jussi a également posté plusieurs patches pour ce noyau 3.3 afin d'offrir des implémentations alternatives de Serpent en assembleur optimisé. La première version, dédiée à l'architecture x86 (avec instructions vectorielles SSE2), se trouve dans /arch/x86/crypto/serpent-sse2-i586-asm_32.S et elle permet de traiter quatre blocs de données en parallèle. D'après les tests effectués sur un Intel Atom N270, on note un gain en vitesse de chiffrement ou de déchiffrement qui peut atteindre 2,28 fois la vitesse du code C.
Une seconde version arch/x86/crypto/serpent-sse2-x86_64-asm_64.S est disponible pour les processeurs x86-64. Cette fois le traitement se fait avec huit blocs de données en parallèle et le gain maximum a été évalué par Jussi à un facteur 3,70 (sur architecture Intel Celeron T1600) et 2,5 (sur architecture AMD Phenom II 1055T).

De nombreux patchs pour des modes d'opérations cryptographiques spécifiques ont également été intégrés dans cette version 3.3 du noyau Linux. On retrouve les modes LRW et XTS pour Serpent (1 - 2). Ces mêmes modes LRW et XTS sont également disponibles pour l'algorithme de chiffrement Twofish (1 - 2).

Support LLCP

Le sous‐système permettant la création de pilotes de communication en champ proche (NFC, pour Near Field Communication) a été intégré dans la version 3.1 du noyau. NFC est une technologie considérée comme prometteuse pour toutes les interactions à courte portée entre appareils nomades (paiements sans contact, échanges de cartes de visite, etc.).

À cette interface de gestion des pilotes NFC, le développeur Samuel Ortiz a maintenant ajouté le support préliminaire du protocole LLCP (Logical Link Control Protocol) dans le nouveau noyau 3.3. Ce protocole est décrit sur le forum NFC et il concerne la couche liaison de données du modèle OSI. Il s'agit de permettre à deux périphériques NFC d'échanger facilement des données via un système de pair à pair (P2P). Le but est soit d'utiliser directement LLCP afin que les applications puissent transférer des fichiers, soit de se baser sur LLCP pour supporter des protocoles réseaux plus matures comme OBEX ou TCP/IP.

Samuel, qui a testé son code avec un smartphone Nexus S, indique que le support du « Logical Link Control Protocol », n'est encore que partiel dans cette version du noyau Linux. D'ailleurs, on voit que l'option de configuration NFC_LLCP dépend encore d'EXPERIMENTAL. Il manque notamment les fonctions de découverte automatique de services qui seront ajoutées dans les futures versions.

Gestionnaire de batteries

On trouve dans le noyau 3.3 un nouveau gestionnaire permettant la surveillance des batteries, activable grâce à l’option de configuration CHARGER_MANAGER.
Le patch d’intégration de ce sous‐système a été écrit par Donggeun Kim, un développeur travaillant pour Samsung. Une première fonction prise en charge par ce « Charger Manager » est l’agrégation des différentes informations qui sont remontées par les multiples moyens de chargements de la batterie. En effet, on peut avoir plusieurs sources d’énergie jouant le rôle d’un chargeur (le secteur, un port USB, des cellules photovoltaïques, etc.), et cela génère différentes vues au sujet du statut de la batterie. Le nouveau sous‐système agrège ses informations et les rend disponibles pour un programme vivant en espace utilisateur.

Mais la vraie raison d'être de ce patch est de maintenir sous surveillance étroite la température de la batterie du système. On sait qu'une surchauffe est toujours possible et cette surchauffe à même parfois entraîné, notamment avec la technologie lithium-ion, des explosions spectaculaires de la batterie.
Puisqu'une surveillance constante de la température est nécessaire, on voit qu'un problème évident se pose en cas de mise en veille de la machine (suspend-to-RAM). Dans cette situation, le sous-système « Charger Manager » va faire du polling sur la batterie, mais en utilisant la fonction cm_suspend_again (voir l'excellente documentation). Avec cette fonction, il est possible de sortir partiellement de veille, d'évaluer rapidement la température et de remettre immédiatement en veille le système. De cette façon la surveillance de la batterie ne coûte presque rien en termes de consommation.

Bibliothèque pour l'arithmétique multiprécision

Dans le cadre du projet GnuPG, une bibliothèque dédiée libgcrypt a été créée afin de fournir toutes les briques cryptographiques de base. Cette bibliothèque offre également la gestion de l'arithmétique multiprécision pour gérer les nombres de taille arbitraire. En effet, un algorithme de chiffrement asymétrique comme RSA utilise des nombres de très grande taille. Il est donc nécessaire de fournir une bibliothèque logicielle permettant d'aller au-delà de la précision offerte nativement par le processeur.
Cette bibliothèque MPI (Multi-Precision Integers) a été intégrée directement dans le noyau Linux 3.3, afin de lui offrir la possibilité native de vérifier les signatures RSA.

Dans son message de commit, le développeur Dmitry Kasatkin indique que cette intégration de la bibliotèque MPI (activée grâce à l'option MPILIB) avait déjà été effectuée au sein du noyau Linux utilisé par Fedora. Il s'est donc contenté de reprendre ce travail et de corriger tous les warnings et les messages d'erreur issus du script checkpatch (il s'agit d'un script perl qui permet de signaler les erreurs de style dans le code).
S'appuyant sur ce code MPI, Dmitry a ensuite étendu l'API cryptographique du noyau pour permettre la vérification des signatures RSA et il a couplé cette nouvelle fonction de vérification des signatures avec le sous-système EVM (Extended Verification Module) qui a été intégré dans le noyau 3.2.

Le résultat net de ces patchs est que le noyau Linux 3.3 dispose maintenant d'une infrastructure de vérification solide et bien intégrée. Des discussions sont déjà en cours sur la LKML pour offrir la possibilité native de signer les modules noyaux et vérifier leur signature au moment du chargement.

Pilotes Android

Comme annoncé dans la section « Pour la suite » de la précédente dépêche noyau, les principales pièces de l'infrastructure Android ont été réintégrées dans la branche principale.
À la fin de l'année 2009, Greg Kroah-Hartman, le mainteneur de la branche -staging, avait éjecté du noyau les pilotes Android. Son message de commit avait été particulièrement laconique :

Ces pilotes ne sont plus développés et les auteurs d'origine semblent les avoir abandonnés. En conséquence, nous n'en voulons plus dans le noyau.

Greg n'a pas été beaucoup plus prolixe dans son patch de novembre 2011 qui annulait le précédent et réintégrait les pilotes dans -staging:

Ce patch annule le commit b0a0ccfad85b3657fe999805df65f5cfe634ab8a.
Il s'est avéré que j'avais tort, nous voulons ce code dans le noyau.

La version 3.3 de Linux accueille donc le code de ashmem (Android shared memory, mécanisme de partage mémoire), de binder (permettant la communication inter-processus) ou encore de logger (infrastructure de log). Le mécanisme spécifique du « low memory killer » a également retrouvé le chemin du noyau.
Avec cette version 3.3 de Linux, on se rapproche donc du but consistant à pouvoir faire tourner correctement les applications Android sur un noyau vanille (non patché). Le gros morceau qui manque encore est le patch wakelock qui permet de baisser la consommation d'énergie de la plate-forme. D'après Greg:

Le noyau 3.3 vous permettra, sans aucune modification, de booter un espace utilisateur Android, mais la gestion de l'énergie ne sera pas très efficace.

Bien entendu, le travail de maintenance et d'intégration va continuer dans les futures versions. Le « Android mainlining interest group », sponsorisé par Linaro, planifie déjà les étapes suivantes.

Redimensionnement ext4

Les utilisateurs d’ext4 disposent depuis longtemps de la capacité de redimensionner la taille de leur système de fichiers. Cela se fait via le programme resize2fs qui fait partie de la suite de programmes e2fsprogs.
Le développeur Yongqiang Yang a décidé de revoir ce mode de fonctionnement, car, selon lui, le fait d’utiliser un programme en espace utilisateur est préjudiciable pour les performances. Il a donc proposé toute une série de patches implémentant cette fonction de redimensionnement directement dans le noyau.
Tout se fait via le nouvel appel système EXT4_IOC_RESIZE_FS qui gouverne le travail du noyau (allocation des tableaux de bits et de la table des inodes, etc.) et avec en entrée un entier de 64 bits spécifiant la nouvelle taille du système de fichiers (en blocs).
La série de patchs a été soigneusement revue par Ted Ts'o, grand manitou d’ext4, qui a simplifié le code et ajouté divers tests pour intercepter les erreurs éventuelles.

Selon l'évaluation effectuée par Yongqiang Yang, le gain est spectaculaire et on obtient les chiffres suivants pour un redimensionnement du système de fichiers de 20 Go à 230 Go :

Noyaux précédents => 5 minutes et 2,77 secondes
Noyau 3.3 => 3,55 secondes

Attention, toutefois, avec cette fonction de redimensionnement ext4 dans le noyau ! La fonction « bigalloc » qui regroupe en clusters les blocs de données, et qui a été intégrée dans le noyau 3.2, n'est pas encore prise en charge par ces patchs de redimensionnement. Ce travail d'intégration est déjà planifié et nous verrons sans doute arriver ces patchs dans les prochains mois.

Changements dans Btrfs

Du côté de Btrfs, les nouveautés incluses dans le noyau ont été listées par Chris Mason dans son message récapitulatif sur la LKML.
Le plus gros changement concerne la fonction de « balancing » qui permet de réarranger à volonté les ensembles de blocs de données (les chunks). Ce code de « balancing » a été entièrement revu par Ilya Dryomov, et il est maintenant bien plus flexible. Par exemple, les opérations de « restriping » peuvent maintenant être mises en pause (avec BTRFS_BALANCE_CTL_PAUSE) et relancées (avec BTRFS_BALANCE_RESUME). On peut également annuler le restriping en cours ou bien effectuer des reprises après un crash de la machine. Ce « restriping » est bien utile pour changer le mode RAID du volume, par exemple pour passer du mode RAID 1 à un arrangement en RAID 10.

Une nouvelle option expérimentale a également été ajoutée à la vaste panoplie de Btrfs. Cette nouvelle possibilité est disponible si l'option BTRFS_FS_CHECK_INTEGRITY a été choisie lors de la configuration du noyau. Comme son nom l'indique, elle permet de vérifier l'intégrité du système de fichiers. Toute opération sur le système de fichiers est monitorée en temps réel afin d'intercepter les écritures qui pourraient laisser le système dans un état incohérent.
Pour activer la vérification à chaud des métadonnées, il faudra monter le système de fichiers avec les paramètres mount /dev/sdb1 /mnt -o check_int, tandis que si, en plus des métadonnées, on veut vérifier les données du système, alors il faudra utiliser la syntaxe suivante : mount /dev/sdb1 /mnt -o check_int_data.

L'option est considérée comme expérimentale (il y a un gros DANGEROUS dans la description) et en plus, elle est très coûteuse :

plenty of kernel memory is used, and plenty of additional CPU cycles are spent.

C'est sans doute quelque chose à réserver aux développeurs de Btrfs pour l'instant, afin de vérifier que leurs nouveaux patchs n'introduisent pas de corruptions dans le système de fichiers.

Open vSwitch

Le module « Open vSwitch », un commutateur réseau virtuel, a été intégré dans le noyau 3.3.
Bien entendu, il était déjà possible d'avoir un tel commutateur (avec Linux Bridge) mais ici on parle d'un outil bien plus complexe et qui a été étudié spécialement pour répondre aux besoins des machines virtuelles (voir le document « Why OpenvSwitch ? »). Ce commutateur virtuel contrôle le flux réseau (flow-based control) et il est capable de maintenir des abstractions de toute la configuration afin que les migrations de machines virtuelles entre divers hôtes s'effectuent facilement.

Le projet Open vSwitch concerne principalement l'espace utilisateur avec plusieurs démons différents sous licence Apache (ovs-vswitchd, ovs-brcompatd, etc.), mais il y a également un module noyau pour le routage des paquets réseau. Le développeur Jesse Gross a proposé en novembre dernier que ce module noyau, qui avait été écrit et maintenu en dehors de la branche principale, puisse rejoindre le noyau Linux officiel.
Il y a eu plusieurs échanges sur la LKML à propos de ces patchs d'inclusion, mais finalement il a été décidé d'accepter ce module. Le fait que ce switch virtuel soit déjà largement utilisé dans plusieurs projets, notamment dans Xen Server V6, a sans doute contribué à cette acceptation.

Remplacement à chaud pour les disques RAID

Neil Brown, responsable de la couche RAID du noyau Linux, a écrit plusieurs patchs afin d'ajouter une fonction de « remplacement à chaud » pour les disques RAID.

Le sous-système md (pour Multiple Devices) est la couche qui est chargée de la gestion du RAID logiciel dans le noyau. Neil a écouté les demandes les plus fréquentes des utilisateurs concernant md et, d'après le mail récapitulatif qu'il a envoyé sur la liste de diffusion, c'est la fonction de « hot replace » qui arrive en tête de liste.
Habituellement, en cas de d'apparition de problèmes sur un disque, la procédure à suivre consiste à enlever le disque suspect de la grappe RAID puis à installer le nouveau disque et attendre que la couche RAID se charge de la reconstruction des données (rebuild).
Sauf en ce qui concerne le très redondant mode RAID 6, on voit bien que le rebuild est un moment ou il faut retenir son souffle. Durant la phase de la reconstruction des données la grappe de disques est en mode dégradé et une nouvelle perte de disque serait potentiellement très grave. La fonction de « remplacement à chaud » permet d'éviter cette phase délicate et stressante.

Pour cela on lance la phase de reconstruction des données alors même que le disque suspect n'a pas été enlevé de la grappe. Dans ce schéma c'est un disque de secours (spare) qui est utilisé. Quand la couche md s'aperçoit qu'un disque commence à générer des erreurs, les patchs de Neil vont permettre de rattacher automatiquement le disque fautif au disque de secours puis de marquer le premier avec WantReplacement et le second avec Replacement. Cette phase de « remplacement à chaud » sera visible de l'administrateur puisqu'un R apparaîtra dans /proc/mdstat.
Le second patch permet alors de copier les données du disque fautif sur le spare et, si md trouve que des blocs sont corrompus, le sous-système les obtiendra depuis les autres disques. Tout ceci se fait alors que la grappe n'est pas en état dégradé puisque le disque suspect n'a pas encore été déconnecté.
Une fois que l'opération de copie des données est terminée, il suffit de marquer le disque suspect avec le drapeau failed et de le retirer de la grappe. Le spare aura simplement pris sa place, à chaud, sans stress excessif pour l'administrateur.

Tout ce mécanisme est disponible pour les modes RAID 1/4/5/6/10 et il améliore indéniablement la sécurité quand on doit remplacer un disque défaillant.
Attention toutefois, puisque l'outil en espace utilisateur mdadm, qui s'occupe de gérer les disques RAID, n'est pas encore compatible avec cette fonction de « remplacement à chaud ».
Neil Brown a expliqué sur la LKML comment tester la nouvelle fonction sans passer par mdadm. Certes, c'est un peu rustique, mais ce n'est que temporaire. Le hasard faisant bien les choses, il s'avère que Neil est aussi le mainteneur de mdadm et qu'il va très rapidement adapter son logiciel afin d'exploiter cette nouvelle possibilité.

64 To pour les mainframes

Vous êtes frustré parce que Linux bride injustement votre mainframe IBM zSeries ? Vous voudriez pouvoir aller au-delà de la ridicule limite de 3,8 To de RAM des noyaux précédents ?
Soyez rassuré, le développeur Martin Schwidefsky, employé par IBM, a écrit un patch permettant de franchir cette barrière et de gérer jusqu'à 64 To de mémoire vive.
La « page table » à trois niveaux qui permettait de gérer 42 bits (3,8 To de RAM en pratique) a été remplacée par une table à quatre niveaux ayant une valeur MAX_PHYSADDR_BITS sur 46 bits. Avec 64 To de RAM pour s'ébattre et gambader follement, vos applications vous disent merci !
Toutefois, comme le franchissement de chaque niveau d'indirection à un certain coût en performances, il est recommandé de rester sur l'ancienne table à trois niveaux si la quantité de mémoire de la machine est inférieure ou égale à 3,8 To.

Blocage des transferts vers les disques FAT

Après le gros travail effectué sur le noyau 3.2 pour améliorer le code de writeback, le développeur Mel Gorman s’est attaqué à un autre problème difficile frappant ce sous‐système.
Quand le noyau cherche à écrire de grandes quantités de données sur un périphérique lent formaté en FAT (de type clé USB ou carte SD), il arrive que le transfert se bloque pendant de longues secondes avant de reprendre. Le bogue ne se manifeste pas systématiquement, mais il a déjà été remarqué par de nombreux utilisateurs. Il faut bien reconnaître que ces blocages sont particulièrement exaspérants et Mel Gorman a eu à cœur de répondre aux nombreux cris de rage exprimés sur les listes de diffusion.

Ce dysfonctionnement s'est révélé difficile à traquer, mais les développeurs ont finalement réussi à prouver qu’il s’agissait d’une interaction non prévue entre le code de compactage mémoire et le code des huge pages.
Plusieurs patches ont alors modifié le comportement du code de gestion de la mémoire du noyau (1 - 2 - 3), afin de faire disparaître ces blocages.
Mel Gorman a choisi de donner une explication complète de son travail, ainsi que les résultats de ses tests dans le message de commit du dernier patch.
Je recommande particulièrement la lecture de ce message à ceux d’entre vous qui ont la fibre sportive. En effet, il est probable que nous tenions là le record du monde du message de commit le plus détaillé et le plus long jamais publié dans les annales du noyau Linux !

PMU virtuel dans KVM

Du côté de KVM, nous trouvons dans cette version 3.3 du noyau un nouveau moniteur de performances (PMU pour Performance Monitoring Unit) que les systèmes invités peuvent utiliser pour détecter toutes sortes de problèmes.
Habituellement, les PMU sont des unités matérielles présentes sur les processeurs et le système d’exploitation se sert de ces informations, via divers outils, pour avoir une vue d’ensemble des performances. L’ennui, c’est que, dans le cadre d’une virtualisation, l’utilisateur d’un système invité ne peut se servir directement de ces informations qui sont réservées au système hôte.

Avi Kivity et Gleb Natapov ont donc choisi d’émuler un PMU via perf_events, ce qui offre une grande liberté aux utilisateurs des machines virtuelles (voir ce fichier PDF). Grâce à ce moniteur virtuel, les utilisateurs peuvent maintenant faire appel aux outils de profilage standard dans leur système invité pour identifier eux‐mêmes les problèmes de performances.

Pilotes graphiques

En ce qui concerne les différents pilotes graphiques présents dans le noyau 3.3, on peut aller lire le message récapitulatif de Dave Airlie pour avoir une idée des principales nouveautés.

En ce qui concerne Nouveau, on note que la gestion de la sortie audio via HDMI a été ajoutée pour les cartes de type GeForce GT 240 jusqu’aux modèles GeForce 400/500 « Fermi ». Ces derniers modèles bénéficient par ailleurs de l’infrastructure expérimentale de re‐clocking (gestion de la fréquence) développée par Ben Skeggs.
Martin Peres a écrit un patch permettant de gérer les ventirads des cartes NVidia GeForce 6 et des modèles supérieurs. Cette prise en charge est encore considérée comme incomplète, puisque seul un contrôle manuel est implémenté.
Enfin, le pilote vga_switcheroo qui est utilisé pour basculer entre une carte intégrée et un GPU plus puissant, a été amélioré par Peter Lekensteyn. Ce pilote corrige plusieurs dysfonctionnements qui affectaient jusqu’à présent la gestion des machines disposant de la technologie propriétaire NVidia Optimus.

Du côté Radeon, il y a — comme pour Nouveau — une prise en charge de l’audio HDMI qui est désormais fonctionnelle sur les cartes de type Evergreen.
Un patch très important est celui écrit par Jérôme Glisse, qui ajoute la gestion de la mémoire virtuelle dans le pilote libre Radeon. C’est un ajout assez invasif (1 400 lignes de code en plus) et très sensible (22 itérations ont été nécessaires), mais ce travail était indispensable pour gérer correctement dans le futur la nouvelle architecture ATI/AMD de type « Graphics Core Next ».

Du côté d’Intel, une petite déception, puisque le pilote i915 n’active toujours pas par défaut le mode d’économie d’énergie RC6 sur les puces Sandy Bridge. On trouve néanmoins quelques avancées, avec une amélioration de la prise en charge des futurs Ivy Bridge, la gestion des tableaux de pixels privés (private plane) ou des sprites vidéos.

Pour finir cette revue des nouveautés dans le domaine graphique, le pilote gma500 écrit par Alan Cox a quitté la branche -staging du noyau. Sa qualité est jugée suffisamment bonne pour qu’il intègre sa branche dédiée sous /drivers/gpu/drm/gma500. Les utilisateurs des cartes graphiques de type Poulsbo (option DRM_GMA500) ou Cedarview (option DRM_GMA600) peuvent maintenant bénéficier d’un pilote, certes basique, sans accélération 3D, mais entièrement libre.

Comment feinter EFI

Les jours du BIOS sont comptés et son successeur, EFI, va se répandre dans de plus en plus de machines x86.
Les développeurs Linux se méfient de ce système d’amorçage et ils souhaitent interagir le moins possible avec ce code qui échappe à leur contrôle. C’est pour cette raison que Matt Fleming a écrit un patch qui permet de charger directement une image du noyau sans avoir à passer par un chargeur d’amorçage (bootloader).
L’option de configuration EFI_STUB modifie subtilement l’image du noyau bzImage en ajoutant des informations dans les champs libres des en‐têtes. De cette façon, ce fichier bzImage sera interprété par le micrologiciel comme une application EFI conforme qui sera chargée directement. En outre, cerise sur le gâteau, ce camouflage astucieux de bzImage ne rend pas l’image incompatible avec un chargeur BIOS, ce qui permet à une image unique d’être compatible avec tous les environnements d’amorçage.

Deux modifications dans /proc

Le pseudo-système de fichiers procfs, qui est accessible via /proc, est utilisé pour donner des informations sur les processus et sur le système. Le noyau 3.3 incorpore deux modifications de ce fort utile système de fichiers virtuel.

Le premier changement est lié au mécanisme de migration des applications d’une machine à l’autre. Pour cela, on enregistre l’état complet d’une application (checkpoint), et on utilise ces informations pour relancer l’application exactement dans l’état dans lequel elle se trouvait auparavant (restart).
Bien entendu, c’est plus facile à dire qu’à faire, et de nombreuses subtilités techniques viennent se mettre en travers de la route de ceux qui veulent faire du checkpointing. Depuis plusieurs années, un effort de longue haleine a été engagé pour permettre au noyau Linux d’offrir une infrastructure robuste de checkpointing et cette modification de /proc s’inscrit dans cette perspective.
Pavel Emelyanov a écrit plusieurs patches afin de créer un nouveau répertoire map_file dans l’arborescence de chacun des processus. Ce répertoire est visible sous /proc/<pid>/map_files/ et il permet de lister, via un lien symbolique, toutes les zones correspondantes en mémoire. Selon le message de commit de Pavel, ce changement est une brique qui sera utile dans la future infrastructure de checkpointing du noyau.

La seconde modification de procfs concerne la sécurité et elle est le résultat des efforts de Vasiliy Kulikov (un journal LinuxFr a déjà été consacré à ce développeur).
Il s’agit essentiellement de proposer de nouvelles options de montage de /proc afin de mieux protéger l’accès aux informations contenues dans ce pseudo‐système de fichiers.

Le message de commit du patch explique que l’option de montage hidepid=0, utilisée par défaut, ne change rien à l’ancien comportement. Tout le monde, y compris un vil pédo‐terroriste, peut lire le contenu de /proc/<pid>/* et se servir de ces données pour ourdir un plan démoniaque de domination du monde (voir cette preuve de concept qui utilise les informations de /proc/<pid>/* pour espionner les frappes clavier).
En revanche, si procfs est monté avec hidepid=1, alors l’accès sera restreint aux processus ayant les mêmes droits que ceux de l’utilisateur. Toute tentative de lecture d’un processus ne lui appartenant pas sera interdite.
Enfin, l’option hidepid=2 permet d’aller encore plus loin, puisqu’en plus d’interdire l’accès, elle masque l’existence même des processus qui n’appartiennent pas à l’utilisateur.
Bien entendu, ces patches ne constituent pas une protection parfaite et absolue, mais, selon Vasiliy :

It greatly complicates an intruder's task of gathering information about running processes.

Pilote NVM Express

Les disques durs SSD (à base de mémoire flash) sont habituellement connectés à la carte mère de l’ordinateur via un port SATA.
Pourtant, de nombreux constructeurs proposent des disques SSD haut de gamme qui utilisent le bus PCI Express. Cela permet d’échapper au goulet d’étranglement de SATA et d’empiler les puces flash en parallèle pour atteindre des débits faramineux de plusieurs Go par seconde.
Jusqu’à présent, il n’y avait pas de spécifications précises, ni de standard décrivant cette utilisation de l’interface PCIe par des disques SSD. Dans ces conditions, chaque constructeur était obligé de développer un pilote spécifique, avec tous les inconvénients qui accompagnent ce mode de travail (problèmes de compatibilité avec les divers systèmes d’exploitation, qualité disparate entre les constructeurs, code source gardé jalousement, etc.).

C’est pour permettre de sortir de cette situation que la norme NVM express a été développée par un consortium de divers constructeurs (Intel, Micron, Dell, SandForce, etc.). Grâce à cette norme, il suffira que le système d’exploitation incorpore le pilote générique NVM Express et les disques SSD pourront se brancher facilement sur le port PCIe, sans devoir utiliser de pilote spécifique.
L’interface est optimisée spécialement pour les disques à état solide (NVM c’est pour Non‐Volatile Memory), et les limites en termes de performances sont repoussées très loin. Par exemple, selon ce document PDF de présentation, la norme NVM express autorise jusqu’à 64 000 queues d’entrées‐sorties et chacune de ces queues peut accueillir 64 000 commandes différentes !

Le pilote NVM Express incorporé dans le noyau Linux 3.3 a été écrit par Matthew Wilcox qui travaille chez Intel et le module est activable à la configuration via l’option BLK_DEV_NVME. Bien entendu, Linux est le tout premier OS à intégrer ce pilote NVM Express.
On peut parier que cette standardisation, qui autorise une baisse des coûts et une plus grande facilité d’utilisation, va permettre une certaine démocratisation des disques SSD PCIe auprès des utilisateurs.

Sélection dynamique de la fréquence dans ath9k

Depuis l'adoption de la norme IEEE 802.11a, les transmissions de données sans fil (Wi-Fi) peuvent utiliser la bande de fréquences des 5 GHz. Cela autorise un meilleur débit que la classique bande des 2,4 GHz, mais cela pose aussi de redoutables problèmes d'interférences avec toutes sortes de matériels sensibles. La bande des 5 GHz étant en particulier utilisée par les radars de trafic aérien et les radars météorologiques, on comprend qu'un brouillage intempestif serait de fort mauvais aloi au moment de l'atterrissage d'un avion !

C’est pour permettre d’éviter ce genre de problèmes qu’a été publiée la norme IEEE 802.11h qui instaure diverses obligations auxquelles doivent se soumettre les équipements Wi‐Fi. En particulier, un protocole de sélection dynamique de la fréquence (DFS pour Dynamic Frequency Selection) est décrit dans la norme pour permettre aux stations de base Wi‐Fi d’utiliser sans risques la bande 5 GHz.
L’idée est de forcer une station à détecter les impulsions radar avant qu’elle ne commence à émettre quoi que ce soit. Si aucun signal radar n’est détecté, alors la station Wi‐Fi passe en mode émission. Si, au contraire, un signal est détecté et qu’il correspond aux tables descriptives des radars (largeur d’impulsion, fréquence, taux de répétition), alors la station doit changer de canal d’émission.

Le travail consistant à ajouter la gestion de DFS dans le noyau Linux a commencé depuis longtemps, et nous voyons maintenant arriver les premiers résultats. Dans le noyau 3.3, le pilote Atheros ath9k a été modifié afin de tirer partie des capacités matérielles de détection radiofréquence de la carte. Le patch de Zefir Kurtisi ajoute donc la gestion de ces fonctions de détections des impulsions radar, et il implémente un traitement des fausses alertes. Dans les prochains noyaux seront ajoutées les tables permettant de reconnaître précisément les divers radars (pattern detectors).
La fonction s’active avec l’option de construction ATH9K_DFS_CERTIFIED, mais le message d’aide sur cette option indique bien que la gestion de DFS n’est que préliminaire et qu’il reste du travail à faire.

ASPM et consommation

Tout le monde le sait, il l’a répété à de nombreuses reprises, Linus Torvalds n’a pas une très haute estime des auteurs des BIOS de nos machines :

We do not trust BIOS tables, because BIOS writers are invariably totally incompetent crack-addicted monkeys. If they weren’t, they wouldn’t be BIOS writers.

Il est peu probable que la saga du problème de consommation, introduit à partir du noyau 2.6.38, le fasse changer d’avis. C’est en effet essentiellement un problème de BIOS mal écrit qui est à l’origine de cette surconsommation.

Dans le noyau 2.6.38, un patch avait été ajouté qui désactivait la gestion de l’énergie via ASPM (Active State Power Management), sauf si le BIOS déclarait qu’il était capable de prendre en charge ce mode de gestion. Ce patch avait été introduit parce que l’utilisation inconditionnelle de l’ASPM, même pour les machines incapables de le gérer, pouvait entraîner des blocages.
L’ennui, c’est que — comme on l’a vu plus haut — les BIOS sont souvent écrits par des « singes incompétents se shootant au crack », et qu’un BIOS pouvait déclarer ne pas gérer le protocole ASPM, alors qu’en réalité le matériel en était parfaitement capable. On se retrouvait donc avec un protocole ASPM désactivé inutilement, ce qui entraînait une consommation plus forte de courant.
Après la constatation de ce problème, les développeurs du noyau Linux se retrouvaient devant plusieurs alternatives :

soit revenir au comportement pre-2.6.38 et toujours activer ASPM. Dans ce cas, certaines machines ne supportant pas l’ASPM se bloquent ;
soit désactiver ASPM quand le BIOS annonce son incapacité à le prendre en charge. Dans ce cas, les machines ayant un BIOS déficient consomment 30 % de plus.

Comment trancher ce nœud gordien ?
Matthew Garrett s’est intéressé à une présentation de Microsoft (PCI Express In Depth for Windows Vista and Beyond), afin de comprendre comment la firme de Redmond faisait pour gérer ce problème dans Windows. La réponse est que Windows ne gère rien du tout tant que la fonction _OSC de PCI-Express ne lui a pas donné la main. Cette fonction _OSC, décrite dans ce fichier PDF, est utilisée pour communiquer au système d’exploitation les capacités du matériel sous‐jacent.
Le patch de Matthew incorporé dans le noyau 3.3 copie simplement ce comportement en pariant sur le fait que les constructeurs testent leur matériel sur Windows. De cette façon, on court‐circuite les éventuelles informations fautives du BIOS et on se protège des dégâts causés par les singes sus‐nommés.
D’après les tests effectués, le gain est important, puisqu’il peut atteindre 5 watts sur un portable Thinkpad X220 au repos.

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.3, le site LWN a publié son traditionnel article récapitulatif.

Il s’agit d’un cycle assez actif avec (au 12 mars) 10 449 patches (11 800 pour le précédent 3.2 qui était le troisième plus gros de tous les temps). Ce sont 1 264 développeurs différents qui sont recensés dans les statistiques Git et, cette fois‐ci, le plus prolifique d’entre eux est Mark Brown avec 283 patches. Un coup d’œil sur ses contributions fait remonter une multitude de résultats concernant les pilotes et la couche audio. Pas très étonnant quand on sait que Mark est employé par Wolfson Microelectronics, une entreprise spécialisée dans les puces audio.
Le second est Mauro Carvalho Chehab avec 271 patches, concentrés sur la couche vidéo V4L2, tandis que la médaille de bronze revient à Axel Lin qui, comme Mark, travaille sur la couche audio.

Ce podium est l’occasion de rappeler aux lecteurs un biais, parmi d’autres, qui est introduit dans ces dépêches LinuxFr récurrentes. Elles se concentrent sur la partie « visible » de l’iceberg du développement Linux et passent souvent sous silence l’énorme travail concernant tous les pilotes présents dans le noyau. Comme le signale Linus dans ses messages de RC, c’est pourtant là que, statistiquement, est concentrée la plus grande partie des patches.
Le problème, c’est que ce genre de travail, un océan de patches disséminés dans tout l’arbre des sources, se résume très mal de façon cohérente dans un article. C’est donc un point à garder à l’esprit : les nouveaux noyaux apportent bien plus que ce qui est listé dans ces dépêches !

Après cet intermède de mise au point, retournons aux chiffres. Ce cycle de développement a rajouté environ 563 000 lignes de code et en a supprimé 395 000. Le gain net de 168 000 permet de passer, pour la première fois, la barre symbolique des 15 millions de lignes en tout !

C’est encore une fois Red Hat qui domine le classement des entreprises contributrices, avec 1 304 patches. Intel n’est pas loin derrière, avec un peu plus de 1 000 patches.
En dépit de cette stabilité en tête, Jonathan Corbet a fait remarquer dans son article que les sociétés du monde de l’embarqué montaient régulièrement en puissance. On voit de plus en plus de contributions de la part des Qualcomm, Texas Instruments, Broadcom, Freescale et autres Samsung.

Ces sociétés ne travaillent pas uniquement sur le support de leur matériel, de plus en plus, elles contribuent également sur le cœur du noyau et infléchissent son évolution dans les directions dont elles ont besoin sur leurs marchés. Il fut un temps où il était courant d’entendre que le développement du noyau Linux était dominé par les besoins de déploiement dans les grandes entreprise. Peu de gens diraient ça de nos jours.

Jusqu’à présent, il n’y a pas eu dans l’histoire du noyau de grand conflit technique du fait de priorités de développement contradictoires. Est‐ce que cette irruption accélérée des firmes de l’embarqué va changer quelque chose à cette situation ? Il sera certainement intéressant de suivre cette évolution dans les prochaines versions du noyau Linux.

Aller plus loin

LWN 1: Les nouveautés du noyau 3.3 (987 clics)
LWN 2: Les nouveautés du noyau 3.3 (413 clics)
La liste des nouveautés sur kernelnewbies.org (532 clics)

# RSA dans le noyau

Posté par claudex le 19 mars 2012 à 09:56. Évalué à 10.

Je me demande quel est l'intérêt de vérifier des clefs RSA dans le noyau. Alors certe, c'est sans doute plus rapide mais à ce moment-là, on peut aussi tout mettre dans le noyau, ça ira plus vite. Quelle est la justification pour mettre ça dans le noyau et pas Xorg ou Pulseaudio?

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: RSA dans le noyau
  
  Posté par Aissen le 19 mars 2012 à 10:47. Évalué à 10.
  
  Ça permet d’utiliser une accélération matérielle, si elle est disponible: des drivers peuvent fournir des "backend" crypto adaptés pour permettre de chiffrer bien plus vite. Le noyau joue son rôle ici de fournir à l’userspace une seule ABI pour accéder à tous les accélérateurs crypto différents.
  
  Et ça évite trop de context-switchs dans le cas d’un driver userspace (qui n’aurait d’ailleurs par forcément l’API pour accéder au matériel).
  - [^] # Re: RSA dans le noyau
    
    Posté par Gof (site web personnel) le 19 mars 2012 à 19:50. Évalué à 5.
    
    Je ne suis toujours pas convaincu.
    
    L'implémentation des algo de crypto peut être réalisée dans des librairies en espace utilisateur. L'espace utilisateur peut aussi accéder au matériel spécifique à l'aide des bons appels systèmes (example: OpenCV).
    
    Et pour éviter les context switch, pourquoi ne pas tout mettre dans le noyaux alors? XOrg? GCC?
    - [^] # Re: RSA dans le noyau
      
      Posté par oinkoink_daotter le 19 mars 2012 à 23:38. Évalué à 2.
      
      Au hasard :
      - l'absence de libc ?
      - l'absence de protection mémoire ?
      - l'absence de flottants ?
      - la surface démente de code non maîtrisé à "auditer" pour éviter que ce soit la fête du slip ?
      
      Je pense que la dedans, on peut choisir au moins 4 bonnes raisons :-)
      - [^] # Re: RSA dans le noyau
        
        Posté par jeberger (site web personnel) le 20 mars 2012 à 21:39. Évalué à 1.
        
        En quoi ces raisons ne s'appliquent-elles pas pour RSA ?
        
        [^] # Re: RSA dans le noyau
        
        Posté par ymorin le 20 mars 2012 à 22:57. Évalué à 10.
        
        En quoi ces raisons ne s'appliquent-elles pas pour RSA ?
        
        En fait, avoir la crypto dans le noyau permet d'utiliser les "coffres forts numériques", tels que EVM. Ça vas pour RSA comme pour tout autre algo de chiffrement.
        
        Avec de tels coffres forts, il n'est pas possible d'avoir la valeur de la clé, qui est stockée dans une mémoire inaccessible. Le seul moyen de chiffrer et déchiffrer, c'est d'envoyer un blob dans le module de chiffrement, de lui demander de chiffrer ou déchiffrer, et de récupérer le résultat.
        
        Bien entendu, il n'est pas possible de faire ça depuis l'espace utilisateur, car dialoguer avec le module de chiffrement se fait souvent par des accès restreints (eg. instructions disponibles seulement en ring 0 sur x86, ou mémoire non mappable dans l'adresse d'un processus mais disponible pour le noyau, etc…)
        
        De plus, pour éviter que différents utilisateurs du module ne se "marche dessus", il faut sérialiser les accès. Ça se fait très bien dans un driver, pas en espace utilisateur (non, les sémaphores n'aident pas, par exemple s'il y deux implémentations dans deux programmes ou librairies différents).
        
        Bon, c'est une vue un peu simplifiée, mais c'est grosso-modo la raison de le faire en mode noyau. Le principe vaut aussi pour les algos de hachage, comme sha1 & Co. qui peuvent être accélérés de cette manière (sauf si ce sont des instruction et pas un module matériel, auquel cas la restriction ne s'applique pas, ces instructions n'étant pas protégées).
        
        Hop,
        Moi.
        
        [^] # Re: RSA dans le noyau
        
        Posté par oinkoink_daotter le 20 mars 2012 à 23:10. Évalué à 3.
        
        Tu as les pointeurs sur les commits dans la dépêche. On peut difficilement comparer xorg avec un (bon, d'accord, deux) petit patch, localisé, porté pour ne pas utiliser la libc, dont les deux tiers sont représentés par une bibliothèque de calculs sur les entiers.
  - [^] # Re: RSA dans le noyau
    
    Posté par oinkoink_daotter le 19 mars 2012 à 23:51. Évalué à 5.
    
    Non. L'interface unifiée en question, elle existe déjà et s'appelle PKCS#11.
    
    La, l'intérêt est double :
    - tout d'abord, protéger le noyau contre un environnement auquel celui-ci accorde moins de confiance : l'userspace. Ca ne sert pas à grand chose de blinder le kernel de vérification crypto si c'est pour les déléguer à l'userspace. C'est ce qu'indique patrick_g au dessous.
    - ça permet aussi de fournir des services crypto à l'utilisateur (c'est ce que tu écris, il me semble). A mon avis, l'interêt dans ce scenario est surtout que ces fonctions vont avoir un niveau de confiance présumé identique à celui du kernel, qui est supérieur à celui d'une bibliothèque user space. Par contre, niveau context switching, ça reste la fête, puisque c'est toujours un processus utilisateur qui s'adresse au noyau.
- [^] # Re: RSA dans le noyau
  
  Posté par patrick_g (site web personnel) le 19 mars 2012 à 10:47. Évalué à 10.
  
  Je me demande quel est l'intérêt de vérifier des clefs RSA dans le noyau.
  
  La lib MPI sert maintenant au sous-système EVM.
  Comme EVM c'est un truc qui permet de faire du contrôle d'intégrité, il vaut mieux faire ça dans le kernel plutôt que de dépendre de programmes user space.
  Ce sera encore plus vrai si le projet de signer les modules noyaux arrive un jour.
- [^] # Re: RSA dans le noyau
  
  Posté par NeoX le 19 mars 2012 à 10:50. Évalué à 2.
  
  si je ne m'abuse le noyau peut deja faire pas mal d'operation de (de)cryptage
  là ils ont juste ajouté la bibliotheqe MPI pour pouvoir en plus gerer les RSA.
# News kernel syndicale.

Posté par ナイコ (site web personnel) le 19 mars 2012 à 10:46. Évalué à 3.

Et voilà, ma pause clope est planifiée et bien remplie. Merci :)
- [^] # Re: News kernel syndicale.
  
  Posté par bubar🦥 (Mastodon) le 19 mars 2012 à 10:51. Évalué à 9.
  
  wow tu lis vite!
  - [^] # Re: News kernel syndicale.
    
    Posté par ナイコ (site web personnel) le 19 mars 2012 à 11:02. Évalué à 3.
    
    …Ok, ça me fera plusieurs pauses. J'avoue. J'en ai pour la semaine, dammit !
  - [^] # Re: News kernel syndicale.
    
    Posté par rootix le 19 mars 2012 à 12:12. Évalué à 3.
    
    Non, il fume longtemps.
  - [^] # Re: News kernel syndicale.
    
    Posté par totof2000 le 19 mars 2012 à 14:03. Évalué à 4.
    
    Non, il fume beaucoup.
    - [^] # Re: News kernel syndicale.
      
      Posté par lendemain le 19 mars 2012 à 14:23. Évalué à 10.
      
      C'est sa pause paquet de clopes.
- [^] # Re: News kernel syndicale.
  
  Posté par Neije le 19 mars 2012 à 16:33. Évalué à 1.
  
  sympa les pauses clopes de 90 min xD
  
  Heureusement pour le patron, c'est pas toutes les semaines ;-)
  
  Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
  - [^] # Re: News kernel syndicale.
    
    Posté par Joris Dedieu (site web personnel) le 20 mars 2012 à 16:20. Évalué à 3.
    
    Heureusement pour le patron, c'est pas toutes les semaines ;-)
    
    Bande de menteurs ! arrêtez de faire croire que vous ne moulez jamais au boulot.
    - [^] # Re: News kernel syndicale.
      
      Posté par ナイコ (site web personnel) le 21 mars 2012 à 15:28. Évalué à 3.
      
      Je suis certains qu'on les prend même à bosser au bouchot.
# Club des amis des UUOC

Posté par patrick_g (site web personnel) le 19 mars 2012 à 11:04. Évalué à 10.

patrick@laptop:~/LinuxFr$ cat noyau_3.3.txt|grep -o '](http'|wc -w
261

Nouveau record pour une dépêche noyau.
Maintenant c'est très chronophage de mettre ces liens, donc ce serait bien d'avoir un retour des lecteurs à ce sujet. Est-ce que c'est utile d'en mettre autant ? Est-ce qu'il y a vraiment des gens qui s'en servent pour approfondir ?
- [^] # Re: Club des amis des UUOC
  
  Posté par Julien Fontanet (site web personnel) le 19 mars 2012 à 11:07. Évalué à 10.
  
  Personnellement je clique en moyenne sur 3-4 liens, si tout le monde fait comme ça alors oui ça vaut le coup.
  
  Merci pour la qualité des dépêches.
- [^] # Re: Club des amis des UUOC
  
  Posté par Zenitram (site web personnel) le 19 mars 2012 à 11:33. Évalué à 10.
  
  Chaque personne ne peut pas cliquer sur tout, mais chaque personne est différente, et clique sur ce qui l’intéresse le plus pour approfondir, et ce n'est jamais le même lien cliqué. Et comme ça, chaque ligne est argumentée (avec une "preuve"), à fond dans le principe du web (des hyperliens).
  
  Donc pour répondre à la question : je pense que oui, mais c'est toi/vous qui fait, donc c'est à toi/vous surtout de décider si tu as envie ou pas d'y passer autant de temps.
  - [^] # Re: Club des amis des UUOC
    
    Posté par bubar🦥 (Mastodon) le 19 mars 2012 à 13:20. Évalué à 7. Dernière modification le 19 mars 2012 à 13:20.
    
    +1
    À chaque sujets abordés dans la dépêche le lecteur doit se faire son tri de documents externe à lire (?) Perso j'me suis mis sous le coude ceux concernant le writeback, car ce bug est assez insupportable sur de l'usb 1.1 avec des clefs péraves (je ne connais pas les diffs, peu importe, ça n'arrive qu'avec une seule clef ici. Et ce n'est pas seulement la copie qui est mise en attente, mais parfois la totalité du système qui gèle qq secondes, plusieurs fois par gros transferts, comme si la clef avait un cache différent et plus petit que celui annoncé et que le noyau essai quant même… je sais pas, bref doc à lire). Et aussi liens vers ce qui concerne EFI & NVM Express. MIAM
    Bref, comme à chaque fois, la dépêche (m') apprends beaucoup, et demande du temps pour être lue attentivement, donc lire les docs est qq chose de fait plus tard, en revenant sur la dépêche pour y piocher ces précieux liens. J'imagine que d'autres seront plus intéressés par checkpatch s'ils le découvrent.
    Bref, c'est génial, merci pour cette partie là aussi (qui doit demander beaucoup de temps de recherche pour piocher the best)
  - [^] # Re: Club des amis des UUOC
    
    Posté par moi1392 le 19 mars 2012 à 14:49. Évalué à 10.
    
    Mille personnes peuvent cliquer mille fois sur un lien,
    mais une personnes ne peut pas cliquer mille fois sur mille liens !
    
    enfin… on s'est compris!
    
    En tous cas, comme les autres, je clique sur quelques liens à chaque dépêche sur le noyau que je lis.
- [^] # Re: Club des amis des UUOC
  
  Posté par mgoeminne (site web personnel) le 19 mars 2012 à 12:59. Évalué à 1.
  
  Personnellement je clique sur la plupart des liens qui me semblent pointer vers des informations techniques. Les discussions enflammées m'intéressent moins que ce à quoi elles aboutissent.
  
  Dans l'absolu, c'est clairement un plus d'avoir tous ces liens (et merci pour l'effort fourni), mais de là à dire si tous sont nécessaires/utiles…
- [^] # Re: Club des amis des UUOC
  
  Posté par coïn le 19 mars 2012 à 13:15. Évalué à 3.
  
  Je sais que c'est mal vu de critiquer les news noyaux, mais je trouve que traduire l'ensemble de mail d'annonce des RC n'apporte pas grand chose.
  
  Un résumé des meilleurs "vannes" et info de Linus devrait être suffisant.
  
  Pour ce qui est des liens, ca m'est arrivé d'essayer d'approfondir un sujet, genre 1 fois :-)
  - [^] # Re: Club des amis des UUOC
    
    Posté par bubar🦥 (Mastodon) le 19 mars 2012 à 13:24. Évalué à 10. Dernière modification le 19 mars 2012 à 13:26.
    
    Beuh ? Si la dépêche ne faisait état que des meilleures blagues / trolls / défonçages, ça donnerait peut être, et à force, une mauvaise image de Linus. Or, là, ça nous apprends autant sur le bonhomme (ne pas voir qu'un seul côté) que sur le mode de fonctionnement de l'équipe et des règles. Bref, ça serait dommage de se passer de ces traductions.
    mes deux centicents.
  - [^] # Re: Club des amis des UUOC
    
    Posté par wismerhill le 25 mars 2012 à 19:25. Évalué à 3.
    
    Je ne suis pas d'accord, j'aime beaucoup lire ces traductions de messages de RC, même si je lis couramment l'anglais j'ai bien les avoir regroupés à la queue leu-leu dans la dépêche.
    
    Et en repassant rapidement sur la dépêche pour repérer les liens qui ont changé de couleur, j'ai cliqué sur 5 liens. c'est sympa d'avoir le lien direct quand on veut plus d'informations sur un sujet en particulier.
- [^] # Re: Club des amis des UUOC
  
  Posté par coïn le 19 mars 2012 à 13:19. Évalué à 1.
  
  Autre détail, l'utilisation de cat is useless. grep étant parfaitement capable d'ouvrir un fichier tout seul :-)
  - [^] # Re: Club des amis des UUOC
    
    Posté par Julien Fontanet (site web personnel) le 19 mars 2012 à 13:38. Évalué à 5.
    
    D'où le titre du commentaire…
    - [^] # Re: Club des amis des UUOC
      
      Posté par patrick_g (site web personnel) le 19 mars 2012 à 13:45. Évalué à 7.
      
      Oui parfaitement…mais en plus mon pauvre cerveau trouve ça plus logique d'écrire la commande comme ça avec les instructions qui se suivent de gauche à droite dans le sens de la lecture.
      - [^] # Re: Club des amis des UUOC
        
        Posté par Julien Fontanet (site web personnel) le 19 mars 2012 à 14:00. Évalué à 4.
        
        Sans cat et de gauche à droite ;) :
        
        < noyau_3.3.txt grep -o '](http' | wc -w
        
        [^] # Re: Club des amis des UUOC
        
        Posté par patrick_g (site web personnel) le 19 mars 2012 à 14:23. Évalué à 5.
        
        Certes, mais je n'aime pas le < perdu à gauche qui, à mes yeux de béotien, semble moins naturel que la commande que je tape.
        
        [^] # Re: Club des amis des UUOC
        
        Posté par Thomas Debesse (site web personnel) le 19 mars 2012 à 16:04. Évalué à 3.
        
        Ces caractères < et > ressemblant à des flèches, et donc ça fait bizarre de ne rien voir à la pointe.
        
        programme > fichier ou programme < fichier est très clair, < fichier programme l'est moins, et parfois, moi aussi je met des cat inutiles, juste pour la lisibilité.,
        
        ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Club des amis des UUOC
  
  Posté par Anonyme le 19 mars 2012 à 13:55. Évalué à 4.
  
  J'aime particulièrement picorer dans ces liens directs vers les sources. Leur absence appauvrirait beaucoup la dépêche et obligerait chaque lecteur à refaire votre travail de recherche. Ne les abandonnez pas svp.
- [^] # Re: Club des amis des UUOC
  
  Posté par Trollgouin le 19 mars 2012 à 14:18. Évalué à 4.
  
  Pour ma part, je ne m'en sert qu'occasionnellement, quand le texte donné ne me suffit pas. Mais je te bénis (laïquement) à chaque fois que je les utilise (et ça fait de ces dépêches des petits bijoux). Je pense que j'aurais des problèmes (ou au moins que je perdrais du temps) à retrouver toutes les sources d'info qui sont très variées. D'un autre côté, toi, c'est à chaque fois que tu t'embêtes…
  
  À toi de voir si tu continue de les mettre (j'imagine en effet que c'est un long boulot), mais en tous cas, merci pour ton travail, avec ou sans liens!
- [^] # Re: Club des amis des UUOC
  
  Posté par Thomas Debesse (site web personnel) le 19 mars 2012 à 16:08. Évalué à 4. Dernière modification le 19 mars 2012 à 16:11.
  
  Est-ce que c'est utile d'en mettre autant [de liens] ? Est-ce qu'il y a vraiment des gens qui s'en servent pour approfondir ?
  
  Oui ! Comme d'autres l'on dit, je ne les ouvres pas tous en effet, uniquement ceux qui m'intéressent, mais s'ils n'étaient pas tous là, il n'y aurait pas ceux qui m'intéressent ! :)
  
  [Edit: et puis j'ai tendance à faire pareil, même si j'écris moins de news. Je ne tirerai pas sur l'ambulance qui pourrait venir me chercher moi aussi !]
  
  ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Club des amis des UUOC
  
  Posté par Yves Bourguignon le 19 mars 2012 à 20:48. Évalué à 1.
  
  Est-ce volontaire de ne pas utiliser la syntaxe wikilien pour les pages Wikipedia ? J'y vois un intérêt, c'est de ne pas avoir un texte avec des W plein les lignes mais d'un autre côté, c'est justement un moyen de gagner du temps en rédaction. 2 crochets de part et d'autre du mot-clé et hop le lien est fait (bon d'accord, pas toujours vrai : "en:" et "noms_qualifiés"). L'extension Fx Wikilook permettant de vérifier la validité du lien.
  - [^] # Re: Club des amis des UUOC
    
    Posté par BAud (site web personnel) le 19 mars 2012 à 22:43. Évalué à 4.
    
    cela fonctionne parfois moyennement sur les pages d'un acronyme (renvoi vers page d'homonymie…) ou quand il faut faire un accord ou tout simplement écrire en français pour renvoyer vers la page anglaise (souvent mieux fournie :/).
    - [^] # Re: Club des amis des UUOC
      
      Posté par patrick_g (site web personnel) le 19 mars 2012 à 23:08. Évalué à 3.
      
      C'est toi qui a rajouté l'hyperlien sur "barguigner" dans la news ? C'est relativement connu comme mot non ?
      - [^] # Re: Club des amis des UUOC
        
        Posté par BAud (site web personnel) le 19 mars 2012 à 23:26. Évalué à 8.
        
        vi, je l'ai rajouté parce que je l'ai recherché :) (en appliquant l'adage « si je me pose la question, je ne serai sans doute pas le seul », autant faciliter la tâche en mettant le lien).
        stait au-delà des mes 3000 mots de vocabulaire courant en tout cas ;-) j'ai cru au début que c'était « baragouiner » mais le sens ne collait pas.
- [^] # Re: Club des amis des UUOC
  
  Posté par Mali (site web personnel) le 20 mars 2012 à 14:17. Évalué à 6.
  
  Ne changez rien ! c'est parfait !
  
  Ah si, le lien vers API
  IMHO ne sert à rien, je ne pense pas que qui ne sait ce qu'est une API ait survécu aux cgroups et memcg avant d'attaquer la byte queue limits !
# power

Posté par mw4rf le 19 mars 2012 à 11:55. Évalué à 4.

Ohmagad ! D'après les tests effectués le gain est important puisqu'il peut atteindre 5 watts sur un portable Thinkpad X220 au repos.

C'est beau :) Je vais tester ça ce soir !

TPX220 9-cell, arch avec rc6 activé, bureau gnome 3 de base, wifi + firefox, governor ondemand, ça tient à peu près 5 heures.
- [^] # Re: power
  
  Posté par BAud (site web personnel) le 21 mars 2012 à 15:57. Évalué à 5.
  
  et donc, cela donne quoi finalement ?
# Un jour trop tard...

Posté par Guillaum (site web personnel) le 19 mars 2012 à 13:08. Évalué à 6.

Voila, cela faisait plusieurs semaines que j'attendais ce noyau comme si il s’agissait du saint Graal pour la réduction de la consommation d’énergie. Et paf, voila que l'on me vole mon ordinateur la veille de la sortie… Damn ! Je ne saurais jamais.

Alors, chez vous cela consomme moins ?
- [^] # Re: Un jour trop tard...
  
  Posté par Jeanuel (site web personnel) le 19 mars 2012 à 14:23. Évalué à 10.
  
  En tout cas, chez toi ça ne consomme plus du tout. Réduction de 100% donc !
  - [^] # Re: Un jour trop tard...
    
    Posté par Guillaum (site web personnel) le 19 mars 2012 à 14:52. Évalué à 1.
    
    Oui, better kernel ever ;)
    - [^] # Re: Un jour trop tard...
      
      Posté par Julien Fontanet (site web personnel) le 19 mars 2012 à 15:00. Évalué à 6. Dernière modification le 19 mars 2012 à 15:01.
      
      « best » :o
      
      Sinon, je compatis pour la perte de portable, c'est un coup dur :(
      - [^] # Re: Un jour trop tard...
        
        Posté par Guillaum (site web personnel) le 19 mars 2012 à 16:48. Évalué à 3.
        
        Merci (pour la correction et la compassion) ;)
# juste une typo récurrente…

Posté par Jiehong (site web personnel) le 19 mars 2012 à 15:28. Évalué à 4.

… on voit, de temps en temps, se balader des « oe » qui devraient êtres des « œ » mais sinon, c'est toujours un grand plaisir que de lire les dépêches des sorties des noyaux.
- [^] # Re: juste une typo récurrente…
  
  Posté par erdnaxeli (site web personnel) le 19 mars 2012 à 16:55. Évalué à 1.
  
  Toi tu tapes avec un clavier en bépo. J'en veux pour preuve le « … » au début de ton message.
  
  Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
  - [^] # Re: juste une typo récurrente…
    
    Posté par O'neam Anne le 19 mars 2012 à 17:28. Évalué à 1.
    
    J'ai un azerty en France (alternative), et j'utilise aussi des …. Avec Maj+AltGr+, .
    D'ailleurs, je suis obligé de remettre en permanence le clavier avec le bon layout à cause de ce vilain bug dans Xorg :
    https://bugs.freedesktop.org/show_bug.cgi?id=43541
    
    LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
  - [^] # Re: juste une typo récurrente…
    
    Posté par Thomas Debesse (site web personnel) le 19 mars 2012 à 17:31. Évalué à 2.
    
    Pas nécessairement, moi-même je n'ai pas encore basculé complètement au bépo, ce présent message est écrit avec un agencement français azerty (sur un clavier UK) et je peux faire … → œŒ æÆ éÉ èÈ ¿? !¡ ⁽⁻¹²³⁴⁵⁶⁷⁸⁹⁰⁾ « » “” ‘’ etc.
    
    ce commentaire est sous licence cc by 4 et précédentes
  - [^] # Re: juste une typo récurrente…
    
    Posté par Il Palazzo-sama (site web personnel) le 19 mars 2012 à 22:24. Évalué à 4. Dernière modification le 19 mars 2012 à 22:26.
    
    C’est un faux bépoiste, il n’utilise pas l’apostrophe courbe. :o
    
    (il utilise le « ' » à la place, que chaque utilisateur du bépo sait ne pas exister en langue française)
    - [^] # Re: juste une typo récurrente…
      
      Posté par Guillaume Knispel le 20 mars 2012 à 06:58. Évalué à 10.
      
      Putain, pour écrire un livre en français ou je sais pas quoi, ok, mais les putains de quotes stylés y a des abrutis qui ont trouvé le moyen de les mettre en tant que localisation des messages de gcc quand on est en en_US-UTF8, et je les hais.
      A jamais.
  - [^] # Re: juste une typo récurrente…
    
    Posté par zebra3 le 20 mars 2012 à 14:48. Évalué à 4.
    
    Pas besoin de bépo, il suffit d'une touche compose (je tapes des …, des œ ou des æ en azerty).
    
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: juste une typo récurrente…
    
    Posté par jeberger (site web personnel) le 20 mars 2012 à 21:34. Évalué à 3.
    
    « compose » « . » « . » → « … »
    
    Ce message a été écrit avec un clavier Azerty standard, avec l'option « Option "XkbOptions" "compose:menu" » dans la config du serveur X…
    
    PS : Note que cette possibilité n'a rien de nouveau : je l'utilise depuis près de 15 ans !
- [^] # Re: juste une typo récurrente…
  
  Posté par mgoeminne (site web personnel) le 20 mars 2012 à 08:04. Évalué à 2.
  
  Pour rester dans le domaine des petits défauts:
  
  ashmem et pas hashmem
  
  Sinon merci pour cette lecture. Il va bientôt falloir penser à écrire un livre…
  - [^] # Re: juste une typo récurrente…
    
    Posté par BAud (site web personnel) le 20 mars 2012 à 08:45. Évalué à 2.
    
    bien vu, corrigé, j'ai ajouté la signification en clair pour la peine.
# /proc pour toujours ?

Posté par rpnpif le 19 mars 2012 à 16:29. Évalué à 8.

J'avais été abusé par une rumeur qui disait que /proc, obsolète serait remplacé par /sys. Est-ce toujours d'actualité ? Ou les deux coexisteront-ils ?
- [^] # Re: /proc pour toujours ?
  
  Posté par Troy McClure (site web personnel) le 20 mars 2012 à 20:34. Évalué à 3.
  
  ça serait vraiment une belle connerie de supprimer proc étant donné le nombre d'applications qui dependent des informations qui s'y trouvent (et qui de plus ne sont pas dispo dans /sys)
- [^] # Re: /proc pour toujours ?
  
  Posté par Sylvain Sauvage le 22 mars 2012 à 21:54. Évalué à 3.
  
  En gros :
  /proc → infos sur les processus (et sur le noyau et ses modules)
  /sys → infos et contrôle du noyau et de ses modules
# Merci beaucoup

Posté par kubrick le 19 mars 2012 à 17:39. Évalué à 8.

Salut,

Un grand merci pour cette chronique détaillée et bien faite. Je félicité sincèrement ses auteurs, en particulier patrick_g pour sa constance et sa ponctualité.

Beaucoup de monde s'est essayé aux chroniques périodiques (je pense aux nombreux auteurs de la Wine Weekly Newsletter notamment) mais peu tiennent le coup dans la durée, ça demande beaucoup de discipline et de travail alors si ça peut aider : merci et bravo.

Je lis la plupart des actualités Linux/libre en anglais, parce que généralement c'est plus "frais" et moins sporadique et que je suis dans un environnement anglophone, mais je me rue toujours sur LinuxFR.org à la sortie d'un nouveau noyau.

Quand au liens, je les trouve fort utiles, car malgré une traduction de qualité, je préfère les railleries de Linus en version originale, et j'aime creuser certains sujets.

Continuez comme ça, c'est parfait.

François.
- [^] # Re: Merci beaucoup
  
  Posté par Yves Bourguignon le 19 mars 2012 à 21:56. Évalué à 3.
  
  Je lis la plupart des actualités Linux/libre en anglais
  
  Tu pourrais (c'est une vraie question en forme d'invitation), avec un copié-collé bien ajusté ou une traduction rapide d'un titre ou un peu plus, nous faire un journal ou juste une annonce dans l'espace de rédaction sur ce que tu repères de frais et d'important pour que quelqu'un s'en empare si tu n'as pas le temps de faire plus ?
  - [^] # Re: Merci beaucoup
    
    Posté par kubrick le 20 mars 2012 à 01:52. Évalué à 1.
    
    Ben tiens oui pourquoi pas si c'est gratuit (les anglois ont toujours du mal avec "free") et sans obligation d'achat.
    
    Je promets d'essayer :)
# Je suis du même avis que Linus \o/

Posté par Olivier Esver (site web personnel) le 19 mars 2012 à 21:19. Évalué à 2.

À propos de PAE (à l'inverse des mecs d'Ubuntu), ça fait plaisir de lire ses commentaires :)

S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
# driver rtl8192cu ...

Posté par Christophe Turbout le 20 mars 2012 à 08:40. Évalué à 2.

Je profite de la dépêche pour savoir si quelqu'un a testé avec ce nouveau noyau le driver rtl8192cu de staging pour le mini wireless belkin n300 usb ?

j'en ai vraiment besoin mais j'ai pas trop le temps de tester donc c'est juste pour savoir si je vais le prendre tout de suite dans debian expérimental ou bien si je devrais aller acheter un autre dongle !

merci.
- [^] # Re: driver rtl8192cu ...
  
  Posté par ymorin le 20 mars 2012 à 15:20. Évalué à 2.
  quelqu'un a testé avec ce nouveau noyau le driver rtl8192cu […] ?
  
  Le rtl8192cu n'est pas dans staging, mais bien dans les drivers officiels, comme sous-pilote du rtlwifi :
```
drivers/net/wireless/rtlwifi/rtl8192cu
```
  Le pilote qui est dans staging est le pilote pour le rtl8192u.
  
  J'ai un rtl8192cu et un rtl8192ce à la maison. Je vais les tester ce soir. Ils ne fonctionnaient pas avec le dernier 3.2, et vu les logs du 3.3, j'ai peu d'espoir…
  
  Je vais aussi regarder le rtl8192u pour voir si il peut remplacer le rtl8192cu, ou si c'est un autre chip incompatible.
  
  Hop,
  Moi.
# Merci

Posté par JoeltheLion (site web personnel) le 20 mars 2012 à 09:31. Évalué à 1.

Merci pour cette news très intéressante et tellement agréable à lire!
# Serpent et anti-EFI

Posté par antistress (site web personnel) le 21 mars 2012 à 18:12. Évalué à 4. Dernière modification le 21 mars 2012 à 18:12.

Merci pour ce, journal très détaillé. Il m'a paru un peu plus complexe que d'habitude mais c'est peut être que je connais moins les sujets abordés cette fois.

Concernant Serpent, comment en profiter ? Est-ce aux logiciels applicatifs de l'implémenter ou à la distribution de l'activer ?

Concernant le patch pour permettant de contourner l'EFI si j'ai bien compris, même question : comment en profiter ? est-ce aux distributions d'y recourir ?
- [^] # Re: Serpent et anti-EFI
  
  Posté par patrick_g (site web personnel) le 22 mars 2012 à 21:41. Évalué à 5.
  
  Concernant Serpent, comment en profiter ?
  
  Les programmes en espace utilisateur qui offrent le choix de l'algorithme Serpent vont simplement utiliser les primitives cryptographiques du noyau. Rien à activer.
  
  Concernant le patch pour permettant de contourner l'EFI
  
  Là ce sont les distros qui feront le boulot (si elles veulent profiter de ça).
  - [^] # Re: Serpent et anti-EFI
    
    Posté par antistress (site web personnel) le 23 mars 2012 à 18:15. Évalué à 1.
    
    Merci :-)
# nouveau

Posté par s3boun3t le 21 mars 2012 à 23:51. Évalué à 1.

dans combien de temps/quel kernel ? pourra t'on voir le changement des fréquences automatique pour le pilote nouveau ?
- [^] # Re: nouveau
  
  Posté par patrick_g (site web personnel) le 22 mars 2012 à 21:37. Évalué à 4.
  
  Il faut poser la question aux développeurs de Nouveau.
  Je sais que Stéphane Marchesin et Martin Peres sont inscrits sur LinuxFr, peut-être qu'ils passeront par là pour répondre.
- [^] # Re: nouveau
  
  Posté par ymorin le 23 mars 2012 à 19:36. Évalué à 4.
  
  Réponse a ta question :
  
  There's really no good reason for us to be in here anymore, we have to maintain this ABI anyway to avoid angering people.
  
  Hop,
  Moi.
  - [^] # Re: nouveau
    
    Posté par patrick_g (site web personnel) le 23 mars 2012 à 20:28. Évalué à 3.
    
    Ce qui ne répond pas à sa question sur le changement de fréquence.
    Là c'est juste nouveau qui sort de -staging.
    - [^] # Re: nouveau
      
      Posté par ymorin le 23 mars 2012 à 22:12. Évalué à 4.
      
      Ce qui ne répond pas à sa question sur le changement de fréquence.
      
      Mais qui répond à sa première question, même si elle n´était pas très explicite :
      
      [nouveau] dans combien de temps/quel kernel ?
      
      La fréquence, c´était sa seconde question. ;-)
      
      Hop,
      Moi.
# Statistiques²

Posté par Thomas Debesse (site web personnel) le 22 mars 2012 à 20:03. Évalué à 3.

15 millions de lignes dans le noyau 3.3…

…et 15 mille mots pour le présenter ;)

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Statistiques²
  
  Posté par Sylvain Sauvage le 22 mars 2012 à 21:56. Évalué à 2.
  
  Ça fait un seul mot pour mille lignes de code…
  
  … et encore, il y a des mots qui se répètent alors que le code ne devrait pas se répéter.
# Commit sur la gestion de FAT

Posté par Sylvain Sauvage le 22 mars 2012 à 22:05. Évalué à 3.

Un message de 389 lignes pour un patch qui supprime trois lignes (deux de code et une vièrge), ça c’est du commentaire comme on aimerait parfois en voir, notamment quand on passe derrière certains… Bon, ok, soyons réalistes, mais est-ce que je pourrais au moins avoir des noms de variables significatifs ?

D’un autre côté, je me demande ce qui empêchera un petit nouveau de remettre ce code (ou approchant) dans un an ou deux…
- [^] # Re: Commit sur la gestion de FAT
  
  Posté par patrick_g (site web personnel) le 23 mars 2012 à 08:00. Évalué à 4.
  
  Ne pas oublier que le changement ne se résume pas à ces quelques lignes. Dans la brève j'ai cité au moins 3 autres patchs de Mel Gorman qui concernent le même sujet.
# A propos de memcg

Posté par djano le 23 mars 2012 à 00:40. Évalué à 2.

Il est donc rassurant de constater que des simplifications sont encore possibles sans impact sur les performances.

Ce n'est pas l'avis de l'article LWN qui comme dans de tel changements dit: "il n'est pas a exclure qu'il y ait des régressions avec certaines charges de travail spécifiques".
# Ah que que!

Posté par djano le 23 mars 2012 à 00:41. Évalué à 3.

Il y a 2 typos dans la dépêche.

Une:

Si ensuite je décide que ~~que~~ tout le trafic réseau sortant sur l'interface eth0

Et deux:

Si Vinton Cerf à raison et que ~~que~~ chacun des acteurs trouve un intérêt égoïste
- [^] # Re: Ah que que!
  
  Posté par BAud (site web personnel) le 23 mars 2012 à 07:39. Évalué à 2.
  
  Merci, corrigé.
- [^] # Re: Ah que que!
  
  Posté par steph1978 le 25 mars 2012 à 23:23. Évalué à 3.
  
  il y a aussi
  
  d'un d'un processeur
  
  dans Architecture C6X
  
  preuve que nous lisons de manière attentive et jusqu'au bout.
  merci pour la dépêche.
  - [^] # Re: Ah que que!
    
    Posté par BAud (site web personnel) le 26 mars 2012 à 00:13. Évalué à 2.
    
    Bien vu, corrigé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.