Sortie du noyau Linux 5.1

La sortie de la version stable 5.1 du noyau Linux a été annoncée le 5 mai 2019 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org mis à jour le 6 mai. Le détail de quelques‐unes des évolutions et nouveautés se trouve dans la seconde partie de la dépêche.

Sommaire

• Annonces des versions candidates par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • Architectures
    • x86 Intel & x86_64 AMD
    • ARM
    • RISC-V
    • Autres
  • Identification des processus
  • Gestion de la mémoire
    • Mémoire vive non volatile
    • Accélération du vidage de l’espace d’échange mémoire (swap)
    • Défragmentation des HugePages
    • OOM Killer
    • Gestion des vidages mémoire (dumps)
  • Sécurité
    • SafeSetID
    • eBPF
  • Bogue de 2038
  • Périphériques et pilotes
    • Cartes graphiques
      • AMD
      • Intel
    • Cartes son
    • Réseau
  • Intelligence artificielle
  • Systèmes de fichiers et outillage
    • IO_URING
    • VFS
    • AutoFS
    • XFS
    • NFS
    • CIFS
    • FSNotify / fanotify
    • Autres
  • LivePatch
• Statistiques
• Autour du noyau

Annonces des versions candidates par Linus Torvalds

RC-1

Annonce :

C’est dimanche, deux semaines se sont écoulées et tout paraît normal. Vous connaissez tous la procédure maintenant : la fenêtre de fusion est terminée et les choses sont supposées se calmer.

La fenêtre de fusion m’a semblé franchement normale et, au vu des statistiques, rien de vraiment bizarre ne se profile. C’est une sortie de taille habituelle (c’est‐à‐dire grosse, évidemment, mais pas plus que d’habitude) et la majorité (un peu plus de 60 %) sont des pilotes, toutes sortes de pilotes. Celui qui sort du lot est le pilote de circuit d’accélération d’IA d’Habanalabs [N. D. T. : Habana Labs], mais je soupçonne que nous verrons ce genre de chose de plus en plus souvent. Il y a aussi les suspects habituels : processeurs graphiques, réseau, périphériques blocs, etc.

Une évolution plutôt récente est la manière dont les mises à jour de tools/testing/ ressortent ces derniers temps. Ce n’est pas une nouveauté de la fenêtre de fusion 5.1, ça dure depuis assez longtemps, mais il convient juste de mentionner que nous avons plus de nouveaux changements dans les auto‐tests que de mises à jour d’architectures, par exemple. Le sous‐répertoire documentation aussi est assez remarquable.

Mais dans l’ensemble, il y en a vraiment un peu partout, y compris des mises à jour au cœur de VFS, en plus des habituelles mises à jour.

Comme toujours, le journal abrégé est beaucoup trop long pour être posté, avec plus de 11 000 commits (12 000, avec les fusions). Voici donc mon « journal des fusions » habituel, qui liste les sous‐mainteneurs et un résumé des git pulls que j’en ai tiré…

Allez‐y, testez.

Linus

RC-2

Annonce :

Bien, la fin de la fenêtre de fusion est une semaine derrière nous, et voici la RC-2. Les choses semblent tout à fait normales, mais honnêtement, la RC-2 est généralement trop précoce pour se faire une idée. Les gens n’ont pas forcément eu le temps de constater des problèmes à ce stade, ce qui est juste un autre moyen de dire « s’il vous plaît, testez plus ».

Rien de particulier n’apparaît. D’accord, nous avons eu des correctifs dans le nouveau code d’io_ring pour des problèmes qui ont été discutés au moment de le fusionner. Autrement, il faut noter que le plus gros des correctifs est d’ordre utilitaire, rien dans le cœur du noyau. En fait, à peu près deux tiers des correctifs ne concernent que le répertoire tools/, principalement à cause de récentes mises à jour d’outils de perfs. Les gens concernés promettent qu’ils ont fini.

Si l’on met de côté les utilitaires, le reste est éparpillé un peu partout, et c’est plutôt petit. C’est en gros réparti de manière égale entre les mises à jour d’architectures, de pilotes et de systèmes de fichiers, mais c’est en partie dû à l’io_ring précédemment cité (qui fait ressortir sensiblement la partie système de fichiers). Il y a de légers bruits ailleurs aussi : la majorité du code dans arch/ est une mise à jour tardive d’ARC, mais rien de tout cela n’est vraiment gros ou inquiétant.

Journal abrégé ajouté pour un avant‐goût des détails (et vous remarquerez ici la dominance des perfs).

À vos tests.

Linus

RC-3

Annonce :

Rien de particulièrement inhabituel cette fois.

La RC-3 est plus grosse que d’habitude, chose que je n’aime évidemment jamais voir, mais en même temps, c’est suffisamment tôt dans la série de RC pour ne pas me faire vraiment peur. Pour l’instant.

Et même si c’est plus gros, rien de particulier n’apparaît. La seule et unique grosse rustine ici (et de loin, car ça représente près du tiers de l’ensemble de la publication) est simplement la suppression du pilote expérimental mt7621-eth, car le pilote Ethernet Mediatek standard gère maintenant ce matériel. En fait, en raison de la suppression de ce pilote, le correctif complet de la RC-3 retire plus de lignes qu’il n’en ajoute, ce qui fait toujours plaisir à voir (pour parler honnêtement, si l’on regarde l’ensemble de la version plutôt que seulement celle de cette semaine, ce n’est pas vrai du tout).

Mais non, la suppression de ce pilote n’est pas la raison qui me fait dire que la RC-3 est plus grosse que d’habitude – ce n’est qu’un seul commit. Nous avons simplement plus de commits que d’habitude à ce stade. J’espère que ce n’est qu’un cas unique – la mesure globale des « tailles de RC » tend à être sujette au bruit, et est dépendante du fait qu’une semaine particulière voit tous les principaux sous‐systèmes fusionner leurs correctifs ou pas. Cette fois, ça a été clairement beaucoup le cas.

Si vous mettez de côté ce gros morceau de la RC-3 représentant la suppression de cet unique pilote, les changements sont assez largement éparpillés. À peu près un tiers sont des pilotes, un autre bon tiers sont des modifications d’outils et de documentation, et le dernier tiers est simplement du « divers » un peu partout (le réseau en est un gros morceau, mais il y a des mises à jour d’architectures, de cœur du noyau, de KVM, et j’en passe…).

Le journal abrégé attaché donne un avant‐goût des détails, et je ne pense pas qu’il y ait quoi que ce soit d’important dedans. Juste beaucoup de petits détails.

Espérons que les RC vont commencer à diminuer à partir de maintenant, mais je ne pense pas que nous verrons quoi que ce soit de mauvais se présenter.

En avant, testez.

Linus

RC-4

Annonce :

Une autre semaine, une autre RC. Plus petite que la RC-3, je suis content de l’annoncer. Rien de particulièrement gros ici, juste de petites choses un peu partout.

Et il y en a vraiment de partout. Les pilotes représentent à peu près le tiers (réseau, périphériques de type bloc, processeurs graphiques, SCSI) et le reste est un mélange de mises à jour d’architectures, de systèmes de fichiers, de documentation, de cœur du réseau, d’utilitaires… Il n’y a donc pas de thème unique ici, juste de petits correctifs éparpillés de partout.

Le journal abrégé est joint pour les personnes qui voudraient avoir un aperçu des détails.

Linus

RC-5

Annonce :

Nous y revoilà… C’est dimanche après‐midi, ça signifier donc une autre RC du noyau.

Nous avons des changements de partout, mais beaucoup ne sortent pas de l’ordinaire, et la plupart sont très petits. Si l’on regarde les stats, les mises à jour des pilotes audio ont tendance à ressortir, prenant presque le tiers du correctif (et presque le tiers des commits aussi, ce n’est donc pas le résultat d’une unique grosse rustine). Mais rien de tout ça ne semble tellement effrayant.

En dehors des correctifs audio, un autre tiers sont les autres pilotes (processeurs graphiques, RDMA, NVMe, MMC, couche bloc…) et la dernière chose est « divers ». Cela inclut des mises à jour d’architectures et d’utilitaires, et des corrections de code variées (réseau, systèmes de fichiers, modules de sécurité, et /mm dans le cœur du noyau).

Rien ici ne me met mal à l’aise à propos de ce cycle de parution. Touchons du bois.

Le journal abrégé est joint avec un résumé des détails, comme toujours.

Linus

RC-6

Annonce :

C’est le dimanche de Pâques ici, mais je ne laisse pas des choses bénignes, comme l’arrivée d’un jour saint pour une religion majeure, interrompre le flot de mon travail sur le développement du noyau. Pour la promenade occasionnelle en plongée, d’accord, mais se réunir pour un repas traditionnel, non. Il faut avoir des priorités. Il y a juste tout ce Memma à manger, même si votre femme a dû le préparer depuis zéro parce que personne ne consomme ce genre de chose aux États‐Unis.

En tout cas, la RC-6 est plus grosse que je l’aurais aimé, ce qui m’a fait revenir à l’historique, et curieusement ce n’est pas si inhabituel que ça. Nous avons récemment eu des pics similaires avec les 4.18 et 5.0.

Donc, je ne vais pas m’inquiéter pour ça. Je pense que c’est juste un hasard de chronologie dans les demandes d’intégration, et sans doute au moins partiellement dû à la demande d’intégration réseau (avec un peu plus du tiers des changements relatifs au réseau, aussi bien dans les pilotes que dans la partie commune).

À part le réseau, nous avons les habituelles mises à jour d’autres pilotes (nvdimm, I²O et processeurs graphiques sortent du lot), d’architectures (principalement x86 – les correctifs KVM ressortent) et les utilitaires (auto‐tests et perfs)

Enfin, nous avons une collection d’autres changements variés : mm dans le cœur, des correctifs de systèmes de fichiers, l’ordonnanceur et du traçage.

Mais malgré que la RC-6 soit un peu plus grosse que je l’aurais espéré, l’ensemble est plutôt petit, et je ne pense pas qu’il y ait quoi que ce soit d’inquiétant ici. En fait, une grande partie sont des choses vraiment triviales, dont certaines juste des corrections d’orthographe ou dans ce genre.

Jetez un œil au journal abrégé ci‐joint pour les détails, si ça vous intéresse, mais surtout, faites le tourner et mettez‐le à l’épreuve…

Linus

RC-7

Annonce :

Si la RC-6 était plus grosse que je l’aurais souhaité, ça semble bien dû à la chronologie des demandes d’intégration, car la RC-7 est très petite.

Un peu moins de la moitié des correctifs sont des modifications réseau de différentes sortes : un mélange du cœur du réseau, de pilotes et d’auto‐tests pour Netfilter.

Le reste est surtout constitué des habituels correctifs d’architectures, de systèmes de fichiers et autres pilotes (surtout RDMA et processeurs graphiques), et des changements divers (documentation, traçage, et des fixlets mm).

Mais tout cela est plutôt petit. De plus, à peu près 30 % des correctifs sont marqués comme stables, donc dans l’ensemble, la 5.1 semble en bonne voie pour une publication la semaine prochaine.

Touchons du bois.

Linus

Les nouveautés

Architectures

x86 Intel & x86_64 AMD

Ajout de la plate‐forme Ice Lake Mobile dans la gestion d’intel_rapl (Running Average Power Limit).

Ajout de la plate‐forme Jacobsville dans la prise en charge d’intel_idle (Jacobsville est une plate‐forme basse consommation, descendant des premiers Atom, aujourd’hui famille 6 « Atom Tremont », pouvant être utilisée dans des « micros‐serveurs » ou encore pour « l’Internet des objets »), et intel_idle leur permet de plonger en sommeil profond pour baisser la consommation électrique. L’intel_idle et les c_state ont parfois causé pas mal de soucis sur certains PC portables, tels que le gel du système avec, et consommation électrique trop élevée sans. Et contrairement à l’ACPI standardisé, les c_states peuvent changer d’un système monopuce (SoC) à un autre. L’ajout de cette prise en charge devrait régler ce problème pour ces systèmes monopuces (processeur + jeu de composants) Jacobsville.

Ajout de la prise en charge du matériel MSN3700C de Mellanox.

Prise en charge des diodes électroluminescentes (DEL/LED) et des boutons pour les APU v2 et v3 de chez PCengines.

ARM

Comme d’habitude avec cette architecture, la prise en charge de nombreux nouveaux systèmes monopuces (SoC) est intégrée, et de nouveaux déclaratifs Device Tree font leur apparition. Entre autres choses on pourra citer :

• l’arrivée du MT7629 de chez Mediatek, le tout dernier routeur Wi‐Fi de la marque, avec un double cœur Cortex A7 (et une prise en charge avec OpenWRT) ;
• l’entrée des Renesa R7/AM2 (puce spécialisée dans le traitement d’image) et RZ/G2E ; ne vous emballez pas, il s’agit « juste » du Device Tree, et pas d’une prise en charge complète (la seconde puce, par exemple, embarque un PowerVR à côté de son double cœur Cortex A53).

Et bien d’autres, cependant sans rien qui sorte spécialement du lot pour être mentionné, aussi vous pouvez aller lire la liste complète des nouveautés ARM sur Linux Kernel Newbies. On notera juste l’arrivée d’une variante du Raspberry Pi, le 3 A+, pour laquelle le raffinement d’un contrôle Bluetooth séparé de celui du Wi‐Fi est ajouté.

RISC-V

La prise en charge matérielle de RISC-V arrive à maturité et des correctifs de noyau avancés doivent être testés et exécutés au moins sur la carte de développeur HiFive Unleashed de SiFive.

Autres

Prise en charge du système monopuce Bitmain en tant qu’A53 double cœur combiné à un seul cœur RISC-V, bien que seul le processeur ARM soit pris en charge pour le moment. Il existe également une nouvelle prise en charge pour ARM, notamment Socionext Milbeaut, NXP i.MX8QuadXPlus et quelques systèmes monopuces de Rensas.

Identification des processus

Le bien connu système de PID souffrait d’un problème de réattribution d’un numéro d’identifiant pour un processus, pouvant éventuellement mener à une situation de concurrence où un processus A envoyait un signal à un processus B, alors que ce dernier était stoppé et son numéro d’identifiant réattribué à un processus C. On peut lire cette discussion pour constater que certains usages ont réellement rencontré ce qui ne semblait être qu’un problème théorique.
Après de nombreuses discussions et propositions correctrices sur plusieurs axes, cette affaire est maintenant close avec l’ajout d’un nouvel appel système, pidfd_send_signal. Une vidéo sur ASCII cinema en présente les principes.

Gestion de la mémoire

Mémoire vive non volatile

Une nouveauté particulièrement intéressante est l’introduction d’un nouveau mode d’usage pour la « mémoire persistante ». Pour rappel, NVDIMM (non‐volatile dual in‐line memory) est un type de mémoire résistant à un arrêt électrique : son contenu est conservé comme sur un disque dur. Le noyau prenait en charge ce type de matériel comme un disque. Il est maintenant possible d’utiliser la NVDIMM comme une barrette mémoire, en utilisant l’API de gestion de mémoire du noyau. Des gains de performances sont donc attendus, et ces gains seront maintenus pendant toute la séquence de fonctionnement de la machine, sans perte de performance au fur et à mesure de l’usage. L’implémentation passe par un accès aléatoire du placement des nouveaux blocs. Comme le souligne Kees Cook il est plaisant de voir qu’une fonctionnalité de sécurité améliore les performances !

Est-ce que la NVDIMM ressemble plus à un fantôme qu’à une réalité, le marché et les constructeurs ne proposant au mieux qu’un ajout d’une petite batterie sur la barrette ? Les choses semblent bouger, notamment chez les grands fournisseurs de « solutions en nuage » et constructeurs, tels que HP et Intel.

En aparté, et à côté de la NVDIMM, il se trouve que l’implémentation de DAX, spécifique aux architectures x86, a été proposée (lors du dernier _2019 Linux Storage, Filesystem, and Memory‐Management Summit » du début d’année) pour être considérée comme terminée._

Accélération du vidage de l’espace d’échange mémoire (swap)

Une autre nouveauté marquant cette version est la réduction de la complexité de l’algorithme derrière le mécanisme swapoff, opération permettant de vider l’espace d’échange mémoire sur le stockage de masse afin de renvoyer son contenu en mémoire vive. Opération que l’on soupçonne complexe et qui vient d’être simplifiée. Les gains de performances impressionnent : on passe de 80 % de temps processeur et 8 min pour renvoyer 6 Gio de l’espace d’échange vers la mémoire vive, à 5 % de processeur et 3 min pour la même opération avec la nouvelle implémentation. Voir ce courriel pour en savoir plus.

Défragmentation des HugePages

Les Transparent HugePages continuent de recevoir des améliorations. Cette fois, c’est pour leur gestion de la défragmentation, ce qui complète le travail précédent et permet maintenant d’améliorer leur allocation. Voir ces explications, pour en apprendre plus. Le changement est noté comme « allocation proche de la perfection ». Vingt‐deux correctif constituent cette belle avancée.

OOM Killer

L’Out Of Memory Management reçoit une légère modification. Pour éviter une situation où un processus bogué consommant toute la mémoire vive et l’espace d’échange est tué, mais toujours relancé par le processus initial (PID 1), c’est maintenant le processus père qui sera tué pour protéger le fonctionnement du système et des services. Aucun doute que certains ici ont connu ce type de situation avec, par exemple, des outils « constructeurs » complètement bogués et tués dix fois par jour. Un voile de pudeur posé sur leur nom, on préfèrera mettre en lumière ce correctif.

Gestion des vidages mémoire (dumps)

Vous avez des machines disposant de beaucoup de mémoire vive, elles portent des machines virtuelles et vous avez un besoin d’analyse de crashs ? Vous serez alors intéressé par l’exclusion des balloon pages des vidages mémoire (dumps) du noyau, permettant de réduire (fortement ?) la taille de ces dumps. Au passage, elles ont aussi été exclues du processus d’hibernation. Pour rappel la technique du ballooning permet, par exemple, à la machine hôte de réclamer de la mémoire vive à une ou des machines invités. Le premier correctif explique en détails cette modification.

Sécurité

SafeSetID

On notera surtout l’arrivée d’un nouvel LSM (Linux Security Module) : SafeSetID. Il s’agit d’autoriser ou non la transition d’UID par une liste blanche d’approbation côté système et l’obtention de privilèges de type CAP_SETUID. Pour le moment, les appels système SETUID sont pris en charge, les SETGUID devraient suivre sous peu. Lisez la documentation du noyau pour aller plus loin.

eBPF

eBPF a le vent en poupe avec pas moins de quinze nouveautés. BPF, extended Berkeley Packet Filter a trois axes : le réseau, la sécurité (seccomp, landlock…) et l’instrumentation du noyau.
Au menu des nouveautés, il y a, entre autres, la création de rapports d’usage de BPF lui‐même, l’ajout possible des en‐têtes IP encapsulés dans les paquets pour IPIP, IP/GRE, IP/GUE pour IPv4 et IPv6, et la gestion du type __int128 sur les architectures AMD64 (cf. ce commit initial). Mais c’est la prise en charge de la concurrence qui retient le plus l’attention dans ces nouveautés, avec l’ajout d’un verrou tournant (spinlock). Les discussions ne sont pas terminées quant aux évolutions futures possibles au sujet de la gestion de la mémoire dans ou avec eBPF, mais elles augurent de belles évolutions à venir.

Pour en savoir plus sur BPF, eBPF et l’outillage BCC, la lecture de cette explication (en français) couvrant une partie de l’usage et avec des exemples pour BCC et Python, peut vous être utile.

Bogue de 2038

L’an de grâce 2038 pourrait être l’année d’un bogue comparable à celui de l’an 2000 où des systèmes d’exploitation, des horloges matérielles, des systèmes de fichiers et des logiciels se retrouveront à afficher une date erronée (1901 au lieu de 2038, voir cet article sur Wikipédia). Ce problème concerne, entre autres, la représentation POSIX du temps, qui était limitée à 2 147 483 647 secondes (rapport entre le 1^er janvier 1970 et une représentation avec un entier signé de 32 bits)

Le noyau compilé pour x86_64 est immunisé. Les architectures 32 bits pourront, avec ce noyau 5.1, disposer d’une structure time_t sur 64 bits. Une élégante et parfaite solution.

Périphériques et pilotes

Cartes graphiques

AMD

Du côté du pilote libre amdgpu, on a la prise en charge de BACO (Bus Active, Chip Off) pour les Vega 10 et 20, un mode d’économie d’énergie dans lequel la majeure partie du processeur graphique est éteinte pendant les périodes d’inactivité, afin de réduire considérablement la consommation d’énergie de la carte graphique.

Le PowerPlay pour les Vega 10 et 20 s’expose maintenant à l’espace utilisateur, via sysfs, ppfeatures permettant d’en configurer certains aspects : l’horloge, avec pp_dpm_socclk et l’accélération du ou des ventilateurs pour les Vega10 et pp_dpm_fclk pour les Vega20. Ceci devrait ravir les overclockers et être utile aussi pour maîtriser un peu plus la consommation d’énergie.

Intel

La protection HDCP (High-Bandwidth Digital Content Protection) en version 2.2 est prise en charge. Pour rappel, il s’agit d’un mécanisme évitant la copie de flux numérique passant par les connecteurs HDMI, DVI et DisplayPort.

Le mode fastboot est maintenant actif par défaut. Ce mode permet d’éviter les multiples initialisations de la carte graphique et/ou de la résolution lors de la séquence de démarrage du système. C’est un bon complément pour une configuration en « amorçage silencieux ». Toutes les cartes au‐delà de la neuvième génération en bénéficient.

Un exemple en vidéo avec une carte graphique autre qu’une Intel, où le rendu graphique de la séquence d’amorçage est sans interruption depuis le BIOS jusqu’au bureau, mais sur lequel il reste un ajustement final ; le fastboot activé par défaut pour les cartes Intel évite cet ajustement final).

À noter aussi un petit correctif pour le « mode TV » : les fréquences 30 Hz, 50 Hz et 60 Hz en 1080p.

Quelques nouvelles déclarations de matériels, pour Coffee Lake et Ice Lake, du nettoyage dans le débogage. Il y a également l’ajout de l’exposition à l’espace utilisateur de la configuration RPCS (SSEU) pour les cartes de la onzième génération, « Gen11 », uniquement (visiblement contre‐productif sur les autres générations). Lisez ce rapport initial pour en savoir plus sur un des constats et l’origine de la question.

Cartes son

Côté audio ce sont surtout les ASOC qui reçoivent des nouveautés, avec pas moins de vingt‐six nouvelles prise en charge, allant du simple ajout de la gestion du bouton de bascule vers un ensemble casque‐micro de tête pour les séries Broxton chez Intel, jusqu’à l’arrivée d’un nouveau codec, le jz4725b, en passant par une nouvelle carte prise en charge par le module rt5651. C’est aussi l’arrivée de la prise en charge pour l’équipement FireFace UCX de chez RME.

Bien que peu excitant pour ce noyau 5.1, la prise en charge de l’audio par Linux continue son chemin. Les audiophiles préféreront peut‐être se pencher sur la nouvelle couche logicielle PipeWire en dehors du noyau, qui a pour ambition d’unifier audio et vidéo, et remplacer à terme Jack et PulseAudio, tout en préservant une compatibilité.

Réseau

Côté Mellanox, toujours beaucoup de nouveautés, avec de petites modifications vraiment atomiques, et des améliorations surtout pour l’Infiniband :

• gestion du 50 Gbit/s par voie (sur les liens 50 Gbit/s, 100 Gbit/s et 200 Gbit/s) ; à noter que la prise en charge de ces cartes est d’ores et déjà rétroportée dans les distributions majeures ;
• améliorations pour la série des cartes et adaptateurs InfiniBand de série 573xx de ce fabricant (incluant les 57500, Connect-x6, cartes de débit 200 Gbit/s).

C’est fait dans le cadre de l’Open Fabric Alliance pour rapprocher les possibilités du pilote libre de leur pilote propriétaire. La cible principale est la meilleure adaptation du matériel au calcul haute performance. Les développeurs intéressés pourront consulter les manuels (au‐delà de Mellanox), disponibles chez Open Fabric. L’effort de convergence, de code source ouvert et de partage ou mise en commun ne peut qu’être encore une fois salué.

Pour le grand public, côté Broadcom, des améliorations mineures dans le module brcmfmac, pour coller au nouveau fonctionnement des derniers micrologiciels.

Intelligence artificielle

Intégration de la prise en charge de la carte « d’intelligence artificielle » de chez Habana Labs de génération Goya. La génération suivante, Gaudi, est d’ores et déjà prévue. Habana Labs présente son propre calculateur spécialisé, la carte Goya est plus spécialement conçu pour l’analyse, tandis que la carte Gaudi sera plus spécialement prévue pour l’apprentissage et elles s’interfacent toutes deux avec les piles logicielles du secteur (telles que TensorFlow) et surtout Habana Labs nous fait le plaisir d’ajouter cette prise en charge avec du code libre directement chez kernel.org.
Ce secteur bouge beaucoup, NVIDIA vient de se réinventer en « constructeur d’intelligence artificielle », tandis qu’Intel vient d’annoncer ses premières puces spécialisées et les acteurs de l’informatique en nuage : Google et AWS travaillent sur leurs propres puces.

Systèmes de fichiers et outillage

IO_URING

IO_Uring fait son entrée officielle dans la branche stable avec cette 5.1. C’est une avancée majeure de ce noyau.
Il s’agit d’améliorer drastiquement les entrées‐sorties asynchrones, certes prises en charge depuis longtemps par Linux, mais dont l’implémentation recevait quelques critiques et méritait d’être améliorée. Cette nouvelle interface io_uring apporte la gestion du tampon pour ces entrées‐sorties asynchrones, et la gestion d’autres types d’entrées‐sorties asynchrones. Cet article en anglais est un bon choix pour aller plus loin.

VFS

Le système de fichiers virtuels VFS permet d’utiliser différents systèmes de fichiers de manière transparente pour les applications. Cette coexistence via cette abstraction permet, entre autres, de s’affranchir des noms de volumes (problème bien connu de Windows) et constitue ce qui permet de gérer en « points de montage » avec l’appel système mount().
Bien que mount() ne souffre d’aucun problème, un nouvel appel système fsopen() voit le jour afin d’apporter une opération intermédiaire descriptive. Concrètement, là où aujourd’hui mount s’occupe de tout dans tous les cas, demain fsopen passera en premier et mount ne s’occupera que du strict nécessaire pour la cible. Il permettra à terme de nouvelles possibilités sur les systèmes de fichiers (remontage dans un espace de noms, par exemple. D’autres exemples et des descriptions des limitations actuelles, sont explicités dans ce courriel).
Cependant, en lisant ces lignes, on peut se demander quels gains réels sont attendus. C’est également une des questions posées par certains mainteneurs du noyau, dont Linus, concernés aussi par la taille de ce correctif sur un des systèmes centraux du noyau, et des possibles implications de sécurité que cela peut engendrer. Après des mois de révisions et d’améliorations, il semble bien aujourd’hui que fsopen() ait sa place dans le noyau. Nous aurons probablement l’occasion d’en reparler, peut-être bien à plusieurs reprises.

AutoFS

AutoFS se voit doté d’une nouvelle option « ignore », il s’agit d’une requête initiale venant de Red Hat, afin de permettre à des applications le souhaitant de ne pas tenir compte de ces points de montage. Votre serviteur émet un doute quant à la pertinence de cette solution, d’autres identifications existent pour éviter d’exposer des points de montage AutoFS, mais il semble ne s’agir que d’un début, comme le laisse entrevoir le commentaire du correctif. Donc, wait and see.

XFS

XFS, ajoute un mode always_cow (pour le copy on write) permettant un débogage plus pertinent dans certaines situations et la prise en charge des matériels qui « ne permettent pas l’effacement de blocs » (zones déclarées en lecture seule). Un cas typique d’usage est un mécanisme de protection des données contre la corruption (coupure électrique, par exemple) : un second espace de métadonnées est alloué et dédié aux journaux jusqu’à ce que l’opération soit complète. Concrètement, il n’y aura jamais de réécriture d’un bloc déjà existant, mais une mise à jour à côté. Voir cette petite documentation sur ZBC et ZDAC pour le contexte initial (ainsi qu’une ancienne présentation de Damien Le Moal à ce sujet).

À noter que cette prise en charge était déjà effective dans le système de fichiers F2FS.

NFS

NFS dépasse une limitation de la glibc pour la lecture du contenu d’un dossier en se dotant d’un cache spécifique. En fait de limitation, il s’agit surtout de s’affranchir des problèmes des performances (observables avec des outils usuels tel que ls en shell ou os.listdir en Python, par exemple), causés par readdir alors que getdents existe, mais est absent de la glibc).
Ce correctif annonce des gains de performances de l’ordre de 70 % lors d’une énonciation du contenu d’un dossier (bémol : on parle là de dossiers contenant plusieurs centaines de milliers de fichiers).

CIFS

De l’amélioration aussi, via du cache, chez CIFS : la réponse à stat /montage ne nécessitera plus d’opération réseau à chaque fois. Intéressant de noter que ce correctif est un travail collaboratif avec Microsoft — Samba/CIFS a fait du chemin depuis ses premières versions basées sur de la rétro‐ingénierie.

FSNotify / fanotify

À côté des systèmes de fichiers ou affiliés, fanotify reçoit enfin le nécessaire pour la surveillance récursive. Celle-ci était auparavant source de consommations de mémoire (voire de temps processeur) car implémentée côté outils, ce n’est plus le cas et les outils pourront faire appel à dirent. Il bénéficie également d’une série de correctifs améliorant les évènements du système de fichiers et son propre comportement.

Autres

Ceph, plate‐forme de stockage distribué, continue de recevoir des améliorations, tandis qu’ExoFS se fait sortir du noyau.

Enfin, il est maintenant possible, moyennant préparation, d’amorcer directement un périphérique déclaré via le device-mapper, donc sans initrd. Ceci ne concerne pas toutes les possibilités de device-mapper, seules six sont actuellement disponibles. Par exemple : amorçage direct sur une partition chiffrée, ou encore sur une partition « dm_verity ». Voir cette première documentation. L’amorçage sur un DM, sans initrd, ça se teste rapidement !

LivePatch

La fonction « live patch » reçoit le « remplacement atomique » permettant de jongler avec plusieurs correctifs en série cumulative. Concrètement, il est maintenant possible de retirer un correctif d’une série. Cette amélioration est utile lorsque plusieurs correctifs touchent à la même structure, la même fonction du noyau, mais également lorsqu’il s’agit de gérer des dépendances entre ces correctifs.

Le sujet semble cependant toujours sensible malgré ces efforts de convergence (menant kgraft et kpatch vers un socle commun), car si certains acteurs (CloudLinux, par exemple) proposant leur solution ne sont pas vraiment un problème à terme, Microsoft en revanche, possède un brevet (aux États‐Unis) sur l’idée, faisant ainsi peser un risque sur la vie de ce projet, et ne semble pas avoir clarifié la situation et son objectif à ce sujet.

Statistiques

Nous vous invitons simplement à lire les informations collectées par Jonathan Corbet pour LWN.net pour la RC-6.

Autour du noyau

La création du « CHIPS Alliance Project » a été annoncée pour accélérer l’adoption du modèle Open Hardware. Les membres actuels sont Esperanto, Google, SiFive et Western Digital. Pour lancer cette nouvelle alliance, Google a contribué à UVM pour les RISC-V. Le projet est hébergé aussi sur GitHub. Plus d’information sur le site de l’alliance.

Pas moins de quarante‐trois nouvelles sociétés rejoignent la Fondation Linux, dont Wolkswagen AG.

Aller plus loin

• Le noyau, son site (94 clics)
• La liste des nouveautés du noyau 5.1 (120 clics)
• Les noyaux précédents (89 clics)
• Annonce de la sortie du noyau 5.1 (42 clics)
• Le noyau, sa documentation (38 clics)