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 plate-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 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 terme 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 buffers TCP. C'est certainement un ajout bienvenu, mais il faut le reconnaitre, ce n'est pas une amélioration radicale de ce contrôleur.
En revanche, avec les patchs 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 ?
Le management 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 toute 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 non évinçables (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 que, au moment de 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 a é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 suboptimale et qu'il fallait revoir profondément ce mécanisme pour mieux intégrer le mécanisme de « control group » dans Linux. C'est ce qu'a annoncé Johannes Weiner dans son mail de mai 2011 ou il présentait son travail :
L'idée à long terme est de ne plus avoir memcg boulonné sur le code de management 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 du ê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 taille différentes. La pression devrait également se distribuer de façon proportionnelle entre les memcgs au lieu d'avoir des reclaim 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 :
Commes 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 Go de RAM :
- Taille du
page_cgroup avant le patch = 31 457 280 octets (30 Mo)
- Taille du
page_cgroup après le patch = 15 728 640 octets (15 Mo)
Bien entendu, c'était une des conditions pour l'intégration des patchs, que ces gains en terme de simplicité du code et en terme 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 benchmarks et en voici un exemple parmi d'autres.
Fichier de type « sparse file » de 100 Go géré dans un cgroup de 1 Go (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 terme 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 patchs 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 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
