Noyau Sortie du noyau Linux 3.5

111
22
juil.
2012
Noyau

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

P.‐S. : Comme annoncé précédemment, cette dépêche raccourcie a fait l’objet d’un travail en collaboration dans la tribune de rédaction. Je remercie les personnes suivantes qui ont participé à l’élaboration du texte : reno, Sébastien Koechlin, Laurent Wandrebeck, Christophe Turbout, detail_pratique, baud123, Tibo, jcr83, Denis Dordoigne, Xavier Claude, Jarvis, Barret Michel, lay, mike.simonson, Benoît, tinram.

Sommaire

La phase de test

-rc1

La version -rc1 a été annoncée par Linus le 3 juin 2012 :

Je l'ai donc mise à disposition hier, mais je n'ai pas écrit de message à ce propos parce que je ne me sentais pas d'attaque.
C'est une version assez classique — grosso-modo 60 % pour les pilotes, 20 % de mises à jour dans arch, et 20 % un peu partout ailleurs — systèmes de fichiers, documentation, outils, etc.
Rien de particulier ne me vient à l'esprit — il y a quelques problèmes de compactage de la mémoire pour lesquels une discussion est en cours, mais je ne pense pas qu'il y ait quoi que ce soit de particulièrement effrayant ou spécial qui sorte du lot dans cette -rc1.
Ci-dessous se trouve mon « journal résumé des merges » — en grande partie généré automatiquement à partir de mes messages de fusions. Il y a probablement quelques merges manquants simplement dues au fait qu'il est généré à partir de mes messages non formatés qui tendent à avoir un format particulier, mais si j'ai merdé quelque part, cela n'aura pas forcément déclenché mon grep. Notez aussi que le « de xyz » concerne la personne qui m'a envoyé la demande d'inclusion, et non qui l'a codée (et quelques dépôts — arm-soc et x86 en particulier — tendent à avoir plusieurs mainteneurs, donc la personne m'envoyant la demande d'inclusion n'est pas forcément l'unique propriétaire du dépôt, juste le « point de contact »).
Selon vos centres d'intérêt, vous pourrez être intéressés par l'ordonnanceur de paquets CoDel, ou par les mises à jour des pilotes GPU, ou par les nouvelles cibles SCSI. Il y a un peu de tout pour pratiquement tout le monde.

-rc2

La version -rc2 est sortie le 8 juin 2012 :

Ok, cela ne fait que 6 jours, mais comme dit précédemment je serai en voyage à partir de demain, et je voulais rendre la -rc2 disponible avant de partir.
J'aurai accès à internet, mais à voir mon agenda, je n'aurai probablement pas beaucoup de temps, donc vous feriez mieux de me considérer comme absent durant une semaine. Autrement dit, s'il n'y a rien de vraiment critique, ne vous fatiguez pas à me demander d'inclure votre travail. Voyez ça comme une de ces semaines où je fais mon difficile sur tout, et deviens grincheux quand les gens m'envoient des petits machins sans pertinence qui ne sont pas des correctifs pour des oops importants.
Cela dit, je pense que -rc2 est plutôt en bon état, et j'ai tenté de retirer de manière assez agressive les modifications qui posaient problème (et parfois les choses qui n'étaient que suspectées d'être la cause de problèmes).
Nous avons l'assortiment habituel de correctifs : pilotes (gpu, i2c, acpi, clocksource), architectures (principalement x86 perf, mais aussi quelques trucs triviaux pour powerpc et parisc), systèmes de fichiers (fuse, cifs, ext4, ubifs), le tout accompagné de mises à jour VM, de la documentation, et des correctifs timer, irq et ordonnanceur.
En avant pour les tests.

-rc3

La version -rc3 est disponible depuis le 16 juin 2012 :

À cette étape, je souhaite toujours qu'il y ait moins de modifications dans les versions -rc, mais -rc3 est disponible, et bien qu'elle pourrait être plus petite (il y a à peine moins de 300 modifications), ce n'est pas trop mal.
La semaine a démarré tranquillement avec juste quelques petites modifications, où les gens semblaient vraiment me faciliter la vie en déplacement – merci. Mais ça a quelque peu dégénéré en cours de route, et je pense que plus de la moitié des demandes d'inclusions de modifications sont arrivées durant les deux derniers jours et étaient plus invasives aussi.
Bon c'est comme ça…

-rc4

Linus a rendu la version -rc4 disponible ce 24 juin 2012 :

Une nouvelle semaine, une nouvelle -rc.
Beaucoup de petits correctifs ici. Je pense que la plus grosse (en nombre de lignes) modification est le correctif de la fonctionnalité kmsg_dump() qui a été cassée du fait du nouveau mécanisme d'enregistrement des messages du noyau.
Ainsi, alors que nous avons 200+ modifications dans cette -rc, elles sont toutes plutôt petites et insignifiantes. Bien sûr, si ce problème dorénavant corrigé vous a frappé (ou que vous êtes le développeur de ces lignes de code révolutionnaires ;), vous serez éventuellement en désaccord avec la partie « insignifiante », mais d'après moi, c'est ainsi que j'aime les -rc à cette étape.
Les statistiques pour les -rc sont somme toute étonnantes : quasi exactement un tiers pour les architectures, les pilotes et le « reste ». Habituellement les pilotes dominent la mêlée, mais je devine que cette fois nous n'avons pas eu que les patchs pour la plate-forme arm, mais aussi pas mal de mises à jour diverses du côté des systèmes de fichiers et de la documentation ce qui aboutit à cette répartition inhabituelle.
Toutefois, espérons que la tendance aux corrections triviales continue, et nous serons en bonne voie pour la mise à disposition de la version 3.5.

-rc5

La version -rc5 a été mise à disposition par Linus le 30 juin 2012 :

À nouvelle semaine, nouvelle -rc. Celle-ci est plus classique que la rc4, vu que les pilotes représentent à nouveau 60+%. Probablement du fait des modifications de la pile réseau, ajoutées depuis la rc4.
Les stats ont l'air plus crades, parce que bien que les modifications étaient globalement petites, la correction de printk ressort clairement. Mais c'était une vraie régression par rapport au 3.4, donc ce n'est pas comme si c'était contestable. UDF est également devenu plus prudent au moment de monter des systèmes de fichiers corrompus – et c'est aussi visible dans les stats – mais c'est en partie dû au fait que les vérifications ont été nettoyés et déplacées dans une fonction, en les rendant plus complètes. Donc les changements effectifs sont plus petits qu'ils n'en ont l'air.
Bref, pas de quoi s'inquiéter à ce stade. Malgré le merge de la pile réseau (qui est plutôt dodu), -rc5 est plus petite que -rc4, même s'il y a quelques commits de plus ; ça va dans la bonne direction.
En résumé : mises à jour réseau, corrections de systèmes de fichiers, quelques petites mises à jour d'architectures (x86, arm, ppc) et un peu de bruit aléatoire.
Dites-moi (sur lkml) si vous avez encore des régressions.

-rc6

La version -rc6 a été mise à disposition par Linus le 7 juillet 2012 :

Une semaine de plus, une -rc de plus. Et heureusement une semaine de calme. Sensiblement moins de commits dans celle-là que dans la -rc5, et je pense que nous sommes proche de la version finale.
Cela dit, c'est également l'été (nos co-développeurs australiens peuvent ne pas être d'accord mais ils sont en minorité), et avec ça je voulais également parler de la nouvelle fenêtre de merge. Parce que je suspecte notamment que beaucoup de développeurs européens sont partis en vacances ou sont en train de se préparer à le faire. Août a tendance à être une période de basse saison pour beaucoup de gens. J'espère que les projets de cet été ne sont pas majoritairement responsables du ralentissement du nombre de patches dans cette rc, mais je soupçonne que la prochaine fenêtre de merge sera presque inévitablement complètement éclipsée pour les développeurs en vacances.
C'est normal, et j'espère que ça va signifier que la sortie de la 3.6 va être plus calme. Je demande aux personnes qui vont en vacances de ne pas m'envoyer leurs patches dans la fenêtre de merge avant de partir. Je préfère vraiment avoir des merges différés à la 3.7 qu'un développeur qui m'envoie les gros changements puis disparait pour la publication des rc.
En tout cas, gardez ça en tête, particulièrement ceux d'entre vous qui prévoient de partir tout le mois d'août.
Retour sur les trucs de la -rc6 : il y a principalement des changements sur btrfs et md dans celle-là, avec des modifications classiques sur les pilotes, des mises-à-jour de Arm, des modifications réseaux, et quelques trucs aléatoires (dont de la doc etc). Rien de bien effrayant, cette rc est plutôt petite, sans toutes ces petites modifications habituelles… Je joins le résumé des mises-à-jour.

-rc7

La version -rc7 a été mise à disposition par Linus le samedi 14 juillet 2012 :

Hé les gars, vous vous rappelez que les modifications se calmaient et ralentissaient, et que les développeurs du noyau étaient partis en vacances ?
Bon, on va devoir reparler de tout ça. Parce que la semaine passée je pensais que faire une -rc7 n'était pas tout à fait nécessaire, à part peut-être pour vérifier les derniers changements dans printk. Mais entre aujourd'hui et hier, j'ai reçu pleins de petites demandes de pull, et maintenant je me retrouve à livrer une -rc7 qui est plus grande que la -rc6.
C'est pas sympa, les gars. Pas cool.
Cela dit, il est vrai que la plupart de ces changements sont plutôt petits. Le patch de correction du calcul loadavg est plutôt gros, mais la majeure partie de ce patch est de l'ajout de commentaires (de longs commentaires).
Mais il y a la série de patchs d'Andrew, il y a les corrections dans media, les corrections un peu partout dans les systèmes embarqués, les corrections pour les powerpc, l'usb, le son, et j'en passe.
Alors d'accord ce n'est pas énorme, mais les modifications sont bien plus nombreuses que pour la -rc6. J'espérais le contraire.
Mais allez-y et testez. Assurez-vous que tout est bon. Parce que je ne voudrais vraiment pas avoir à faire une -rc8.

Les nouveautés

Algorithme CoDel

L'algorithme CoDel a été intégré dans le noyau Linux 3.5. Il constitue une réponse partielle au fameux problème du « bufferbloat » décrit dans la dépêche du noyau 3.3.
Pour résumer, il s'agit de changer le comportement de TCP afin d'éviter l'engorgement des buffers (les mémoires tampons) : quand un buffer est trop rempli par un fichier à envoyer (par exemple), les requêtes interactives (Web, SSH, etc.) sont ralenties car traitées après, il y a donc un équilibre à trouver dans le remplissage des buffers pour être efficace sans augmenter trop la latence..
Les algorithmes actuels utilisés dans TCP sur-utilisent ces buffers ce qui pénalise la latence : CoDel devrait corriger cela.
Notons quand même que tous les buffers induisent de la latence : ceux de l'application, de la pile TCP, de la carte réseau, de la box internet, des routeurs du FAI, etc., une modification de Linux est donc nécessaire mais pas forcément suffisante…

Pour plus d'information sur CoDel, voir cet article LWN.

x86

Le code gérant les exceptions pour l'architecture x86 a été entièrement revu.
C'est un grand nettoyage qui a été opéré sur ce code par David Daney et H. Peter Anvin avec comme but de permettre le tri de la table des exceptions lors de l'étape de compilation (avec l'option BUILDTIME_EXTABLE_SORT). De cette manière on peut gagner un peu de temps lors du boot puisque le tri est déjà fait et on supprime pas mal de vieux code:

Cette nouveauté a nécessité l'abstraction du protocole de la table des exceptions et a permis de retirer 20 ans de présupposés qui s'étaient accumulés au sujet du format de la table des exceptions. Le résultat de tous ces changements c'est que le code de gestion des exceptions x86 est maintenant très propre et moderne.

EDAC

Toujours dans le domaine de la gestion des erreurs, le développeur Mauro Carvalho Chehab a posté plusieurs patchs qui améliorent le sous-système EDAC (Error Detection And Correction). Il s'agit ici de gérer les erreurs qui peuvent survenir au sein des barrettes de RAM (mémoire vive) de nos machines. Jusqu'à présent ce code reposait sur des présupposés techniques qui n'ont plus lieu d'être avec les contrôleurs mémoire des processeurs modernes. Depuis l'introduction des technologies RAMBUS et FB-DIMM il est devenu nécessaire de repenser ce code sous peine d'obtenir des messages d'erreurs peu exploitables. Dans l'intervalle les pilotes des différents chipsets ont dû mentir au sous-système EDAC afin de pouvoir fonctionner correctement.
La refonte du code introduite dans le noyau 3.5, et qui modifie l'ABI interne, permet maintenant d'exposer au sous-système EDAC la technologie réelle qui est employée dans les barrettes mémoire. Les messages d'erreur sont plus explicites et ils permettent d'indiquer la zone physique touchée par l'erreur.
Bien entendu tous les pilotes de chipsets ont été convertis pour utiliser cette nouvelle version de l'ABI EDAC.

Btrfs

Dans son courriel récapitulatif, Chris Mason liste les principales nouveautés du noyau 3.5 concernant le système de fichiers Btrfs.
La gestion des erreurs s'améliore avec cette version. Stefan Behrens a introduit un moyen de compter les erreurs qui surviennent sur un disque, ce qui permet de mettre à l'écart ceux qui produisent trop d'erreurs, car il y a beaucoup de chances qu'ils soient défectueux. Les erreurs prises en compte sont les erreurs de lecture/écriture, les erreurs de CRC et les erreurs lors des vérifications des blocs de métadonnées.
Un bug qui pouvait provoquer de grosses latences a été corrigé. Le problème était que le writeback n'était pas considéré comme complet tant que les métadonnées sur les extends n'étaient pas écrites. Josef Bacik a utilisé un mécanisme existant qui surveille les insertions de métadonnées en attente pour terminer le writeback plus tôt.
Jan Schmidt a travaillé sur le suivi des blocs des btree lors du changement de propriétaire. Le code n'a, pour l'instant, pas d'utilité, mais le sera lorsque les fonctionnalités de quotas sur les sous-volumes et sur les envois/réceptions seront intégrées.

Ext4

La grosse nouveauté Ext4 de ce noyau est la possibilité de générer un code de redondance cyclique de type CRC-32 sur les métadonnées du système de fichiers. Les codes cycliques redondants permettent, en échange d'une consommation plus importante de l'espace disque, à la fois de détecter et de réparer les données corrompues.

Dans la pratique, lorsqu'une corruption est détectée il est possible de ne monter le système de fichiers qu'en lecture seule afin d'éviter des pertes de données sur les systèmes corrompus. Cette fonctionnalité s'active via tune2fs si vous ne voulez par reformater votre partition. Par contre, un noyau antérieur à cette version ne pourra, dans tous les cas, que monter le système de fichiers en lecture seule. De plus fsck est capable d'utiliser cette information pour réparer le système de fichiers.

Voir cet article LWN sur la surveillance des métadonnées via CRC-32.

NUMA

Depuis plusieurs années le noyau Linux offre l'option CONFIG_NUMA lors du build ce qui permet d'adapter l'ordonnanceur et l'allocation de mémoire afin de tirer partie des architectures NUMA.
L'architecture Numa est une architecture conçue pour des systèmes comprenant de nombreux cœurs de calcul sur un même processeur. Le problème avec ce genre d'architecture est comme toujours de garantir la cohérence des données contenue dans la mémoire. Il existe deux techniques différentes pour répondre à ce problème. L'architecture NUMA et SMP. Dans l'architecture SMP toute la mémoire est accessible par un seul et unique bus.
C'est une solution simple mais qui pose de nombreux problèmes d'accès concurrents et de cohérence du contenu de la mémoire. En effet il faut s'assurer qu'on ne modifie pas une donnée qui est elle-même en train d'être modifiée par un autre cœur.
Pour Numa on a au contraire un bus et une mémoire réservés par cœur de calcul (un node). Cette solution simplifie le problème de cohérence et d'accès mais introduit aussi un problème de distance quand un cœur a besoin d'une valeur calculée par un autre.
C'est le développeur Peter Zijlstra qui a entrepris de repenser complètement cette option en rendant le code plus souple et mieux adapté aux configurations matérielles sous-jacentes. Il n'y a plus de couches fixes et tout se base maintenant sur la fonction node_distance(), ce qui permet d'éliminer toutes les tables d'initialisations SD_NODE_INIT pour les diverses architectures.

Autosleep

Le projet de fusion des modifications d'Android dans le noyau Linux a commencé en décembre 2011. Le point le plus controversé concerne l'implémentation des "wakelocks" (que l'on pourrait traduire en "verrouillage en mode réveillé"). Normalement les machines sous Android se mettent en veille à la moindre occasion puisque c'est l'état par défaut du système. Le mécanisme "wakelocks" permet à certains logiciels de bloquer le passage en veille du système afin de pouvoir exécuter une tâche. Cette technique, qui empêche une application mal écrite de vider la batterie en consommant du CPU en permanence, est vivement critiquée par les développeurs du noyau, aussi bien sur la forme (la qualité du code d'Android) que sur le fond (l'intérêt de contourner le problème d'une application en complexifiant le noyau).

La fusion n'étant pas envisageable actuellement, Rafael Wysocki a élaboré une méthode alternative: autosleep. Elle se base sur un mécanisme mis en place dans le noyau 2.6.36 (oct. 2010) dans lequel un événement (comme l’appui sur un bouton) peut réveiller ou maintenir le système éveillé. Rafael a ajouté un fichier /sys/power/autosleep qui permet de spécifier une mise en veille automatique en mémoire ou sur disque en l'absence d'événement bloquant.
Il a également ajouté, à l’image d’Android, un journal des événements bloquants afin de connaître l’origine du maintien en activité ; et une interface permettant à une application disposant des droits nécessaires de bloquer la mise en veille pour un certain temps.

L’API est très similaire à celle d’Android dans le but de faciliter le fonctionnement d’une application Android sur un noyau ordinaire. Bien entendu personne ne sait si les développeurs d'Android vont chercher à tirer partie de cette nouvelle fonction en abandonnant progressivement wakelocks.

Voir cet article LWN sur autosleep.

Filtres Seccomp

Jusqu'à présent Linux n'offrait pas de moyen simple pour restreindre les appels systèmes utilisables par une application. C'est pourtant intéressant quand on veut compliquer autant que possible la vie d'un attaquant potentiel. Les développeurs de Chrome ont réussi à réaliser cette fonctionnalité sur Linux, mais leur solution est très compliquée, intégrant même un désassembleur x86 !
Le patch de Will Drewry introduisant le filtrage Seccomp des appels système via BPF devrait permettre de simplifier beaucoup les choses.

La technique repose donc, de façon étonnante, sur l'outil Berkeley Packet Filter qui est normalement utilisé pour filtrer les paquets réseau. Ici le mécanisme est réutilisé pour filtrer les appels systèmes en déclarant une liste blanche des appels autorisés. L'idée est que les développeurs d'applications, qui par définition connaissent parfaitement leur code, pourront créer un filtre Seccomp afin de déclarer la liste spécifique des appels autorisés pour leur application (voir la documentation).

S'il y a un accord sur l'utilité de filtrer les appels systèmes, il a tout de même fallu 3 ans avant qu'une solution soit acceptée par les développeurs et incluse dans le noyau. LinuxFr avait déjà parlé en début d'année de la saga des filtres seccomp.

Tracing

En regardant le courriel récapitulatif envoyé par Ingo Molnar on peut lister les améliorations du tracing incluses dans ce noyau 3.5.
On note tout d'abord que les possibilités de visualisation de l'outil perf ont été améliorées. Il est maintenant possible de faire des recherches ou de naviguer dans les résultats.
La technique IBS (Instruction-Based Sampling), qui est présente dans les derniers coeurs AMD, est maintenant exploitée par le noyau afin d'offrir des informations plus précises sur les cycles ou les micro-instructions utilisées lors de l'exécution d'un programme.
Enfin la nouveauté la plus importante est l'utilisation de la bibliothèque libtraceevent par l'outil perf. Cette bibliothèque permet de factoriser un certain nombre de lignes de code mais elle va surtout permettre à divers outils de se reposer sur elle dans le futur :

C'est le premier pas vers l'unification des outils de tracing et perf et cela offre également une bibliothèque de tracing sur laquelle les outils externes comme powertop peuvent s'appuyer.

User namespaces

Eric W. Biederman a écrit plusieurs patchs pour cette version du noyau afin de fiabiliser et d'améliorer la fonction d'isolation par conteneurs.
Puisque chaque UID peut être spécifique à un conteneur particulier, un nouveau type, nommé kuid_t est introduit afin d'identifier sans ambigüité les processus. L'isolation est plus propre entre l'hôte et les conteneurs qui sont hébérgés sur la machine. Ainsi l'utilisateur root sur un conteneur ne peut plus avoir un accès libre aux répertoires /proc/ et /sys/. Les capacités (capabilities) sont actives au sein de l'espace de nom du conteneur et on peut donc accorder sans risque ces capacités à l'utilisateur confiné dans le conteneur.
Enfin, d'après les tests effectués par Eric Biederman, les performances de ce sous-système rénové des conteneurs sont excellentes. Quand l'option n'est pas choisie à la compilation alors aucune dégradation n'est observée. Quand l'option est activée Eric à constaté un ralentissement extrêmement faible. Le test consistant à faire un milliard d'opérations stat passe de 156 secondes à 164 secondes sur son laptop.

Voir cet article LWN sur les améliorations de l'isolation par conteneurs.

Uprobes

Le patch uprobes, qui est utilisé pour placer des sondes dans les programmes en espace utilisateur, a enfin été inclus dans le noyau après des années d'attente. Il s'agit d'une sous-partie de SystemTap qui entre ainsi dans Linux pour faciliter le tracing des programmes.
Le message de commit de Srikar Dronamraju explique bien, avec force détails techniques, comment se fait ce placement de sondes tandis que ce second patch implémente l'interface avec perf.
Pour ce qui est d'expliquer l'utilité d'uprobes il faut se tourner vers ce message d'Ingo Molnar qui donne plusieurs exemples d'utilisation et qui souligne les bénéfices qu'apporte cette nouvelle fonction.

Amélioration du logging

La gestion du logging dans le noyau a évolué avec cette version 3.5.
Le but de ce patch est de passer d'un système de logging où on est orienté « flux d'octets » vers un système où on est orienté « enregistrement » (voir ce commit).
Pour le moment les messages peuvent facilement être corrompus sur leur chemin vers les logs. Par exemple, si il y a un buffer overflow, une partie des messages qui sont dans la mémoire tampon sera écrasée par les nouveaux messages.
De plus, les messages qui viennent de différents processeurs peuvent se mélanger, tout spécialement si un message de log est écrit par plusieurs coeurs.
Avec le patch de Kay Sievers le noyau place les logs dans un tampon afin d'éviter le mélange des différents flots de logs. Le patch apporte également des méta-informations comme le contexte spécifique du périphérique ou bien un numéro de séquence unique ce qui permet de flitrer plus efficacement les logs.

Au fil des versions candidates il s'est avéré que ce nouveau système de logging entrainant des conséquences inattendues sur la fonction printk().
Concrètement, quand on envoie un message dans le log en utilisant printk()

printk("mon début de super message de log ");
maSuperFonction1();
printk("la suite de mon super message de log ");
maSuperFonction2();
printk("la fin de mon super message de log. \n");

Les 3 appels à printk ci-dessus correspondent à une seule ligne dans syslog car tant qu'il n'y a pas de message se terminant par un retour chariot, le système de logging bufferise le message. Le problème avec cette technique c'est qu'avec le patch si quelque chose se passe mal le système de logging et le noyau se retrouvent bloqués.
Face à cette situation, les développeurs du noyau envisagent plusieurs solutions.

  • changer tous les appels à printk pour qu'il se terminent tous par un retour chariot ;
  • rajouter un printk_flush pour que les messages même partiels soient affichés si quelque chose se passe mal.

Le problème avec ces 2 solutions c'est qu'elles nécessitent de changer le code partout où le problème pourrait apparaître. Et l'expérience leur apprend que beaucoup de ces endroits ne peuvent être trouvés qu'en étant confronté au problème. Il y a donc trois solutions alternatives :

  • ajouter une option pour activer/désactiver le buffering ;
  • retirer ce patch de linux 3.5 ;
  • retirer le buffering de printk.

Linus s'est montré particulièrement en faveur de la dernière option. Il pense qu'il n'y a aucun souci à générer les logs dans un buffer mais qu'en revanche le texte généré par printk devrait être immédiatement envoyé sur la console.
Kay Sievers a donc écrit un patch spécifique pour résoudre cet agaçant problème affectant printk. Ce nouvel épisode met simplement en lumière la difficulté de rajouter de la structure aux logs sans rendre la vie difficile aux développeurs.

Voir cet article LWN au sujet du logging dans le noyau.

TCP connection repair

L'intérêt de cette fonctionnalité est de permettre la migration d'un conteneur actif d'un hôte physique vers un autre. Le problème, dans ce cas-ci, est de conserver les connexions réseau actives et surtout les paquets TCP (les paquets UDP n'offrant aucune garantie de livraison, on peut se permettre de les supprimer sans aller à l'encontre du fonctionnement attendu). Avant cette version du noyau, la plupart des informations nécessaires pour cette migration pouvaient déjà être obtenues au travers de /proc et /sys.

Pavel Emelyanov a écrit un patch pour obtenir les informations manquantes et pouvoir les insérer dans un nouvel hôte. Il faut d'abord mettre les sockets que l'on veut migrer dans un état « repair mode » grâce à l'appel système setsockopt() avec le paramètre TCP_REPAIR. Pour cela, il faut la capacité CAP_NET_ADMIN et que la socket soit dans un état « connexion établie » ou « fermée ». Une fois cela effectué, on peut obtenir les paquets dans les fils d'attentes d'entrée et de sortie, mais aussi les paramètres négociés avec l'hôte distant comme les MSS (maximum segment size, taille maximum de segment). Si une socket est fermée alors qu'elle est en état « repair mode », elle est simplement supprimée sans aucune notification à l'hôte distant.

Pour transférer ces sockets sur le nouvel hôte physique, il faut d'abord les créer normalement puis les passer directement en état « repair mode ». On peut réécrire les files d'attente des paquets avec l'appel système sendmsg(), il faut aussi introduire les paramètres négociés avec l'hôte distant. Un point important est de réintroduire les numéros de séquence, ils se suivent, mais le premier est généralement généré aléatoirement, ce qui ne doit pas être le cas ici.

Une fois qu'on est à peu près dans le même état qu'avant la migration, on appelle la fonction connect() sur la socket, le système va alors mettre directement la socket dans l'état « connection établie » sans échanger de message avec l'hôte distant. Finalement, une sonde de fenêtre (window probe) est envoyée à l'hôte distant et le trafic réseau peut reprendre normalement sur cette socket sur le nouvel hôte physique.

Voir cet article LWN sur TCP connection repair.

Pilote graphique AMD

Fin des travaux sur le tampon de profondeur hiérarchique (Hiz pour les intimes) pour les cartes de la génération Evergreen (HD 5xxx) et Northern Islands (HD 6xxx). Bien entendu les améliorations de performances sont au rendez-vous.

Pilote graphique Intel

Intel n'est pas en reste puisque en plus de la moisson habituelle de nettoyage et d'amélioration du code existant, cette version voit l'intégration du code pour deux nouveaux processeurs graphique.
La première n'est autre qu'Haswell le successeur d'Ivy Bridge. Elle confirme la tendance d'Intel à intégrer le code le plus tôt possible dans le noyau pour avoir un support optimal à la sortie du produit.
La deuxième nouveauté est encore plus intéressante car elle annonce le retour de solution graphique maison pour les processeurs de type Atom. La génération suivante d'Atom se nommera Valley View et elle incorporera un coeur graphique proche de celui utilisé dans les processeurs Ivy Bridge. Les premiers patchs ont été ajoutés au noyau Linux 3.5 et le travail sera complété dans les versions suivantes. Cela signifie, joie et bonheur, que les coeurs graphiques PowerVR ne seront probablement plus utilisés sur les processeurs basse consommation d'Intel.

  • # Ext4

    Posté par . Évalué à  10 .

    La grosse nouveauté Ext4 de ce noyau est la possibilité de générer un code cyclique redondant de type CRC-32 sur les métadonnées du système de fichiers. Les codes cycliques redondants permettent, en échange d'une consommation plus importante de l'espace disque, à la fois de détecter et de réparer les données corrompues.

    Dans la pratique, lorsqu'une corruption est détectée il est possible de ne monter le système de fichiers qu'en lecture seule afin d'éviter des pertes de données sur les systèmes corrompus. Cette fonctionnalité s'active via tune2fs si vous ne voulez par reformater votre partition. Par contre, un noyau antérieur à cette version ne pourra, dans tous les cas, que monter le système de fichiers en lecture seule. De plus fsck est capable d'utiliser cette information pour réparer le système de fichiers.

    Rah je n'ai pas eu beaucoup de temps pour aider sur cette dépêche…

    Ext4 a deux autres grosses nouveautés :

    Inline data

    Les tailles d'inodes sont prédéfinies (256o) et lorsqu'on n'utilise pas d'attributs étendus, de la place est perdue (ext4 utilise la moitié de la place). Pour les tout petits fichiers, il est maintenant possible de les stocker dans l'inode. Tao Ma's, l'auteur de cette fonctionnalité explique que sur ces tests il a réduit de 1% l'espace occupé pour l'ensemble du système et de 3% si on ne s'intéresse qu'à /usr.

    Il faut noter qu'avec ce patch, un fichier tout petit qui serait amené à grossir, devrait être déplacé de l'inode vers l'espace de stockage classique. Il faut donc bien tester la pertinence de la solution avant de l'utiliser en production (sur des clusters par exemple).

    Bigalloc

    Ce patch s'attaque au problème de performance que peut poser les très grandes tables d'allocation avec des blocs de 4Kio sur des grands espaces de stockage.

    Jusqu'à présent il était possible de définir des tailles de blocs plus gros pour gérer des système de fichiers qui gèrent quasiment que de gros fichiers. Cette solution manquait de souplesse, mais avais aussi d'autres inconvénients car elle impacte l'ensemble du systèmes comme les pages de cache.

    Le bigalloc consiste a ajouter la notion de grappe d'inode. Ainsi le système de fichier peut utiliser de grands blocs sans impacter le reste du système. Lorsqu'une allocation d'un seul bloc est demandé alors le système de fichier maintiendra une correspondance entre les blocs noyau et ceux du système de fichier.

    Cette solution permet un gain en espace disque car les tables d'allocation sont plus petites, mais aussi un gain lors des entrées sorties.

    Voila

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Pilote graphique AMD

    Posté par . Évalué à  7 .

    Petite erreur, le HIZ ne fonctionnera pas avec le pilote graphique AMD…
    Phornix : R600g Gallium3D HyperZ Defeats Developers

  • # nano erreur

    Posté par (page perso) . Évalué à  3 .

    une nano erreur : remplacer parsic par parisc ?

    • [^] # Re: nano erreur

      Posté par . Évalué à  5 .

      Quelques autres petites corrections

      -rc5 : plus petits qu'ils n'en ont l'air.

      Algorithme CoDel : les requêtes interactives

      Autosleep : disposant des droits nécessaires

    • [^] # Re: nano erreur

      Posté par . Évalué à  3 .

      Une autre dans le paragraphe sur autosleep : « Cette technique […] est vivement critiqué » => « critiquée ».

  • # Merci !!!

    Posté par . Évalué à  10 .

    C'est juste génial, merci pour toutes ces informations à chaque release !!!

    Continuez comme ça :)

  • # empeche ou permet

    Posté par . Évalué à  7 .

    'Le mécanisme "wakelocks" permet à certains logiciels de bloquer le passage en veille du système afin de pouvoir exécuter une tâche. Cette technique, qui empêche une application mal écrite de vider la batterie en consommant du CPU en permanence, '

    qui empeche-> qui permet plutot ?

    • [^] # Re: empeche ou permet

      Posté par . Évalué à  8 .

      Je ne crois pas. Ça permet de laisser le système éveillé sans avoir à maintenir une activité qui consommerait la CPU.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: empeche ou permet

        Posté par . Évalué à  4 .

        Quel intérêt de maintenir le système éveillé si aucune tâche n'est active ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: empeche ou permet

          Posté par . Évalué à  8 .

          J'avais un Nokia qui n'avais pas de flash, mais il avait une application lampe de poche qui affichait du blanc le plus lumineux possible à l'écran (en fait ça marche aussi si elle utilise le flash). Tu peut vouloir afficher une photo sur ton téléphone pendant 10min sans vouloir que ton écran s'éteigne.

          C'est le seul exemple qui me viens en tête mais il doit y en avoir d'autres.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: empeche ou permet

            Posté par . Évalué à  1 .

            Ben une lecture vidéo en plein écran, pendant qu'on bulle allongé dans le canapé devant le PC/la tablette.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: empeche ou permet

          Posté par (page perso) . Évalué à  6 .

          Parce que ça augmente la latence et ça éteint l'écran et qu'on ne veut pas que l'utilisateur attende une seconde quand il pousse sur un bouton et que l'écran s'éteigne alors qu'on était en train d'afficher une image.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: empeche ou permet

          Posté par . Évalué à  3 .

          Probablement un mode de veille avant le suspend complet. Certain processeur ARM sont capable de couper quasiment toutes leurs unites interne excepte les registres, le cache et la TLB. Cela permet de consommer beaucoup moins tout en maintenant le systeme parfaitement reactif et multitache. Il faut par contre que les applications et le systeme gere les choses correctement, car sinon c'est un bon moyen de se reveiller trop souvent et de tuer la batterie.

        • [^] # Re: empeche ou permet

          Posté par . Évalué à  3 .

          Parce que certains périphériques ne marchent pas quand le système est en veille : tous ne sont pas branchés de manière à pouvoir émettre une interruption matérielle au processeur (par exemple les touchscreens ; en plus, ça réveillerait ton smartphone tout le temps quand il est dans ta poche, et ça boufferait beaucoup de batterie). Et certains ne peuvent simplement pas marcher quand le CPU n'est pas la pour effectuer une partie du travail (genre la caméra).

      • [^] # Re: empeche ou permet

        Posté par . Évalué à  8 .

        Moi aussi cette phrase me fait tiquer. Je suppose que par "mal écrite" l'auteur voulait dire qu'une application se comportant mal pourrait utiliser une attente active pour éviter la mise en veille, consommant inutilement la batterie. Ce serait le comble pour un OS pensé pour réduire la consommation électrique au maximum :)

        Ce qui me gène donc, c'est que le mécanisme de wakelock n’empêche en rien une application mal écrite de consommer inutilement de la batterie. Il fournit une juste bien meilleure alternative à l'attente active.

  • # CRC et détection d'erreurs

    Posté par . Évalué à  5 .

    Les codes cycliques redondants permettent, en échange d'une consommation plus importante de l'espace disque, à la fois de détecter et de réparer les données corrompues.

    Petite erreur ici, ou alors cela demande des explications ! Un contrôle de redondance cyclique permet de détecter les erreurs, pas de les corriger.

    • [^] # Re: CRC et détection d'erreurs

      Posté par (page perso) . Évalué à  6 .

      Comme les cours commencent a dater pour moi, je ressors le lien qui va bien.

      Les CRC sont une sous famille parmi ces algos de checksums qui ne traitent effectivement que la détections d'erreurs. D'autres algos, dans le lien est cité celui de Hamming, permettent en plus la correction des données.

      • [^] # Re: CRC et détection d'erreurs

        Posté par . Évalué à  4 .

        Ah c'est moi qui est fait l'erreur. J'ai fais un amalgame (dût au temps qui est passé depuis mes cours sur le sujets) entre les deux familles.

        1 000 excuses.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: CRC et détection d'erreurs

          Posté par . Évalué à  3 .

          Je ne jetterais aucune pierre :) Errare humanum est ! Mon but était plus de savoir si c'était une erreur ou s'il y avait un mécanisme plus complexe, basé sur du CRC, afin de fournir en plus de la correction d'erreurs (d'ailleurs, est-ce que cela existe ?)

          • [^] # Re: CRC et détection d'erreurs

            Posté par . Évalué à  3 .

            Il réutilise simplement l'implémentation déjà existant de CRC32 du noyau, donc pas de killer feature en vue. Comme déjà dis il existe des codes cycliques autocorrecteur mais ce n'est pas le cas ici.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: CRC et détection d'erreurs

            Posté par . Évalué à  6 .

            Avant de vouloir faire de la correction, il faudrait déjà de les checksum ne s'appliquent pas à seulement une infime partie du disque (metadata seulement). Après tu as le problème de performance car il faut penser que les checksum doivent être recalculés à chaque changement et vérifiés à chaque accès. Utiliser des codes auto-correcteur est très couteux en terme de CPU et d'espace de stockage (tu ne peux pas réparer un bloc de 4Ko avec 32 bits de données). Et les checksums sont stocker avec ou comme metadata.

            ZFS checksum absolument tout avec soit un CRC-like soit du SHA mais ne propose la correction d'erreur uniquement si un bloc dupliqué valide existe (mirroring ou block replication). Et il y a a priori une raison.

          • [^] # Re: CRC et détection d'erreurs

            Posté par . Évalué à  10 . Dernière modification : le 24/07/12 à 11:05

            d'ailleurs, est-ce que cela existe ?

            Oui, il existe des codes de détection d'erreurs et des codes de détection et correction d'erreur (je ne sais pas si c'était ça la question).

            Par exemple, le Code Reed-Solomon. Le principe est de définir un alphabet (un sous-ensemble) et une distance à l'intérieur d'un ensemble, et dès qu'on détecte un caractère qui est pas dans l'alphabet, on le remplace par le caractère plus proche. La capacité de correction est donc la moitié de la distance min entre deux caractères. Au-delà, on ne sait pas retrouver le caractère d'origine.

            Exemple simpliste : Les multiples de 5 dans l'ensemble des nombres de 1 à 100. Si on a une erreur inférieure ou égale à 2, on sait corriger. Bien sûr, ici, c'est nul parce que la redondance représente 80% du poids alors qu'en Reed Solomon c'est plutôt la proportion inverse.

            Dans la pratique, la correction se fait par blocs et l'élément de base est un octet. Une erreur de 1 ou 5 bits dans un octet revient au même, mais une erreur de plusieurs octets dans un mot le rend plus délicat à traiter. Donc pour résister aux burst-errors (erreurs consécutives dues à une rayure, par exemple), on entrelace autant que possible le signal pour éloigner les octets du même mot, et on regroupe les octets sur eux-mêmes, au lieu de mettre les bits en enfilade, de sorte qu'une erreur soit regroupée sur un même octet autant que possible.

            Reed-Solomon est utilisé dans les disques compacts, mais aussi dans les DataMatrix (codes barre en 2D) qu'on retrouve sur des médicaments, factures France Telecom, ou sur des circuits intégrés.

            • [^] # Re: CRC et détection d'erreurs

              Posté par (page perso) . Évalué à  4 .

              Reed-Solomon est utilisé dans les disques compacts, mais aussi dans les DataMatrix (codes barre en 2D) qu'on retrouve sur des médicaments, factures France Telecom, ou sur des circuits intégrés.

              Dans l'ADSL aussi. Pour la majorité (et les plus malchanceux) d'entre nous, ce code nous permet de mouler.

            • [^] # Re: CRC et détection d'erreurs

              Posté par . Évalué à  3 .

              Merci pour ton explication très clair :)

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: CRC et détection d'erreurs

              Posté par . Évalué à  3 .

              Merci pour ces précisions. Je ne connaissais pas le code Reed-Solomon :) (bon, j'admets, je ne suis pas non plus un spécialiste du domaine). Connaissant quelques codes correcteur, ma question n'était pas tellement sur leur existence, mais de savoir s'il existait un code correcteur basé sur la famille des CRC.

              Quoiqu'il en soit, merci pour le code de Reed-Solomon ;)

          • [^] # Re: CRC et détection d'erreurs

            Posté par . Évalué à  5 . Dernière modification : le 25/07/12 à 14:25

            Je ne jetterais aucune pierre :) Errare humanum est ! Mon but était plus de savoir si c'était une erreur ou s'il y avait un mécanisme plus complexe, basé sur du CRC, afin de fournir en plus de la correction d'erreurs (d'ailleurs, est-ce que cela existe ?)

            Oui le BCH (https://en.wikipedia.org/wiki/BCH_code) ca ce calcule comme un crc, mais lieu de choisir un polynôme qui maximise la détection d'erreur, on choisit un polynôme qui permet de corriger un maximum d'erreur. En pratique il faut un "crc" taille m*t, ou t est le nombre d'erreur a corrigé et 2m est la taille du message a corrigé en bits (crc compris). Par exemple pour 512 octects de données et 4 bits de correction, il faut un "crc de taille 13*4 = 52 bits

            Contrairement au Reed-Solomon il travail par bit et pas par burst. Il est utilisé dans les mémoire flash.

    • [^] # Re: CRC et détection d'erreurs

      Posté par (page perso) . Évalué à  5 .

      Il est peut-être possible de deviner là où est l'erreur pour la corriger et vérifier si la correction correspond au code.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: CRC et détection d'erreurs

      Posté par . Évalué à  6 .

      Penser aux .par qui permet non seulement de verifier mais aussi de corriger.

      • [^] # Re: CRC et détection d'erreurs

        Posté par . Évalué à  5 .

        JE vois pas pourquoi je me suis fait moinsser pour ca:
        http://www.par2.net/par2spec.php

        A moins qu'on me dise que ca n'a rien a voir avec du crc ?

        • [^] # Re: CRC et détection d'erreurs

          Posté par . Évalué à  5 .

          Bha ca n'a rien a voir avec du CRC… Si on va par là du CRC et une fonction de hachage crypto c'est la même chose. Le CRC n'a qu'un seul but: détecter le plus souvent possible une corruption non intentionnelle d'un bloc de données. Ni plus ni moins.

          Le but de la fonctionnalité c'est uniquement de détecter la corruption des metadata et basta. On est encore très très très loin de ZFS.

        • [^] # Re: CRC et détection d'erreurs

          Posté par . Évalué à  2 .

          hmm enlevez le http:// du lien svp ..la ca redirige pas vraiment a l'adresse voulue.

  • # Une bonne cuvée!

    Posté par . Évalué à  5 .

    Moi qui trouvait que Linux était un peu en retard sur FreeBSD (DTrace, Capsicum, ZFS), j'apprécie la présence d'uprobes et des filtres seccomp dans la version 3.5, bon Btrfs doit encore mûrir mais c'est déjà pas mal.

    Le temps mis par seccomp et surtout par uprobes pour être intégré dans Linux me laisse songeur tout de même!

  • # numa

    Posté par (page perso) . Évalué à  9 .

    Il y a quelques erreurs à propos des architectures numa:
    - Ce n'est pas pour de nombreux coeurs sur un même processeur, mais plutôt de nombreux processeurs en général. Elles existaient bien avant les puces multi-coeur.
    - NUMA pose autant (et même bien plus) de problèmes d'accès concurrents et de cohérence du contenu de la mémoire. Le vrai problème de SMP par rapport à NUMA, c'est que tous les processeurs étant sur un même bus, ils se partagent la bande passante. Alors qu'en NUMA, on répartit la mémoire sur plusieurs bus, et les processeurs sont répartis sur ces bus. Quand l'OS se débrouille bien, les processus tournant sur les processeurs ont leurs données dans la barrette mémoire juste en face, et donc n'ont pas besoin d'aller chercher à côté, et donc il n'y a plus de partage de bande passante mémoire, chaque paquet de processeur accède tranquillement à la barrette mémoire en face sans être dérangé par les autres.
    - Comme dit juste avant, en NUMA, bus et mémoire ne sont pas par coeur. Il y a des machines où c'est un bus+mémoire par paquets de 4 puces (e.g. machines itanium de Bull), il y a des machines où c'est par puce (e.g. Opteron), il y a des machines où il y en a 2 par puce, la moitié des coeurs de la puce étant en face de l'un, et l'autre en face de l'autre (magny-cours). Un bus+mémoire par coeur, ça ferait par contre vraiment beaucoup, en général c'est plutôt de l'ordre de 4 à 16 en tout. Utilisez l'outil lstopo pour savoir comment votre machines est faite ;)

    • [^] # Re: numa

      Posté par (page perso) . Évalué à  6 .

      Il y a quelques erreurs à propos des architectures numa

      Oui c'est un ajout malheureux d'un des contributeurs sur ce paragraphe NUMA. Dur, dur de trouver l'équilibre entre le contrôle total de la news et la rédaction collaborative.

    • [^] # Re: numa

      Posté par (page perso) . Évalué à  4 .

      Utilisez l'outil lstopo pour savoir comment votre machines est faite ;)

      C'est sympa cette commande. Par contre, je ne vois pas le bus mémoire.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: numa

        Posté par . Évalué à  1 .

        lstopo ne montre pas les bus, mais les noeuds mémoire. Si ta machine est NUMA, tu verras plusieurs noeuds (NUMANode) avec chacun une certaine quantité de mémoire. Et en dessous de chaque boite représentant un noeud mémoire, tu as les coeurs/threads/caches proches de celui-ci.

  • # félicitations

    Posté par (page perso) . Évalué à  -2 .

    juste bravo pour cet article !

    merci

    Sebastien

    [services informatique](http://www.aexm.fr/ "AEM") sur Grenoble

  • # mise en page

    Posté par (page perso) . Évalué à  3 .

    la mise en page semble complètement pétée à l'heure actuelle

  • # token ring

    Posté par (page perso) . Évalué à  5 .

    Attention pour les utilisateurs de token ring, ce n'est plus supporté à partir de cette version.

    http://lwn.net/Articles/497397/

    • [^] # Re: token ring

      Posté par (page perso) . Évalué à  2 .

      ça date de 1988 token ring non ? netware de 3com c'est encore pris en charge ? (pour x25 les jours sont comptés il paraît…)

Suivre le flux des commentaires

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