Sortie du noyau Linux 4.7

La sortie de la version stable 4.7 du noyau Linux a été annoncée le dimanche 24 juillet 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le noyau a fêté ses 25 ans le 25 août 2016 \o/.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

Sommaire

• TL;DR
• En bref
• Annonces des versions candidates par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • • CPUFreq et PState
    • Gestion de la mémoire
    • ARM
      • Nouveaux systèmes monopuces gérés :
      • Nouvelles cartes gérées :
      • Allwinner
      • Rockchip
      • Amlogic
      • Samsung
      • Qualcomm
      • Mediatek
    • MIPS
  • Développement
    • USB/IP
    • Hist Trigger
  • Pilotes graphique libres
    • AMDGPU
  • Réseau
    • Pilotes
    • Bufferbloat
    • Autre
      • Partial segment offloading explications
      • TCP préemptible
      • RPS et RFS
    • Socket
  • Sécurité
    • LoadPin
    • Clefs de chiffrement
    • Divers
  • Systèmes de fichiers
    • Recherche parallèle dans les dossiers
    • ext4
    • F2FS
    • XFS
    • Btrfs
    • NFS
    • Système de blocs
  • Virtualisation
    • KVM
    • virtio
• Le bilan en chiffres
  • Le noyau
  • La dépêche
• Appel à volontaires

TL;DR

• gestion du processeur graphique Radeon RX 480 (nouvelle architecture d’AMD appelée Polaris) ;
• Nouveau gestionnaire de fréquence dynamique du processeur (schedutil) ;
• lecture en parallèle du contenu des répertoires, avec un gain de performance dans quelques rares situations ;
• amélioration des outils de contrôle et surveillance (histogrammes d’événements dans ftrace, pile d’appels dans perf trace, tracepoints dans BPF) ;
• intégration du mécanisme sync_file, issu d’Android, qui permet une synchronisation explicite avec l’espace utilisateur.

En bref

Les grandes nouveautés du noyau Linux 4.7 sont la gestion du processeur graphique Radeon RX 480 d’AMD, qui, bien sûr, a été directement implémentée dans le pilote AMDGPU, un nouveau module de sécurité appelé LoadPin, qui s’assure que les modules chargés par le noyau sont tous originaires du même système de fichiers, et la gestion des contrôleurs de périphériques USB virtuels USB/IP.

De plus, il s’agit de la première version du noyau à être prête pour le mécanisme de clôture sync_file utilisé dans les systèmes d’exploitation mobiles Android, qui permet au programme Berkeley Packet Filter (BPF) de s’attacher aux points de dépistage (trace points), aussi bien que le longuement anticipé gestionnaire de fréquence dynamique du processeur schedutil, qui promet d’être plus rapide et plus précis que les existants.

Les nouvelles fonctionnalités sont les suivantes : gestion de la consultation parallèle des répertoires, possibilité de créer un histogramme des évènements avec l’interface ftrace, gestion des appels en chaîne avec l’outil de traçage perf et gestion de la mise à jour du micrologiciel en utilisant le mécanisme EFI « Capsule ». Comme d’habitude, de nombreux pilotes ont été mis à jour et de nombreux bogues ont été résolus.

À noter l’ajout dans le noyau de la gestion des manettes de la Xbox One de Microsoft et du Thunderbolt d’Apple/Intel (Interface qui combine PCI Express et DisplayPort).

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC-1 est sortie le 29 mai 2016 :

Habituellement, je ferme la fenêtre d’intégration le dimanche après‐midi, mais je suis connu pour être embêté par les traînards et tout fermer un jour en avance. Cette fois‐ci, pour mettre un peu de piment, j’ai tout simplement décidé de publier un dimanche matin à la place.

[Et, oui, avant que vous ne me le demandiez, ma vie est vraiment ennuyeuse, si c’est ça « mettre un peu de piment ».]

Cette publication matinale est en partie due au fait que je n’ai rien en attente, que je sache (et s’il y avait quelqu’un qui avait prévu d’envoyer ses changements de dernière minute cinq minutes avant l’habituelle publication de l’après‐midi, ça m’est égal). Et en partie parce que je pense que cela a été une bonne fenêtre d’intégration et que nous avons beaucoup de nouveau code pour la fermer.

Et je ne dis pas ça parce que la fenêtre d’intégration de la 4.7 est particulièrement grosse — elle a l’air plutôt normale et résolument plus petite que ne le fut la 4.6. Nous avons toutes les habituelles mises à jour de pilotes, cependant cette fois‐ci nous avons un assez gros changement dans la couche VFS qui autorise les systèmes de fichiers (s’ils adoptent cette façon de faire) à utiliser readdir() et la recherche en parallèle des éléments du chemin d’accès dans le même répertoire.

C’est probablement le plus gros changement conceptuel de VFS que nous ayons eu depuis que nous avons commencé à faire la résolution de chemin d’accès en cache en utilisant RCU.

Cela dit, les changements de code pour tout ça sont plutôt petits et ils sont éclipsés par toutes les habituelles mises à jour de pilotes. En fait, aucune des mises à jour des systèmes de fichiers ne pointe dans les habituelles « statistiques de répertoires » (parce que les stats de répertoires de git coupent les trucs à 3 %). Donc, quand on arrive au gros du travail, nous avons l’habituelle distribution : environ deux tiers des pilotes (processeurs graphiques et réseau dominent, mais il y en a d'autres) et le reste est principalement des mises à jour d’architectures, de la documentation et du « divers » (où se cachent les changements de VFS).

Même si ce n’est pas une énorme publication, elle est certainement assez grosse pour que même le journal abrégé soit beaucoup trop gros pour le poster ou le lire afin d’avoir une vue d’ensemble, je joins donc mon habituel résumé des intégrations. Et, en tant que tel, souvenez‐vous que les gens crédités sont les gens pour qui je pousse les demandes de changements, ce qui n’est pas forcément le cas de tous les gens qui ont véritablement écrit le code.

Juste pour donner aux gens une idée de la disparité entre la liste de mainteneurs ci‐dessous et le nombre de gens soumettant des correctifs, il y a environ 1 400 auteurs en tout pour les trucs qui sont arrivés pendant la fenêtre d’intégration.

Bref, assez de bla‐bla. Allez‐y, testez. Et, en particulier, si vous êtes une personne du système de fichiers bas niveau ou impliquée d’une autre manière dans la recherche d’éléments de chemins d’accès (couche de sécurité, etc.), allez‐y, testez si tout a l’air OK. Et si votre système de fichiers n’est pas un de ceux qui font déjà des recherches ou des lectures de répertoires en parallèle (à cause de problème de blocage), jetez‐y un œil aussi.

Linus

RC-2

La version RC-2 est sortie le 5 juin 2016 :

C’est dimanche après‐midi, c’est donc le moment d’une version candidate !

Les choses semblent assez normales et il y a des corrections partout, avec du code pour les pilotes et les architectures qui mènent la charge comme d’habitude, mais il y a des trucs épars dans tous les coins, y compris les systèmes de fichiers, le réseau, MM, les bibliothèques de simplification [helper libraries], etc., etc.

Il y a quand même une régression NFS en cours, mais personne, en dehors de certains tests de résistance explicites, ne l’a remarquée, donc j’ai fait une RC-2 malgré la connaissance du problème. Je recevrai une demande d’intégration d’Al plus tard et on réparera ça pour la RC-3. En attendant, je compte sur les rares personnes qui auraient rencontré le problème pour faire du test de résistance sur les systèmes de fichiers et pour d’ores et déjà tester le correctif.

Il y a une non‐correction en retard que j’ai prise bien que la fenêtre d’intégration soit fermée, parce que je la voulais depuis un moment. Je doute que quiconque remarque le résultat effectif d’un nettoyage/changement de PTY, ce qui signifie que notre vieille et dégoûtante option de configuration du noyau DEVPTS_MULTIPLE_INSTANCES a disparu, parce que le nettoyage fait qu’elle n’est plus nécessaire. Nous étions dans une situation où certaines distributions voulaient cette option désactivée pour des raisons historiques et d’autres la voulaient activée pour un comportement moderne. Le comportement de notre /dev/ptmx a été nettoyé et corrigé de sorte que ça juste marche™ dans les deux cas, et cette vilaine verrue a simplement disparu. De plus, le code est de toute façon plus propre.

Je mentionne cette non‐correction probablement essentiellement parce que je me sens un peu coupable de l’avoir intégrée, puisque j’aurais probablement crié sur un des sous‐mainteneurs qui aurait tenté d’appeler ce nettoyage un correctif retardataire. Quod licet Iovi, et tout le toutim… Mais en réalité, pas d’excuses, à part « en définitive ».

Peu importe, il y a donc un peu de tout et c’est suffisamment petit pour que vous puissiez éplucher le journal résumé ci‐joint pour les détails.

Linus

RC-3

La version RC-3 est sortie le 12 juin 2016 :

Vous connaissez tous la rengaine, alors chantez maintenant : « nouvelle semaine, nouvelle RC ».

Rien de particulièrement notable cette semaine. Comme promis, la RC3 contient le correctif pour le problème NFS qui était en suspens dans la dernière RC, que personne ne semble avoir remarqué (comme prévu également).

Les statistiques de modifications semblent plutôt normales et inoffensives. Il y a plus de composants de systèmes de fichiers que d’habitude, mais ce sont majoritairement des ajouts de tests de btrfs et, si vous ignorez cette partie, ce sont tous les trucs habituels : les pilotes dominent (processeurs graphiques et réseau en constituent la majeure partie, mais il y a de l’I²C, du RDMA…) avec quelques mises à jour d’architectures et du code réseau général. Et les habituels trucs épars partout. Mais tout cela est assez petit. Le journal abrégé est joint pour les gens qui aiment avoir un rapide aperçu des détails.

Linus

RC-4

La version RC-4 est sortie le 19 juin 2016 :

Ça a été une semaine assez normale et la RC-4 est sortie. Allez la tester.

Les statistiques ont l’air très normales : environ deux tiers de pilotes et le reste est constitué pour moitié des mises à jour d’architectures et pour l’autre moitié de « divers » (petites mises à jour des systèmes de fichiers, un peu de documentation et une poignée de corrections par ailleurs).

Le gros des mises à jour de pilotes sont pour l’USB et les pilotes graphiques, mais il y a aussi l’IIO, les DEL, les pilotes de plates‐formes, le DMA, etc.

Les mises à jour d’architectures sont surtout destinées aux machines ARM, mais il y a aussi quelques petites corrections pour x86.

Mais tout ça est assez petit, rien de particulièrement inquiétant.

Le journal abrégé est joint pour les gens qui veulent avoir un aperçu du genre de choses qui se sont passées.

Linus

RC-5

La version RC-5 est sortie le 26 juin 2016 :

Nouvelle semaine, nouvelle RC.

Hum. Je pense que ça se calme, bien qu’avec deux tiers des modifications arrivés à partir de vendredi matin, cela ne semble pas le cas — mes vendredis finissent par être très occupés. Mais à bien regarder les chiffres, nous en sommes là où nous sommes habituellement à ce stade des RC.

Les statistiques sont tout à fait normales : une moitié de pilotes, un quart de mises à jour d’architectures et le reste de divers : systèmes de fichiers, ordonnanceur, gestion de la mémoire, etc.

Les mises à jour de pilotes concernent surtout les pilotes graphiques, mais aussi RDMA, hwmon, Xen, GPIO et son.

Du côté des architectures, PowerPC, x86, un peu d’ARM64, et un peu de bruit un peu partout dû au nettoyage de la gestion de la mémoire.

Allez‐y, testez. Avec la RC-5, nous devrions commencer à être pratiquement prêts.

Et, s’il vous plaît, si Thorsten Leemhuis suit une de vos régressions, pouvez‐vous vérifier et revérifier si elle demeure ? C’est plaisant de disposer à nouveau d’un suivi des régressions, mais il serait bien également de s’assurer que celles qui sont réglées soient fermées.

Linus

RC-6

La version RC-6 est sortie le dimanche 3 juillet 2016 :

Hum… Une autre semaine, une autre RC.

J’aimerais vraiment dire que ça se calme et que l’on se rapproche, mais ce serait un mensonge.

Ce n’est pas comme si c’était une énorme RC, mais elle est vraiment plus grosse que les RC précédentes. Je ne pense pas que ce soit réellement un gros problème, car il semblerait que ce soit plutôt dû au calendrier. Nous venons d’avoir des fusions en provenance de la plupart des sous-systèmes (par exemple, le réseau de Davem et tous les sous‐systèmes de pilotes de périphériques habituels de Greg, sans parler des mises à jour des pilotes graphiques et de tous les autres mainteneurs de sous‐systèmes). Mais le réseau (à la fois les pilotes et le code principal) est la partie la plus notable.

Les détails sont, comme d’habitude, dans le journal résumé ci‐joint.

Attendons de voir comment ça se passe la semaine prochaine. Un pur hasard ou l’émergence d’une mauvaise tendance ?

Linus

RC-7

La version RC-7 est sortie le dimanche 10 juillet 2016 :

Nous avons eu une semaine bien calme, ce que j’attendais — la dernière RC était plus grosse uniquement en raison de problèmes d’aléas de calendrier et non un changement inquiétant à ce moment du cycle de sortie. Ouf.

Quoi qu’il en soit, il y a quelques régressions encore en cours d’observation, mais à moins que quelque chose de bizarre ne survienne, ce sera la dernière RC. Cependant, en raison du calendrier de mes voyages, je ne ferai pas la version finale 4.7 la semaine prochaine et les gens auront deux semaines pour rapporter (et corriger) les bogues restants.

Oui, c’est votre chance. Mon calendrier de travail ne va pas mettre le bazar, voyez plutôt cela comme si vous aviez une SEMAINE DE BONUS ! Ouais !

Bon d’accord, mon calendrier de travail va probablement mettre le bazar pour quelqu’un et je m’en excuse d’avance. Mais, bon, même ce délai bien planifié peut évidemment changer, si quelqu’un trouve un vrai bogue tueur. Mais ça ne semble pas du tout le cas, vu que le cycle de sortie n’a pas été particulièrement gros ou effrayant.

Mais, allez donc le tester. Le journal abrégé donne les détails sur ce qui s’est passé durant cette calme semaine, mais globalement tout est très normal : deux tiers de pilotes (réseau, son, GPIO et divers), avec le reste partagé à peu près équitablement entre des corrections d’architectures et du « divers » (en l’occurrence, principalement le cœur du noyau, du réseau et eCryptfs). Mais tout cela est plutôt petit.

Linus

Version finale

La version finale est sortie le dimanche 24 juillet 2016 :

Donc, après un léger retard dû à mes voyages, je suis de retour et la version 4.7 est sortie.

Bien que la RC-7 soit sortie il y a deux semaines, les correctifs finals n’étaient pas si conséquents que ça et la majorité d’entre eux étaient triviaux — souvent d’une ou quelques lignes. Il y a eu quelques pilotes réseau qui ont reçu plus d’attention. En annexe, le journal des modifications depuis la RC-7, pour les personnes intéressées : c’est plutôt varié, avec du réseau, des correctifs sur le processeur graphique Intel Kabylake pour les plus notables. Il y a également eu de petites retouches un peu partout.

Et, bien entendu, ça signifie que la fenêtre d'intégration pour la version 4.8 est ouverte. D’après le contenu de linux-next, ça va être une plus grosse version que l’actuelle (la version 4.7 a été vraiment calme, la faute en revient au moins en partie à l’été dans l’hémisphère nord).

Linus

Les nouveautés

Architecture

CPUFreq et PState

Le noyau 4.7 ajoute une nouvelle option de gestion de fréquence (schedutil) plus « intelligente », qui utilise des informations plus précises et permet une latence plus faible en cas de modification de charge pour effectuer ses changements de fréquence. Malgré sa relative simplicité, ce mode propose déjà des résultats encourageants. Le travail effectué ici pose les bases pour des traitements futurs plus efficaces.

Gestion de la mémoire

Les tâches de compression async ont vu leurs latences réduites, ce qui est utile sur les systèmes n’ayant plus assez de mémoire et cherchant à optimiser la mémoire allouée.

Dans cet ordre d’idée, l’OOM (Out of Memory killer), a été amélioré pour être plus fiable (cf. explications en anglais sur LWN.net).

L’ordonnanceur SLAB dispose d’une nouvelle option CONFIG_SLAB_FREELIST_RANDOM pour améliorer la sécurité en ajoutant de l’aléatoire pour les allocations. Cela permet de rendre moins prédictibles ces dernières, et ainsi de compliquer la tâche d’exploitation des débordements de pile.

ARM

Nouveaux systèmes monopuces gérés :

• Oxford Semiconductor OX810SE (comme discuté ici) ;
• Qualcomm IPQ4019.

Nouvelles cartes gérées :

• Aspeed ast2500/ast2400 ;
• TI dra72-evm rev C (SR2.0) ;
• Western Digital My Book World Edition (basé sur OX810SE) ;
• Amazon Kindle Fire (première génération) codename kc1 ;
• Arrow Electronics DB600c (basé sur Qualcomm APQ8064) ;
• Embest MarS, Ka-Ro MB7 + modules + TXUL, pico-hobbit (basés sur i.MX6) ;
• Nitrogen6_MAX QP / Nitrogen6_SoloX (basés sur i.MX6) ;
• Baltos IR2110/IR3220 ;
• ICEv2 basé sur AM33X ;
• MPS2 AN385/AN386/AN399/AN400 ;
• Linksys EA4200v2/EA4500 ;
• KuroBox-Pro (basé sur orion5x) ;
• MiQi de mqmaker (basé sur Rockchip) ;
• Samtec VIN|ING ;
• tablettes Dserve DSRV9703C, Difrence DIT4350, Colorfly e708 q1, Polaroid MID2809PXE4 (basés sur systèmes monopuces Allwinner) ;
• carte de développement ZII ;
• IPQ4019 DK01 ;
• Google Pixel C.

Allwinner

• A13/R8 : gestion du moteur d’affichage (DE) ;:
• A10/A20 : prise en charge du S/PDIF ;
• A31/A23/H3 : Amélioration de la gestion de l’audio ;
• H3 : gestion de l’USB ;
• tablettes : Dserve DSRV9703C, Polaroid MID2809PXE4, Colorfly e708 q1, Difrence DIT4350 ;
• cartes : Olimex A20 OLinuXino LIME2, Orange Pi 2, Orange Pi One, et l’Orange Pi PC.

Rockchip

• cartes : Geekbuying GeekBox, RK3399 Evaluation Board, mqmaker MiQi SBC.

Amlogic

• carte : Hardkernel ODROID-C2.

Samsung

• pilote générique Exynos de gestion de la fréquence du bus ;
• prise en charge du ARTIK5 ;
• ajout d’un régulateur pour la eMMC/SD des cartes ODOID XU3 et XU4 ;
• corrections et nettoyages divers.

Qualcomm

• ajout de la gestion du BQ27541 du Nexus 7 ;
• meilleure prise en charge du 96Boards HiKey (Kirin 620) dans le DT ;
• ajout du Qualcomm IPQ4019 (« Internet processor ») ;
• gestion des cartes Arrow DragonBoard 600c de 96boards (Snapdragon 600).

Mediatek

• pilotes graphiques pour Mediatek MT8173 (DRM).

MIPS

• ajout de la gestion de la délocalisation du noyau, permettant ainsi de passer outre la limitation de 1 Mio ;
• ajout du KASLR grâce à la gestion de la délocalisation ;
• ajout des compteurs de performances (perf counters) ;
• gestion de la ligne de commande étendue ;
• ajout de la prise en charge de DPT-Module, Dragino MS14 (Dragino 2) et Onion Omega ;
• ajout de la gestion de BCM6358, Whirlwind (BMIPS5200) et BCM63268 ;
• ajout d’un essai préliminaire pour les Loongson 3A ;
• ajout de la prise en charge des CN73xx, CN75xx et CN78xx ;
• ajout de la prise en charge du D-Link DSR-1000N ;
• ajout de la détection du DSP v3, et du MIPSr6 (processeur virtuel) ;
• gestion de l’envoi de SIG_SYS à l’espace utilisateur 32 bits depuis un noyau 64 bits.

Développement

USB/IP

Ce projet déjà mature, est enfin intégré comme système à part entière dans le noyau. Il permet de partager de manière générique des périphériques USB à travers le réseau. Techniquement, cela n’est qu’une encapsulation des trames d’entrées‐sorties dans des trames TCP. Il y a deux parties à ce projet, une côté serveur qui permet de mettre à disposition les périphériques USB connectés à l’hôte, et l’autre, côté client, qui permet de se connecter au serveur et de connecter des périphériques USB comme s’ils étaient en accès direct. Si le serveur est pour le moment réservé à Linux, le client est également disponible pour Windows, permettant ainsi à ce dernier l’accès à des périphériques présentés par le serveur.

Cette fonction vient avec deux outils : usbip et son daemon, usbipd :

• usbip attach remote=host ;
• usbip detach port=port ;
• bind --busid=<busid> ;
• unbind --busid=<busid> ;
• list --remote=host ;
• list --local ;

Hist Trigger

Cette nouvelle fonctionnalité de traçage permet d’ajouter la création d’histogrammes de manière efficiente et personnalisée. Le blog de Brendan Gregg explique bien cette fonctionnalité et son fonctionnement.

Le répertoire /sys/kernel/debug/tracing/events/ contient un ensemble d’éléments qu’il est possible de tracer :

• probe_libc/malloc/ va par exemple permettre de tracer la fonction malloc() ;
• raw_syscalls/sys_enter/ va, par exemple, permettre de tracer l’ensemble des appels système.

Pour activer les histogrammes sur ces exemples, positionner le déclancheur correctement, hist:key=common_pid.execname, par exemple. Cela permet pour la durée du traçage, de récupérer le nombre d’appels pour chaque numéro de processus et nom d’exécutable.

Cette fonction, qui a pour nom CONFIG_HIST_TRIGGERS n’est pas activée par défaut.

Pilotes graphique libres

AMDGPU

Ajout de la prise en charge des processeurs graphiques Polaris dans amdgpu, notamment avec la prise en charge de sa première implémentation, la carte Radeon RX 480.
cf. http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Linux-4.7-Is-Big.

Réseau

Pilotes

Le pilote w5100 prend désormais en charge le mode série (SPI) pour les cartes réseau basées sur les contrôleurs Wiznet W5100 et W5500.

Bufferbloat

Le bufferbloat est défini comme l’excès de mise en tampon (buffering) des paquets, ce qui conduit à de fortes latences, une surconsommation processeur et un faible débit réseau.
La méthode fq_codel_drop() n’est pas optimale, elle effectue un balayage sur 4 Kio pour trouver un fat flow au lieu de supprimer un simple paquet. Sur une charge engorgée (flood) de 900 Mbits, nous passons d’une consommation processeur de 88 % à moins de 10 %.

Autre

Partial segment offloading explications

L’idée est d’élargir la GSO à une gamme plus large de périphériques, d’avoir des en‐têtes fixes et de faire en sorte que le matériel gère seulement la segmentation de l’en‐tête interne.

TCP préemptible

La couche réseau TCP est maintenant préemptible, ce qui permet de la mettre en pause sur l’opération potentiellement bloquante et de récupérer du temps processeur, pour essayer de lutter contre les « pics de latence fous ».

RPS et RFS

Le protocole Stream Control Transmission Protocol (SCTP) prend en charge le RPS (Receive Packet Steering) et RFS (Receive Flow Steering) pour améliorer la montée en charge sur plusieurs processeurs.

Socket

Optimisation du bit ASYNC pour les sockets.

Sécurité

LoadPin

Un nouveau module de sécurité a été introduit dans cette version. Ce dernier permet de restreindre la provenance des fichiers chargés par le noyau (micrologiciels, modules…). Il s’assure que tous les modules viennent d’un même et unique système de fichiers et que ce dernier est intègre et inaltérable.

Clefs de chiffrement

• ajout de fonction en espace utilisateur pour l’accès aux calculs de Diffie‐Hellman via l’appel système KEYCTL_DH_COMPUTE ;
• ajout d’aide pour une gestion simplifiée des clefs, avec une plus grande facilité de définition des règles de vérification ;
• les grandes clefs sont désormais stockées avec chiffrement.

Divers

• ajout d’un champ tty à l’événement d’ouverture de session (LOGIN). Cela permet ainsi de savoir depuis quel terminal la tentative d’ouverture de session est effectuée.

Systèmes de fichiers

Recherche parallèle dans les dossiers

Cette optimisation permet d’accélérer la recherche de tâches concurrentes pour trouver plusieurs dossiers sur le disque ; les performances et la consommation processeur devraient être meilleures sous forte charge (passage de mutex à des sémaphores lecture‐écriture). La plupart des systèmes de fichiers sont concernés.

ext4

Pas mal de corrections dont un crash potentiel quand un fichier journalisé a une mauvaise allocation différée et qu’elle n’a pas encore été écrite.
Correction de problèmes lors du manque d’espace disque.

Correction pour DAX (direct access : supprime la copie supplémentaire en lisant et écrivant directement dans le périphérique de stockage).

La lecture de grands répertoires avec de nombreux blocs vides prenait du temps et agaçait avec les longs temps d’attente. Désormais, l’utilisateur ou l’ordonnanceur pourront interrompre le processus de lecture.

F2FS

Diverses corrections de sécurité, de bogues et améliorations des performances (surtout du côté des allocations).

XFS

Correction, nettoyage, améliorations mineures (cf. Système de blocs ci‐dessous).

Btrfs

Beaucoup de corrections, surtout pour les différents systèmes de synchronisation qui permettent aux applications d’être sûres que l’écriture a été faite sur le disque.

La compatibilité avec OverlayFS est enfin réalisée, grâce à la prise en charge des opérations de renommage RENAME_EXCHANGE et RENAME_WHITEOUT.

NFS

Depuis le noyau 4.5, la copie de fichiers par morceau (copy_file_range) était prise en charge.
Désormais, la copie d’un fichier en entier sera prise en charge directement par le noyau, mais de façon synchrone seulement, a priori.

Système de blocs

Dans le système de blocs, l’ajout de async discard permet de ne plus bloquer les autres couches et de travailler pendant ce temps‐là.
Après adaptation des systèmes de fichiers pour l’exploitation de cette fonctionnalité, les performances devraient être meilleures. Pour l’instant, seuls XFS et le pilote NVMe en profitent.

Des corrections, nettoyages d’interface et quelques optimisations ont été faits. Maintenant le blk-mq (Device Mapper multiple queue) se fait sans verrou, ce qui permet une meilleure exploitation en multiprocesseur, surtout dans le cas de processeurs sur des puces différentes (multi‐socket), le gain en cas de multiples cœurs sur une même puce étant moindre.

Virtualisation

KVM

Création d’un répertoire debugfs et des fichiers stat pour chaque machine virtuelle, nommés d’après leur numéro de processus (PID). Ce répertoire contient la même chose que le répertoire KVM précédent, mais avec des stats spécifiques pour chaque machine virtuelle.

virtio

Ajout d’outils de mesures.

Le bilan en chiffres

Le noyau

Pour le noyau, l’évolution moyenne du nombre de lignes de code par RC est globalement stable pour cette version 4.7, comme le montre le graphique suivant :

Si on regarde l’évolution du nombre de lignes de code par version, on constate que le noyau 4.7 est dans la moyenne de la série des 4.x :

Nombre de commits Git par utilisateur :

Nombre de lignes modifiées par utilisateur :

Origine des contributions :

Origine des contributeurs du noyau :

La dépêche

La rédaction de cette dépêche s’est étendue sur quatre mois (du 14 mai au 19 août), avec plus de 410 éditions et 25 contributeurs).
N. D. M. : en fait plus de 500 éditions, jusqu’au 28 septembre.

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :

	Mainteneur	Contributeur(s)
La phase de test	Aucun
Arch	Romain Perier	Tiwaz
Développeurs	Romain Perier	Tiwaz
Pilotes graphiques libres	Martin Peres
Réseau	Aucun	BRULE Herman (alpha_one_x86)
Systèmes de fichiers	Aucun	BRULE Herman (alpha_one_x86)
Sécurité	Aucun
Virtualisation	Xavier Claude
Édition générale	Aucun	M5oul, jcr83, Davy Defaud

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Aller plus loin

• Dépêches des noyaux précédents (210 clics)
• Site officiel du noyau Linux (182 clics)
• Les nouveautés du noyau 4.7 (358 clics)