URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-4 Title: Sortie du noyau Linux 4.4 Authors: jcr83 esdeem, M5oul, superna, rogo, Florent Fourcot, Tiwaz, Yves Bourguignon, Benoît Sibaud, Sébastien Koechlin, Martin Peres, BAud, palm123, Olivier Esver, ɹǝıʌıʃO, Nÿco, Mohamed MEDIOUNI, Romain Perier, antistress, Siosm, Davy Defaud, TuxMips, ʭ ☯ , reynum, Dams Nadé, bobble bubble, patrick_g, david.g et goernil Date: 2015年11月16日T10:26:26+01:00 License: CC By-SA Tags: noyau_linux, sortie_version, coulisses, f2fs, linus_torvalds et lwn Score: 106 La sortie de la version stable 4.4 LTS du noyau Linux a été annoncée le 10 janvier 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://kernel.org/). Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche (qui est sous [licence CC BY-SA](http://creativecommons.org/licenses/by-sa/3.0/deed.fr), Attribution — Partage dans les Mêmes Conditions) ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [ Site officiel du noyau Linux](https://www.kernel.org/) [Die Neuerungen von Linux 4.4](http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-4-4-3053832.html) ---- #En bref * Au terme de deux années d’efforts, le code gérant TCP a été réorganisé, procurant une implémentation de bien meilleure qualité, avec des gains de performances pouvant dépasser 100 fois dans certains scénarios de serveurs TCP. * Un nouveau [mécanisme d’entrée/sortie](#lecture-sans-interruption-et-polling) fait son apparition. S’il est encore expérimental et désactivé par défaut, il pourrait à terme compléter le mode de lecture des périphériques en mode bloc, en permettant une lecture séquentielle à plus haut débit. * Le mécanisme [[BSD Packet Filter]] du noyau a connu plusieurs évolutions importantes. Le principal changement est l’ouverture partielle de l’API aux programmes non privilégiés ; un code en espace utilisateur peut désormais utiliser l’appel système `bpf()` pour placer un filtre sur un socket. Ce nouveau noyau permet aussi de créer des filtres persistants, c’est-à-dire, qui peuvent être conservés malgré l’arrêt du processus, puis repris par un nouveau processus. Enfin, ce système eBPF a été intégré à perf, l’outil de mesure des performances interne à Linux. * Les utilisateurs de partitions ext4 **chiffrées** sont [encouragés](#ext4) à passer à Linux 4.4 ou à utiliser des noyaux dans lesquels les corrections ont été rétro-portées : un bug menant à une corruption de données a été corrigé, ainsi qu’une fuite de mémoire. * Comme d’habitude, la grande majorité des _commits_ est consacrée aux pilotes de matériel, tant pour améliorer la gestion de l’existant (portables Toshiba, etc.) que pour accepter de nouveaux matériels (nouvelle puce Realtek WiFi USB, Intel Skylake W8 touchpad, etc). #Annonces des RC par Linus Torvalds ##RC-1 La version [RC-1](https://lkml.org/lkml/2015/11/15/168) est sortie le dimanche 15 novembre 2015 : C’est dimanche, deux semaines sont passées et par conséquent, la 4.4-RC1 est parue et la fenêtre de fusion fermée. Comme d’habitude, l’historique complet des changements est trop important pour être publié, vous trouverez donc en annexe le journal des fusions montrant l’origine des intégrations avec un petit commentaire sur chaque fusion. Si on regarde l’ensemble des modifications en elles-mêmes, tout semble plutôt normal d’un point de vue général, même si les pilotes représentent peut-être une plus grosse part que d’habitude (75 % des correctifs) et les mises à jour d’architectures environ 10 %. Les 15 % restants se répartissent entre la documentation, les systèmes de fichiers, le cœur du réseau (par opposition aux pilotes réseau), l’outillage et les infrastructures cœur. Les changements sur les pilotes sont partout, bien que les pilotes de préproduction, de réseau et de GPU ressortent (et ces trois parties comptent pour plus de la moitié des changements sur les pilotes – aux alentours de 40 % de l’ensemble des changements). Du côté des architectures, l’ARM (en prenant en compte le 32 et le 64 bits) compte pour à peu près la moitié des changements, alors que x86, PowerPC, MIPS, chris et S390 comptent pour l’autre moitié. Allez-y, testez. Linus ##RC-2 La version [RC-2](https://lkml.org/lkml/2015/11/22/207) est sortie le dimanche 22 novembre 2015 : Tout semble plutôt normal du côté de la 4.4 sans grosses surprises dans la RC-2. Il y a eu quelques ajouts tardifs de fonctionnalités : la prise en charge des _hugepages_ sur [PA-RISC](https://fr.wikipedia.org/wiki/PA-RISC) et quelques corrections concernant l’allocateur mémoire noyau [slub](http://en.wikipedia.org/wiki/SLUB_(software)) ont seulement été fusionnées à la fin de cette semaine, mais à vrai dire, elles auraient dû faire partie de la fenêtre de fusion. Mais le système d’allocation mémoire de masse n’est pas encore vraiment _utilisé_ dans l’arborescence et donc, les mises à jour de ce côté portent sur une utilisation future plutôt que sur quelque chose qui pourrait régresser. Quant à PA-RISC, je n’arrive pas à trouver une raison de m’en inquiéter : je mets volontiers au défi tout utilisateur de PA-RISC de me prouver le contraire et de montrer comment la nouvelle fonctionnalité provoque une régression. Amenez-vous pour voir. Le gros des changements depuis la rc-1 (de loin) se situe dans les pilotes (environ 70 % de correctifs — les pilotes réseau et GPU en représentant la plus grande part), avec des mises à jour d’architecture (12 %, avec PA-RISC et S390 étant les deux plus grosses mises à jour) et la base réseau (8 %) étant l’essentiel du reste. Les 10 % restants sont dispersés ; fs (systèmes de fichiers), mm (gestion de la mémoire) et les outils de performance en représentant la plus grande part. Le journal abrégé est joint. Vous pouvez y voir un aperçu des changements. Je ne peux pas vraiment dire qu’il en ressorte quelque chose de particulier. Allez-y, testez. Linus ##RC-3 La version [RC-3](https://lkml.org/lkml/2015/11/29/293) est sortie le dimanche 29 novembre 2015 : Je suis sorti presque toute la journée, donc, elle arrive quelques heures plus tard que d’habitude, mais elle est là, la RC hebdomadaire usuelle. « Progrès constant vers la 4.4 ». Les changements semblent plutôt normaux : un peu moins de 60 % de mise à jour de pilotes (parmi lesquels près de la moitié sont des mises à jour de GPU, cette fois principalement biaisé par des correctifs de mises à jour des firmwares _nouveau_), environ 25 % de mises à jour d’architectures (principalement arm[64], mais aussi quelques changements dans x86, s390, powerpc, nios, mips, m68k, [arc](https://www.synopsys.com/dw/ipdir.php?ds=sw_linux)...) et environ 10 % de mises à jour de systèmes de fichiers. Le reste étant « divers » (principalement des fichiers d’en-tête). Le journal abrégé ci-joint donne un aperçu des détails. Je ne pense pas qu’il y ait grand-chose d’enthousiasmant, bien que cela dépende évidemment du fait que vous ayez été affecté par un problème particulier, ou pas. Il est constitué principalement de petites corrections diverses. Linus ##RC-4 La version [RC-4](https://lkml.org/lkml/2015/12/6/137) est sortie le dimanche 6 décembre 2015 : Une nouvelle semaine, une nouvelle rc. Nous avons eu un peu plus de _commits_ que la semaine dernière (principalement dus à la fusion des correctifs réseau), mais dans l’ensemble, ça a été plutôt calme. Tout semble plutôt normal : environ 70 % de pilotes – les pilotes réseau, gpu, audio, et scsi dominent. De surcroît, nous avons 15 % de cœur de réseau et le reste est partagé entre mises à jour d’architectures et choses diverses un peu partout (dont quelques correctifs vfs et cœur du noyau). Le journal abrégé en annexe donne une vue d’ensemble des détails, il est suffisamment petit pour qu’on puisse facilement le lire en diagonale. Linus ##RC-5 La version [RC-5](https://lkml.org/lkml/2015/12/13/228) est sortie le dimanche 13 décembre 2015 : Une nouvelle semaine, une nouvelle rc. La semaine a été plutôt tranquille et la RC-5 a l’air plutôt normale. Il y a eu un assez méchant bug primordial, introduit dans la RC-4, qui est désormais corrigé dans la RC-5, mais bien que cela soit un peu gênant, je ne crois pas que beaucoup de personnes aient rencontré le problème. Mis à part ce petit problème, les choses sont tout à fait normales et il n’y a vraiment pas beaucoup de changements, et ils sont tous assez petits pour démarrer. Donc, tout semble bon, et je pense que nous sommes sur la bonne voie pour le calendrier de sortie habituel, ce qui devrait nous amener à une version 4.4 très tôt en 2016. Je suis enclin à retarder cette version d’une semaine non pas à cause des problèmes de parution, mais tout simplement parce que je sais que les prochaines semaines vont être calmes et la plupart des gens veulent se concentrer sur autre chose que de se préparer pour la prochaine fenêtre de fusion. On verra. Je devrais en finir et sortir la 4.4 à temps et ensuite décaler la fenêtre de fusion. Quoi qu’il en soit, si vous avez tous finalisé vos achats de Noël, je recommande chaudement de s’intéresser de près à la RC-5 entre les cadeaux et la décoration. Et si vous ne célébrez pas les fêtes, vous n’avez aucune excuse pour ne pas tester tout ça. Linus ##RC-6 La version [RC-6](https://lkml.org/lkml/2015/12/20/193) est sortie le dimanche 20 décembre 2015 : Tout continue normalement. Si la RC-5 de la semaine dernière était effectivement très petite, la RC-6, cette semaine, est un peu plus grosse. La principale différence est que la RC-6 intègre un changement réseau. Mais, la RC-6 est toujours aussi petite, et les correctifs sont normaux : au-delà de 60 % pour les pilotes, 16 % pour le cœur de la gestion réseau, 13 % pour des mises à jour d’architectures et 10 % pour des choses diverses (de la documentation, des en-têtes de fichiers, de petites mises à jour du système de fichiers, etc.). Vous pouvez consulter les changements joints pour avoir une idée de ce qu’il s’est passé. Je pense (et j’espère) qu’avec les vacances, la semaine prochaine continuera à être calme. Et peut-être, je peux espérer que les gens utilisent la coupure pour jouer avec leur matériel et tester la plus récente version du noyau. Linus ##RC-7 La version [RC-7](https://lkml.org/lkml/2015/12/27/215) est sortie le dimanche 27 décembre 2015 : Noël est fini, et voilà le Nouvel An, mais il n’y a pas de repos pour les développeurs noyau, et la RC-7 est par là. [En regardant le patch RC-7] OK, clairement il y a un peu de repos pour les développeurs noyau, car la rc7 est plutôt minuscule. Je pense qu’un tiers du patch provient des mises à jour de SPARC, et ils ne sont pas énormes non plus. Le reste provient des autres architectures (x86, PA-RISC, MIPS, ARM, arc), des pilotes (gpu, sound, mtd...) et quelques mises à jour pour compiler. Mais tout est plutôt petit. J’espère la même chose la semaine prochaine, quand je serai certainement prêt à publier la 4.4 finale, mais je vais probablement faire une RC-8 juste pour ne pas ouvrir la fenêtre de fusion alors que les gens sont toujours en vacances. Linus ##RC-8 La version [RC-8](https://lkml.org/lkml/2016/1/3/261) est sortie le dimanche 3 janvier 2016 : En général, lorsque je fais une huitième RC, c’est qu’il reste un problème non résolu qui nécessite plus de temps pour être réglé. Cette fois, c’est seulement que je veux être certain que tout le monde est rentré de vacances et qu’il ne reste rien en cours, et que tous auront le temps de préparer leurs demandes d’intégration pour la prochaine fenêtre. Vous n’aurez aucune excuse si vous n’avez pas terminé vos travaux lorsque la fenêtre d’intégration s’ouvrira. Les changements se trouvent dans les endroits habituels, et sont plutôt petits. On y trouve pour moitié des pilotes (principalement des pilotes de réseau, mais aussi du rdma et quelques autres changements mineurs) et pour le reste des mises à jour d’architectures (surtout SPARC, ARM), du code réseau et quelques corrections dans la cryptographie. Mais c’est vraiment très petit. C’est bien comme ça que ça doit être, avec les vacances et la fin du cycle. Attendez-vous à la sortie de la version 4.4 finale le week-end prochain, sauf si quelque chose de très inattendu survient. Linus ## Version finale La version [finale](https://lkml.org/lkml/2016/1/10/305) est sortie le dimanche 10 janvier 2016 : Rien de fâcheux n’est arrivé cette semaine, donc Linux-4.4 est disponible dans tous les endroits habituels. Les changements depuis la RC-8 ne sont pas énormes. Il y a environ un tiers de mises à jour d’architectures, un tiers de pilotes et un tiers « divers » (principalement du cœur de noyau et du réseau), mais c’est tout petit. Ce qui serait notable comprend la remise en état de l’ABI _sysenter_ pour x86-32, que quelqu’un (*tousse*android-x86*tousse*) a mal utilisé en ne recourant pas au [vdso](https://en.wikipedia.org/wiki/VDSO) et utilisant cette instruction à la place. L’historique complet est annexé pour les personnes intéressées ou simplement curieuses. Et avec ça, la fenêtre de fusion pour la 4.5 est évidemment ouverte, même si je ne vais pas vraiment commencer l’intégration demain. Linus #Les nouveautés ##Gestion de la mémoire L’appel système `mlock()` permet de verrouiller en mémoire une zone d’adressage d’un programme qui contient des données cruciales (cryptographie, etc). Mais en pratique, ce verrou est parfois excessif, car on bloque une large zone de mémoire dont on ne se sert que très partiellement. Le noyau 4.4 introduit `mlock2()` qui permet des verrous reportés (*deferred memory locking*). Cette gestion plus fine de la mémoire permettra donc de diminuer certaines consommations de mémoire. Pour plus d’informations, voir la nouvelle page de [man mlock](http://man7.org/linux/man-pages/man2/mlock.2.html) et [(LWN) Deferred memory locking](http://lwn.net/Articles/650538/). Une autre modification structurelle a permis de nettoyer le code d’allocation de la mémoire. La structure `zonelist_cache`, introduite en 2006, était une source récurrente de problèmes, notamment sur les architectures [NUMA](http://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access). Plutôt que de continuer à accumuler des aménagements sur ce code, une réécriture a permis de supprimer cet élément, avec performance [généralement inchangée](https://lkml.org/lkml/headers/2015/9/21/204), voire meilleure. Ce n’est pas souvent qu’on retire 240 lignes de code du noyau. Pour plus de détails, lire l ́article de LWN : [Some kernel memory-allocation improvements](http://lwn.net/Articles/658081/). ##Architecture ### ARM [SoC](https://fr.wikipedia.org/wiki/Système_sur_une_puce) - [Raspberry Pi](https://www.raspberrypi.org/) : ajout d ́un pilote pour communiquer avec le firmware, voir [plus loin](//linuxfr.org/news/sortie-du-noyau-linux-4-4#broadcom-pilote-vc4-rpi) pour plus de détails. - [i.MX6PU](http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors-based-on-arm-cores/i.mx-6-processors/i.mx6qp/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL) : [ajout](http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/361877.html) de la prise en charge du mode veille (*suspend/resume*) de ce SoC de Freescale. - [C.H.I.P](http://getchip.com/) : [intégration](http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371072.html) de la prise en charge du chipset Allwinner R8 présent dans cette carte. Il manque encore la gestion du Wifi (dépendante de deux régulateurs pour être alimenté) et du codec audio qui n’est pas encore activé dans le DeviceTree. - ARM SCPI : ajout d ́un pilote pour le SCPI (Système de contrôle du Processeur), un système utilisé pour communiquer avec le système embarqué de gestion de consommation. - Rockchip RK3288 : [ajout](https://lkml.org/lkml/2015/8/12/12) des domaines de puissance (Power Domain) compatible avec le module `genpd` qui permet de contrôler chaque domaine et de couper le courant de manière dynamique si le module n’est plus utilisé ou en veille. - Divers : prise en charge du [changement de CPU à chaud](https://lkml.org/lkml/2015/7/7/86) pour la série des BG2Q de Marvell berlin, et du [SMP](http://lists.infradead.org/pipermail/linux-mediatek/2015-August/001886.html) pour les 4 cœurs Cortex-A7 du SoC Mediatek MT6580. [Prise en charge initiale](https://lkml.org/lkml/2015/8/26/732) de la famille de SoC Northstar Plus de Broadcom à base de Cortex-A9. - Plusieurs mises à [jour ARM64](https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-ARM64-Coming), comme une meilleure détection des fonctionnalités des cœurs ARM64 (en particulier sur des systèmes hétérogènes.), une implémentation native de fonctions atomiques et une optimisation des fonctions natives de copie depuis/vers l’espace utilisateur, ainsi qu’une mutualisation du code de gestion des compteurs de performance matériels (PMU) entre arm et arm64. - L’architecture **arm64** peut maintenant fonctionner avec des pages de taille 16 Kio. Cependant, [Linus a émis de sérieux doutes](https://lwn.net/Articles/663941) quant à son utilité dans le monde réel. Petite explication : l’argument en faveur d’une taille de page de 16 Kio est de pouvoir gérer plus de mémoire. Sauf qu’avec cette taille de page, vous perdez beaucoup de mémoire et augmentez la fragmentation. Cela a déjà été évoqué il y a quelques années par les personnes s’occupant de l’architecture PPC. Excepté dans des cas très spécifiques (un seul processus qui a besoin de beaucoup de mémoire et très peu de processus en parallèle), cet apport n’a que peu d’intérêt. ### MIPS - Support du programme universitaire [MIPSfpga](http://blog.imgtec.com/mips-processors/mipsfpga-opens-up-the-mips-architecture-to-universities-worldwide) qui permet aux universités du monde entier d’intégrer gratuitement un cœur [MIPS](https://fr.wikipedia.org/wiki/Architecture_MIPS) dans leurs projets ; - Grosse évolution et nettoyage du code de démarrage [MIPS](https://fr.wikipedia.org/wiki/Architecture_MIPS) qui tend à supporter le [Device Tree](https://en.wikipedia.org/wiki/Device_tree) aussi bien que son homologue ARM ; - Ajout du support d’un nouveau cœur de test [5Ke](https://www.linux-mips.org/wiki/5K). ##Développement et traçage L’outil de traçage du noyau [perf](https://perf.wiki.kernel.org/index.php/Main_Page) s’est enrichi d’une dizaine de fonctionnalités, allant d’une option pour [afficher en nanosecondes](https://git.kernel.org/torvalds/c/83e1986032dfcd3f9e9fc0d06e11d9153edae19b) les marqueurs de temps à la [configuration des événements](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e637d17757a10732fa5d573c18f20b3cd4d31245) à tracer. Une grande part de ces modifications est spécifique ou optimisée pour l’[Intel Processor Tracing](https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing). Le travail le plus conséquent fut l’intégration de perf à eBPF. Une commande comme `perf record --event bpf-code.c /bin/ls` permet désormais de compiler le code source [BPF](https://fr.wikipedia.org/wiki/BSD%20Packet%20Filter) et de charger ce filtre dans le noyau pour récupérer la trace noyau des événements sélectionnés. ##Pilotes graphiques libres ### Direct Rendering Manager Le code commun des pilotes DRM a gagné la capacité de sonder les différents CRTC et encodeurs disponibles pour les systèmes utilisant un *device tree*. Ce code permet de [factoriser le code de plusieurs pilotes](https://lists.freedesktop.org/archives/dri-devel/2015-October/093250.html). L’interface fbdev au-dessus des pilotes DRM utilise maintenant la gestion du mode graphique atomique lorsque celle-ci est disponible afin de [réduire le nombre de mises à jour du mode](https://www.spinics.net/lists/dri-devel/msg88897.html), et réduire ainsi les clignotements. Pour plus d’informations, vous pouvez consulter [la demande d’intégration DRM](https://lkml.org/lkml/2015/11/8/308). ### AMD (pilotes amdgpu et radeon) Les pilotes amdgpu et radeon [continuent d’évoluer](http://lists.freedesktop.org/archives/dri-devel/2015-October/092509.html), avec beaucoup de petites améliorations et un gros travail de fond avec l’ajout d’options de débogage, la gestion de nouveaux opcodes, l’activation du nouvel ordonnanceur GPU, et divers portages depuis radeon vers amdgpu. ### Broadcom (pilote vc4, RPi) Fruit de l’important travail débuté il y a un an et demi par Eric Anholt ([ex Intel, recruté à cet effet par Broadcom](https://www.phoronix.com/scan.php?page=news_item&px=MTcyMTc)), le pilote graphique libre pour les puces Broadcom VideoCore 4, utilisées par le Raspberry Pi, est maintenant intégré partiellement au noyau. Seules les parties KMS et 2D sont incluses ; la gestion 3D exigera de pouvoir se passer du _firmware_ propriétaire pour la gestion d’énergie puisque l’IOMMU refuse actuellement l’accès au registre depuis les processeurs ARM ; les registres sont également non documentés. Le code inclut la gestion de HDMI, sans HDCP. Il est encore impossible d’initialiser le système sans logiciel propriétaire. La gestion de la 3D fera son apparition dans Linux 4.5 ([commit](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/vc4?id=21de54b3c4d08d2b20e80876c6def0b421dfec2e)). ### Intel (pilote i915) Le processus de conversion du pilote i915 vers une gestion atomique du mode graphique continue avec l’ajout d’une base solide permettant de s’approprier le mode graphique utilisé par le firmware EFI (fastboot). Malheureusement, un bug a été trouvé tard dans le code ce qui a forcé à désactiver le code par défaut. À propos de la gestion atomique encore, le code permettant la validation et gestion dynamique de la fréquence d’horloge des CRTC [introduit dans Linux 4.3](//linuxfr.org/news/sortie-du-noyau-linux-4-3) vient d’être porté dans le monde atomique. Toujours côté affichage, la gestion du rafraîchissement automatique des panneaux (Panel Self-Refresh) et la gestion de la compression du framebuffer ont fortement avancé. Le PSR devrait être activé dans Linux 4.6 et devrait permettre de diminuer la consommation électrique. L’espace d’adressage passe maintenant à 48 bits pour les processeurs Broadwell+ (génération 8), ce qui devrait permettre de gérer une plus grande quantité de mémoire, mais surtout va permettre d’avoir un espace d’adressage partagé entre le CPU et le GPU. L’envoi de commande via le microcontrôleur GuC est maintenant géré, mais pas encore activé par défaut. Le GuC devrait à terme être un ordonnanceur et être responsable de la gestion d’énergie. Pour plus d’informations, vous pouvez consulter le [traditionnel article de blog](http://blog.ffwll.ch/2015/12/neat-drmi915-stuff-for-44.html) de Daniel Vetter, le mainteneur i915. ### NVIDIA (pilote nouveau) Le pilote nouveau a reçu de nombreuses améliorations liées à la gestion d’énergie, notamment le _reclocking_. Roy Spliet a en effet ajouté la gestion du _reclocking_ de la mémoire GDDR3 pour les GPU G94-G200 ([commit](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=0d42743dfa908a2ca4e349f883361906ebb4db95)). Karol Herbst a quant à lui amélioré la fonction de calibration des PLL générant l’horloge de la mémoire GDDR5 pour les familles Kepler+ ce qui permet un _reclocking_ bien plus fiable ([commit](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=78eaf335e4c8224e74e5d512f20ec48109db9dac)) ! Ben Skeggs a également perfectionné la détection des GPU ayant leur moteur 3D désactivé au démarrage (PGOB = Power Gating On Boot) et activé sa gestion pour le chipset GK107. Pour finir avec la gestion d’énergie, Martin Peres a ajouté la gestion des contrôleurs de tension commandés en modulation de largeur d’impulsion (PWM) qui sont très courants pour les GPU Maxwell et certaines cartes Kepler. Alexandre Courbot de NVIDIA a profité des nouvelles fonctionnalités apportées par la réécriture du cœur de Nouveau ([Linux 4.3](//linuxfr.org/news/sortie-du-noyau-linux-4-3#nvidia-pilote-nouveau)) pour améliorer les performances des accès à la mémoire d’instance. Le nouveau code est [40 % plus rapide](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=69c4938249fb48aeed32fd76c67972e71f471cd2). Il a également converti le code de gestion de la mémoire vidéo pour utiliser la nouvelle API de Linux pour le DMA. ### Autres Le pilote `virtio-gpu`, [présenté dans la dépêche Linux 4.2](//linuxfr.org/news/sortie-du-noyau-linux-4-2#virtio-pilote-virtio-gpu), a enfin reçu la gestion de la 3D dans le noyau. Le code nécessaire en espace utilisateur a été écrit, [fusionné dans Mesa en octobre](a8987b88ff1db4ac00720a9b56c4bc3aeb666537) et sorti en version 11.1 (décembre 2015). Les changements nécessaires pour QEMU sont eux disponibles à partir de la version 2.5, sortie en décembre 2015. Pour plus d’informations, vous pouvez consulter [une vidéo de démonstration](https://www.youtube.com/watch?v=_LqpRbVCEuc) ainsi que la page du projet [Virgil3D](https://virgil3d.github.io/). Le pilote msm pour les GPU Qualcomm ajoute une gestion expérimentale du Snapdragon 820. ##Réseau ###Optimisation de la poignée de main TCP La [poignée de main TCP](https://fr.wikipedia.org/wiki/Transmission_Control_Protocol#.C3.89tablissement_d.27une_connexion) est critique pour plusieurs raisons : elle introduit de la latence avant le moindre transfert de données et elle est source d’une vulnérabilité permettant des attaques par déni de service. La réorganisation de cette poignée de main et l’optimisation des performances est un travail de longue haleine qui a atteint un point très intéressant dans cette version grâce à la [suppression d’un verrou](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e994b2f0fb9229aeff5eea9541320bd7b2ca8714) dans la procédure gérant les paquets SYN. Si on prend du recul, cette poignée de main est désormais [10 à 100 fois plus rapide qu’il y a deux ans](http://thread.gmane.org/gmane.linux.network/380654). L’ordinateur de test du développeur est capable de gérer 3,5 millions paquets SYN par secondes, tout en ayant encore du temps CPU disponible. ###Encore plus rapide avec SO_REUSEPORT Toujours à propos de cette poignée de main, l’option [SO_REUSEPORT](https://lwn.net/Articles/542629/) permet à plusieurs sockets d’écouter sur le même port, permettant notamment d’améliorer les performances avec un serveur multithreadé. Cette option a elle aussi été optimisée, permettant d’arriver à [six millions de paquets SYN](http://thread.gmane.org/gmane.linux.network/381777) par seconde, sur la même machine de test que citée dans le paragraphe précédent. ### Et si on ajoutait la gestion fine de CPU ? Et ce n’est pas terminé. L’option SO_INCOMING_CPU existait en lecture depuis 2014 et permettait de connaître le processeur gérant le flux de données TCP de la socket. À présent, cette option est également [accessible en écriture](https://patchwork.ozlabs.org/patch/527795/) (via `setsockopt()`) et permet à une application de spécifier le processeur qui devrait gérer la socket. Cela étend l’idée de l’option SO_REUSEPORT, en permettant à chaque fil d’exécution d’une application de se positionner sur un processeur particulier. ###Nouvelles méthodes de détection de pertes de paquets Toujours sur TCP (et encore par un développeur de chez Google, la même entreprise que pour les optimisations de performance), une nouvelle méthode de détection de paquets perdus arrive dans le noyau Linux. Savoir si un paquet a été perdu est un problème non trivial, mais essentiel de TCP, notamment parce que cette détection est à la base de la gestion de congestion. RACK (pour « Recent ACK ») est un nouvel algorithme qui considère comme perdu un paquet s’il n’a pas encore été acquitté alors qu’un acquittement a été reçu pour un paquet émis plus tard. Cet algorithme était en production sur des serveurs Google depuis plus d’un an au moment de la proposition de patchs. Pour plus d’informations, vous pouvez lire la [demande d’inclusion](https://www.mail-archive.com/netdev@vger.kernel.org/msg83215.html) ainsi que le [brouillon à l’IETF](https://tools.ietf.org/html/draft-cheng-tcpm-rack-00). ###Passage à la micro-seconde pour le temps de transmission durant la poignée de main TCP Ce n’est pas un hasard si l’auteur de ce commit est le même que celui qui a implémenté RACK : le noyau analyse maintenant à [la microseconde le temps de transfert des paquets](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f1c28ae74bb1a34d36fca2db5161611d58b3148) lors de la poignée de main TCP (les paquets suivants utilisaient déjà la microseconde). Cette amélioration de la précision est nécessaire sur les réseaux locaux si on souhaite utiliser cette information dans les algorithmes de congestion. ###Du changement dans les routes à chemins multiples en IPv4 Pour comprendre ce changement, il [faut remonter au noyau 3.6](//linuxfr.org/news/sortie-du-noyau-linux-3-6#toc_11) et la suppression du cache des routes en IPv4. Comme effet de bord de cette suppression, le routage des paquets en cas de chemins multiples pour une même route était devenu quasi aléatoire pour chaque paquet. C’est normalement peu important (en IP, chaque paquet devrait être indépendant), mais dérange certaines applications qui attendent les paquets dans l’ordre (et augmente dans tous les cas le coût de traitement pour les applications qui savent réordonner des paquets arrivés dans le désordre). Afin que les paquets appartenant à un même flux de donnée utilisent la même route (et arrivent donc probablement dans le bon ordre), Peter Nørlund a [ajouté le calcul d’un condensat](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=07355737a8badd951e6b72aa8609a2d6eed0a7e7) (hash) prenant en entrée les adresses IP source et destination. Tous les paquets ayant le même hash prendront le même chemin. Dans les détails non triviaux, les paquets d’erreurs en ICMP sont également gérés (il faut regarder des adresses à l’intérieur d’un paquet, cela complexifie beaucoup le traitement). Cette fonctionnalité est indispensable pour que la [découverte de la MTU](https://fr.wikipedia.org/wiki/Path_MTU_discovery) continue de fonctionner correctement. En revanche, les identifiants de niveau supérieur (comme les ports en TCP et UDP), qui permettraient de mieux discriminer les flux, ne sont pas lus. Cette faiblesse d’identification des flux est une limitation d’IPv4 : en IPv6, on pourrait utiliser la lecture des labels de flux exactement pour ce cas d’usage. ###En bref ####L’ICMP avec IPVS En parlant de chemins multiples et de gestion des erreurs ICMP pour découvrir la MTU, [[IPVS]] est un répartiteur de charge pour le noyau Linux. Facebook l’utilise, mais a fait face à un problème : les paquets [[ICMP]] signalant des erreurs ne sont pas transmis à l’instance source de l’erreur, provoquant notamment des problèmes de [découverte de MTU](https://fr.wikipedia.org/wiki/Path_MTU_discovery). La série de [correctifs](http://archive.linuxvirtualserver.org/html/lvs-devel/2015-08/msg00076.html) ajoute une nouvelle option `sysctl`, qui permet de corriger ce problème. Le comportement par défaut ne change pas. #### Les VRF fonctionnent désormais en IPv6 Nous en parlions dans la [dépêche du noyau 4.3](//linuxfr.org/news/sortie-du-noyau-linux-4-3#prise-en-charge-initiale-des-vrf), les _Virtual Routing and Forwarding_ (VRF) ont fait leur entrée dans le noyau Linux, mais ne fonctionnaient pas pour IPv6. [C’est désormais corrigé](https://lwn.net/Articles/660325/), elles sont pleinement fonctionnelles avec les deux versions du protocole IP. ####Identifiant de la table FIB en IPv4 Cette information était déjà disponible en IPv6, elle arrive en IPv4 : l’identifiant de la [FIB](https://en.wikipedia.org/wiki/Forwarding_information_base) est [désormais inclus](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b7503e0cdb5dbec5d201aa69d8888c14679b5ae8) dans les informations de la table de routage. ####Les tunnels Geneve en IPv6 Les tunnels [Geneve](https://tools.ietf.org/html/draft-gross-geneve-00) sont un des très nombreux tunnels que le noyau Linux prend en charge. Ils fonctionnent [désormais également en IPv6](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ed66f0e8235118a31720acdab3bbbe9debd0f6a) (seul l’IPv4 était disponible auparavant). ####Plusieurs chemins en MPLS Annoncé dans la [dépêche du noyau 4.1](//linuxfr.org/news/sortie-du-noyau-linux-4-1#routage-des-paquets-en-utilisant-le-m%C3%A9canisme-multiprotocol-label-switching-mpls), le code pour [[MPLS]] dans le noyau Linux progresse. Il fonctionne maintenant avec [plusieurs chemins pour une même route](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e74f51056a167036f9168fb8d04b9e16ea12af43). ####Des informations sur les ponts (bridges) via l’interface Netlink [Netlink](https://en.wikipedia.org/wiki/Netlink) est l’interface privilégiée pour exporter les informations réseau en espace utilisateur. Malheureusement, des morceaux historiques peuvent ne pas passer par là et ne pas exporter les informations dans `/proc` ou via le `sysfs`. C’était le cas pour les ponts (bridges), mais Nikolay Aleksandrov a fait un grand travail pour que le maximum d’informations soit maintenant accessible : annonce de la [première partie](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68e4bd2778fb48a98cf9db8e218ef2f3a817bafc), et de [la seconde](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68e4bd2778fb48a98cf9db8e218ef2f3a817bafc). ####Des applications persistantes pour BPF On ne présente plus le [Berkeley Packet Filter (BPF)](https://www.kernel.org/doc/Documentation/networking/filter.txt) du noyau. Celui-ci avait une limitation pour certains utilisateurs : lorsqu’un programme s’arrête, les règles qu’il a pu mettre en place disparaissent. Daniel Borkmann, principal développeur de cette partie du noyau, a donc proposé de [permettre la persistance de ces règles](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b2197755b2633e164a439682fb05a9b5ea48f706), ce qui se concrétise par des fichiers spéciaux que les programmes peuvent ouvrir dans `/sys/fs/bpf/`. ##Sécurité Le chiffrement matériel avec le protocole [Trusted Platform Module](https://en.wikipedia.org/wiki/Trusted_Platform_Module) accepte désormais la norme TPM 2.0. C’est la seule fonctionnalité notable parmi des [développements](https://github.com/torvalds/linux/commit/1873499e13648a2dd01a394ed3217c9290921b3d) principalement de maintenance. ##Périphériques en mode bloc (block devices) ### Lecture sans interruption et *polling* Rien à voir avec les coups de fils pour connaître notre gel douche préféré, c’est en fait l’apparition dans la couche E/S par bloc du noyau d’une technique issue de la couche réseau. Jusqu’à présent, la lecture d’un disque se faisait par interruptions successives déclenchées par le pilote, ce qui permet au processeur de s’occuper d’autres tâches entre deux interruptions. Avec les SSD, les débits sont suffisamment élevés pour remettre en cause le mécanisme coûteux des interruptions matérielles et logicielles et envisager un flux plus continu. Ce noyau introduit un mécanisme de lecture où la couche-bloc demande elle-même les données (polling) au pilote. En cas de lecture séquentielle, le gain est parfois très net, jusqu’à un facteur deux, même s’il dépend fortement du périphérique. L’implémentation est encore très partielle et expérimentale, mais son intégration au noyau devrait accélérer les développements. Pour en savoir plus : [LWN](http://lwn.net/Articles/663879/). ### Montage *loop* Indépendamment du système de fichiers, on peut placer un point de montage *loop* sur un fichier, par exemple avec une image de DVD. Ce mécanisme utilise désormais des accès directs, sans passer par des mémoires tampon au niveau du périphérique de bloc *loop*. Les [performances](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bc07c10a3603a5ab3ef01ba42b3d41f9ac63d1b6) en sont grandement améliorées, notamment en termes de consommation de mémoire. ##Systèmes de fichiers ###F2FS https://github.com/torvalds/linux/commit/0fcb9d21b4e18ede3727b8905e74acd0d1daef56 Intégration des changements de f2fs de Jaegeuk Kim : La plupart des changements sont des améliorations de stabilité et de performance de la fonctionnalité de mise en cache des extensions en mémoire. Avec en plus quelques nouvelles fonctionnalités et configurations supplémentaires ainsi que quelques corrections. ###Btrfs https://github.com/torvalds/linux/commit/27eb427bdc0960ad64b72da03e3596c801e7a9e9 Intégration des changements de btrfs de Chris Mason : Beaucoup d’améliorations du côté de la gestion du sub-quota et beaucoup de nettoyage de la part de Dave Sterba et Anand Jain entre autres. Josef a soumis un tas de corrections concernant l’allocateur utilisé en production chez Facebook. Il a trouvé que l’option `mount -o ssd_spread` améliore grandement les performances sur du RAID 5/6 matériel, mais au prix de quelques engorgements CPU. Ces patchs font alors une grande différence. ###Ext4 https://github.com/torvalds/linux/commit/b0f85fa11aefc4f3e03306b4cd47f113bd57dcba Voici le [résumé](https://lkml.org/lkml/2015/11/6/417) par Ted Ts’o en charge de ext4 : * Ajout de la prise en charge de la fonctionnalité CSUM_SEED qui permettra dans le futur aux applications en espace utilisateur de changer l’UUID du volume sans réécriture de toutes les métadonnées de ce volume. * Un certain nombre de corrections diverses, qui concernent surtout le chiffrement de partitions ext4. Quiconque utiliserait ce chiffrement devrait rétro-porter tous les changements opérés en 4.4 pour corriger des fuites mémoires et des corruptions de données. * Il y a aussi du nettoyage des tests de ext4 et de la prise en charge de sysfs. ##Virtualisation Il est désormais possible à une machine virtuelle dans QEMU d’utiliser l’accélération matérielle OpenGL 3D de son hôte. Ce [projet](https://virgil3d.github.io/) assemble plusieurs éléments : [virtio-gpu](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3187567222178d4b3742e88242f7abb3c3b7a215) dans le noyau 4.4, virtio dans [QEMU 2.5](http://wiki.qemu.org/ChangeLog/2.5#virtio), et Mesa (git master). ###KVM https://github.com/torvalds/linux/commit/933425fb0010bd02bd459b41e63082756818ffce #### s390 Des corrections et améliorations de la gestion des interruptions et du temps. #### PPC Principalement des corrections diverses. #### ARM Pas de grosses nouveautés, mais beaucoup de petites corrections et améliorations nécessaires : * des corrections pour le compteur d’architecture (arch-timer) * ajout de nouvelles sémantiques d’activation par niveau pour le compteur d’architecture (arch-timer) * une série de patchs pour arrêter de manière synchronisée un système invité (nécessaire pour la redirection d’interruptions) * amélioration des points de trace * une astuce pour la gestion des exceptions de panique de niveau EL2 * encore du nettoyage de la virtualisation du GIC (Gestionnaire d’Interruptions de ARM) pour la suppression d’états redondants #### x86 Quelques changements: - gestion du "VT-d posted interrupts" (i.e. les périphériques PCI peuvent injecter des interruptions directement dans un CPU virtuel). Cela introduit donc un nouveau composant (dans virt/lib/) qui relie VFIO et KVM. Les mêmes composants seront aussi utilisés pour la redirection d’interruptions sur ARM. - de nouvelles fonctionnalités Hyper-V, même si la principale "Hyper-V synthetic interrupt controller" devra attendre linux 4.5. Ceci permettra a KVM aussi d’exposer des périphériques Hyper-V. - la virtualisation imbriquée prend maintenant en charge les VPID (comme les PCID mais pour les CPUs virtuels) qui accélèrent un peu les choses - pour le futur matériel prenant en charge le NVDIMM, il y a maintenant la prise en charge de clflushopt, clwb et pcommit - prise en charge du "split irqchip", i.e. LAPIC dans le kernel + IOAPIC/PIC/PIT dans l’espace utilisateur, qui réduit la surface d’attaque de l’hyperviseur - intégration nécessaire des corrections pour le SMM (system management mode) - pour le côté client, "stable scheduler clock support" a été réécrit pour que son fonctionnement soit indépendant du superviseur ## Cgroups https://github.com/torvalds/linux/commit/69234acee54407962a20bedf90ef9c96326994b5 Intégration des changements de cgroups de Tejun Heo. Le cœur de cgroups a vu de nombreux changements pour cette version : - Le verrouillage `percpu_rwsem` pour le groupe de processus légers (`threadgroup`) est rétabli. Cette fonctionnalité était temporairement supprimée pour des raisons de latences causées par les appels `down_write`. Le re-travail de Oleg sur `percpu_rwsem` dont l’intégration est prévue pour la prochaine fenêtre d’intégration corrigera le problème. - Sur la nouvelle version de la hiérarchie, quand les gestionnaires sont activés et désactivés, toutes les opérations sont atomiques et peuvent échouer et revenir proprement. Cela permet des erreurs lors des appels ->can_attach() ce qui est nécessaire pour les `cpu RT slices`. - Les tâches restent associées à leur cgroup original après leur sortie jusqu’à leur libération complète. Cela permet un suivi des ressources des tâches fantômes et facilite la découverte de l’origine de ces processus fantômes dans la nouvelle hiérarchie. Le gestionnaire de numéro de processus était cassé avant ces changements, car les processus fantômes échappaient à ces limites ; malheureusement changer ce comportement a requis bien trop de changements profonds et cela reste une mauvaise idée de porter ces corrections en arrière, donc le gestionnaire de numéro de processus sur 4.3, la première version l’incluant, restera cassé au moins jusqu’à ce que l’on soit certain des changements du cœur de cgroups. - Optimisation d’une partie des tests communs en utilisant des `static_key`. #Le bilan en chiffres Selon le [site LWN](http://lwn.net/Articles/668870/), cette version 4.4 a impliqué 1 548 développeurs alors que pour la version 4.3, il y en avait eu 1 600. Parmi ces 1 548 personnes, 246 ont fait leur première contribution au noyau. Pour l’année 2015, la palme du développeur le plus actif a été remportée par H Hartley Sweeten si on s’appuie sur le nombre de commits (282 *changesets*), ou par Alex Deucher si l’on s’appuie sur le nombre de lignes modifiées (3 220 lignes). Si l’on se réfère aux entreprises impliquées dans le noyau, Intel l’emporte haut la main, notamment devant Red Hat, Samsung et AMD, aussi bien en nombre de commits qu’en nombre de lignes modifiées (avec respectivement 12,9 % et 13,3 %). #Appel à volontaires Cette dépêche a nécessité plus de 960 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 28 personnes du 16 novembre 2015 au 18 février 2016 dans l’espace de rédaction. ![Graphe des contributions à la dépêche](http://pix.toile-libre.org/upload/original/1455791957.png) Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition : | | Mainteneur | Contributeur(s) ----------------------------- | -------------------------------------------------- | --------------- **En bref** | Aucun | [rogo](//linuxfr.org/users/rogo)| **La phase de test** | Aucun | Aucun | **Arch** | Aucun | [Tiwaz](//linuxfr.org/users/tiwaz) | **IPC** | Aucun | [ariasuni](//linuxfr.org/users/sinma) | **Développement** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Pilotes graphiques libres** | [Martin Peres](//linuxfr.org/users/mupuf) | Aucun | **Réseau** | Aucun | [Florent Fourcot](//linuxfr.org/users/ffourcot), [Tiwaz](//linuxfr.org/users/tiwaz) | **Block devices** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Systèmes de fichiers** | Aucun | [ariasuni](//linuxfr.org/users/sinma)| **Sécurité** | Aucun | [rogo](//linuxfr.org/users/rogo)| **Virtualisation** | [Xavier Claude](//linuxfr.org/users/claudex) | Aucun | **Édition générale** | Aucun | [jcr83](//linuxfr.org/users/jcr83), [Moul](//linuxfr.org/users/m5oul), [eggman](//linuxfr.org/users/eggman)| 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, Réseau, Développement et IPC 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 ! C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !

AltStyle によって変換されたページ (->オリジナル) /