Sortie du noyau Linux 5.13

Posté par  . Édité par Nils Ratusznik, Benoît Sibaud, palm123, patrick_g, orfenor et Xavier Claude. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
47
21
juil.
2021
Noyau

Les dépêches noyau linuxfr sont de retour. S'il sera compliqué de rattraper le retard sur les noyaux 5 (la dépêche pour le noyau 5.1 date de mai 2019), nous commençons par combler le retard doucement, en introduisant cette présentation d'un noyau de 2021.

C’est ainsi que le 27 juin 2021 est sorti le noyau Linux 5.13, coincé entre l’actualité sur la capitalisation boursière de Facebook qui dépasse les 1000 milliards et un variant Delta qui commence à prendre de l’ampleur sur fond de record au Nasdaq.

Linus nous annonce que malgré le calme de ces dernières semaines, globalement, la version 5.13 est une version plutôt importante. Avec plus de 16 000 commits de plus de 2 000 développeurs impliqués, elle fait partie des grosses versions. Et ce n’est pas, comme parfois, une intégration d’une nouvelle technologie, mais juste une tendance globale pour l'ensemble du noyau.

Architectures

M1

Cette version apporte les premières briques pour l’intégration du processeur maison d’Apple, le M1. C’est une prise en charge préliminaire, et qui permet de poser les bases.

ARM

Prise en charge de nouveaux matériels :

  • le NanoPi R4S sur base de RK3399 ;
  • les processeurs Qualcomm SC7280, utilisés dans certains ordinateurs de type Chromebook ou Windows ARM ;
  • les téléphones OnePlus 5/5T (sur base Qualcomm MSM8998) ;
  • le kit de développement Snapdragon 888 Mobile ;
  • la tablette reMarkable (sur base NXP i.MX 7).

Intel

Un nouveau pilote de gestion de la température (Intel Cooling Driver) pour les processeurs Intel permet de définir un seuil de température différent du seuil par défaut pour réduire la fréquence du processeur.

Pilotes logiciel

Un nettoyage a été effectué au niveau des pilotes logiciels, incluant un certain nombre de périphérique WiMax, le framework Google gasket, les pilotes sysace et umem ainsi que certains vieux pilotes de port série. Notons aussi la suppression du fichier de bloc spécial /dev/kmem.

Dans les ajouts notables (ou visibles), on peut noter qu’après l’inclusion de pilotes pour les manettes Sony DualShock et Nintendo 64 dans le noyau 5.12, nous avons droit dans ce noyau à l’ajout du contrôleur Amazon Luna.

L’Apple Magic Mouse 2 reçoit aussi une amélioration de son pilote, via l’ajout du multitouch, ainsi qu’une supervision du niveau de la batterie.

Sécurité

Inclusion de Landlock, un nouveau module de sécurité, qui vient s’ajouter aux modules existants, pour mieux gérer la portée des processus. Son inclusion survient après 34 révisions et des années de développement.

Temps réel

Le noyau se voit adjoindre un développement venant de la branche RT Preemptive, via l’ajout des interruptions logicielles en espace noyau via un thread dédié, qui peut alors respecter une priorité spécifique, comme n’importe quel autre processus.

Statistiques

Statistiques des noyaux de la série v5.x

Statistiques des noyaux de la série v5.x

Statistiques des noyaux de la série v5.13-rcX

(Nous excluons la rc1 qui correspond à la fenêtre de merge)
Statistiques des noyaux de la série v5.13-rcX

Aller plus loin

  • # Thread de corrections

    Posté par  . Évalué à 3 (+2/-0).

    Merci pour la dépêche, bonne idée.

    • il manque une majuscule à "l'Apple Magic Mouse 2"
    • Temp réel -> il manque un "s"
    • et je pense qu'il manque des "s" aux deux "Statistique" de l'avant-dernière section
  • # Et RISC-V?

    Posté par  . Évalué à 10 (+15/-0). Dernière modification le 21/07/21 à 23:41.

    Dommage de ne pas se porter plus vers l'avenir qui commence à bien s'encrer dans le présent avec l'architecture open source RISC-V. Son support par le noyau Linux continue à se compléter.
    * Support for generic clockevent broadcasts.
    * Support for the buildtar build target.
    * Some build system cleanups to pass more LLVM-friendly arguments.
    * Support for kprobes.

    Au fur et à mesure que les distributions y sont portées. Debian (Bulleseye), Ubuntu, et Fedora tourne à présent sur cette architecture, on commence à avoir des cartes autres que microcontrôleur abordables (enfin, à moins de 800€), c'est limité, plutôt orienté dev, mais ça évolue très vite. Un porteur de Haiku sur RISC-V à [utilisé le pilote radeon_hd pour faire tourner sur du Risc-V, il a visiblement principalement eu une contrainte d'alignement sur 16 bits. Ces pilotes sont aussi présent dans Debian pour RISC-V. C'est vraiment un des grands plus des sources ouvertes la portabilité. Quelqu'un fignole également la partie noyau Linux du pilote Radeon.

    J'ai fait tourner du Debian sur du qemu depuis 2 mois, ça tourne plutôt bien, 95% des paquets sont portés (je pense que ce qui reste c'est ce qui test en dur une version de x86, à vérifier). J'ai quelques microcontrôleurs également pour m'amuser (on en trouve des très complets sur des cartes à partir de 3€ avec FPU, crypto, wifi, audio etc.., j'ai fait quelques essais en assembleur, c'est intéressant la conception, c'est du RISC2. Pour réduire encore le nombre d'instructions par rapport aux autres RISC, il n'y a par exemple plus que les comparateurs < et <=, plus de comparateurs > et >=, ça paraît étrange mais ça permet de réduire pas mal les transistor tout en gardant les mêmes fonctionnalités (il suffit d'inverser les registres dans le test). Les spécifications de l'assembleur comporte des macros pour faciliter l'écriture comme sur des processeurs moins optimisés. Quelqu'un s'est amusé à compiler un noyau 5.0 sur architecture RISC-V et le faire tourner sur un émulateur sur un microcontrôleur embarqué ESP32 (ISA Xtensa alors qu'il y a des ESP32-C qui sont en RISC-V). Il y a plein d'expérimentations folles en RISC-V via différents émulateurs :). Cet émulateur n'a pas l'air libre par contre :(.

    Pour ceux qui s'intéresse un peu au spatial, l'ESA utilisait la famille de processeur LEON basé sur SPARC-8, pour ses satellites, les nouvelles générations baptisées NOEL-V (anagramme), sont basées sur du RISC-V, ce qui permet de réduire encore la conso. L'extension vectorielle (comme à l'époque du Cray) est utilisée pour de l'AI (traitement de photos avant l'envoie sur terre par exemple). Ça utilise le bus AMBA 2.0 d'ARM pour les SoC, dont les specs, je ne le savais pas est sous licence libre également. Les processeurs spatiaux doivent répondre aux contraintes de basse températures, et de rayons ionisants qui fausseraient les calculs sur un processeurs standard. C'est le second projet européen dont j'ai connaissance (avec le processeur européen pour supercalculateur+automobile), qui utilise du RISC-V. L'académie chinoise des sciences à aussi sorti un processeur RISC-V haut de gamme complet sous licence libre (Mulan v2), dont les sources sont en Chisel appelé Xiangshan. Ils ont sorti une implémentation ASIC avec une puissance de calcul/GHz SPEC2006 qui est comparable aux haut de gamme ARM ce mois-ci, ils espèrent atteindre le même rapport calcul/GHz qu'un i9 cet automne et c'est prévu pour faire tourner du Debian de base :).

    • [^] # Re: Et RISC-V?

      Posté par  . Évalué à 6 (+4/-1).

      Bon commentaire !

      Juste une remarque : "L'extension vectorielle (comme à l'époque du Cray)", non, c'est du simple SIMD comme le SSE à 128 bits (intel va jusqu'à 512 mais cela consomme trop et cela fait baisser la fréquence du chip). Le cray avait des vecteurs de 2048 double, c'est une autre taille.

      "La première sécurité est la liberté"

      • [^] # Re: Et RISC-V?

        Posté par  (site Web personnel) . Évalué à 7 (+7/-0).

        Oui et non. On parle bien d'une extension vectorielle, dans le sens ou la taille des registres n'est pas définie par l'ISA, mais par l'implémentation. Le NOEL-V a bien des registres vectoriels de 128 bits, mais un code binaire identique est capable d'exploiter des vecteurs de taille différente sur un autre CPU.

        • [^] # Re: Et RISC-V?

          Posté par  . Évalué à 4 (+3/-2).

          C'est impossible. Il est très difficile d'avoir un binaire qui s’exécute correctement avec des tailles de vecteur variables selon le cpu.

          "La première sécurité est la liberté"

          • [^] # Re: Et RISC-V?

            Posté par  (site Web personnel) . Évalué à 7 (+7/-0).

            Difficile ou impossible, il faudrait savoir. C'est très bien expliqué comment l'extension V de RISC-V implémente ça dans le livre "The RISC-V Reader: An Open Architecture Atlas" de David Patterson et Andrew Waterman.

            Un cherchant un peu sur le net, j'ai également trouvé ce site qui explique pas trop mal le principe: https://gms.tf/riscv-vector.html

            A noter que ARMv8 propose l'extension SVE qui fonctionne sur un principe similaire, mais avec moins de flexibilité.

            • [^] # Re: Et RISC-V?

              Posté par  . Évalué à 4 (+2/-1).

              Je serais curieux de voir ce que cela donne dans la vie réelle. J'aurais tendance à penser que ce genre d'ISA serait lente (latence entre instructions pour décoder l'info de taille à chaque fois, voir une batterie de switch pour gérer la taille dynamique).

              J'aurais préféré une ISA "matricielle", c'est à dire un vecteur qui gère aussi les matrices 2*2 sur un vecteur de 4 éléments. Cela simplifie plusieurs type de calcul. De mémoire, les cpu tensorflow fonctionnent ainsi.

              "La première sécurité est la liberté"

              • [^] # Re: Et RISC-V?

                Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                Je serais curieux de voir ce que cela donne dans la vie réelle.

                Ça dépend de ce que tu vis dans ta vie réelle. Pour le calcul scientifique cette approche vectorielle est susceptible d’améliorer énormément les performances par rapport à tous les traitements spécifiques des fins de boucles nécessaires avec les registres de taille fixe (et toutes les heuristiques pour tenter de deviner quand le temps perdu dans ces traitements risque de contrebalancer le gain potentiel du traitement vectoriel, qui change évidemment chaque fois qu’on vise une machine un tout petit peu différente). De plus, ça veut dire que presque tous les traitements peuvent profiter des opérations vectorielles, pas seulement ceux sur un type de données, le code ainsi vectorisé s‘approche alors beaucoup d’un code réellement parallèle. Pour tout le (assez peu de) code que j’écris, je n’aurais rien à faire de matrices 2×2 (éventuellement je me servirais de 3×3 mais pas assez pour gagner quoi que ce soit si des opérations de base existaient pour elles), par contre la vectorisation change tout.

                • [^] # Re: Et RISC-V?

                  Posté par  (site Web personnel) . Évalué à 7 (+7/-0).

                  Je suis tout à fait d'accord, il ne faut pas tout réduire à du calcul matriciel. Par exemple grâce aux instructions vectorielles "fault-only-first load", il est notamment possible de travailler sur des chaînes de caractères sans contrainte d'alignement et sans connaître leur longueur à priori.

                  Ainsi une implémentation de strlen() vectorisée reste très simple:
                  https://github.com/gsauthof/riscv/blob/master/strlen.s

                  À comparer à une implémentation AVX2 pour x86:
                  https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-avx2.S

                  Sans compter que pour x86, il faut aussi la version AVX-512 pour les CPUs serveurs, et la version SSE2 pour l'entrée de gamme.

                  • [^] # Re: Et RISC-V?

                    Posté par  . Évalué à 2 (+1/-0).

                    Complètement, il y a aussi les traitements de données type RRD, comme ceux arrivant de différents capteurs et qui doivent être traitées en série.

                • [^] # Re: Et RISC-V?

                  Posté par  . Évalué à 2 (+0/-1).

                  De plus, ça veut dire que presque tous les traitements peuvent profiter des opérations vectorielles, pas seulement ceux sur un type de données, le code ainsi vectorisé s‘approche alors beaucoup d’un code réellement parallèle.

                  Là, je ne vois pas pourquoi. En général, pour faire cela il faut du scatter/gather ou des load/store vectorisé, ce qui n'existe jamais.

                  Je comprends que cela simplifie le code à générer. Mais cela peut vite ajouter un étage de pipeline pour le calcul avec toutes les latences qui vont avec.

                  "La première sécurité est la liberté"

                  • [^] # Re: Et RISC-V?

                    Posté par  . Évalué à 6 (+5/-0).

                    Je crois qu'il y a un problème de compréhension du fonctionnement d'une unité vectorielle comme celle-ci. Le but est bien de traiter des ensemble de donnée en série.

                    Voici une présentation de 2015 à ce sujet qui explique les avantages du processeur vectoriel traditionnel par rapport au packed-SIMD et quelques améliorations apportées dans le cas de l'extension vectorielle de RISC-V :
                    https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf

                    • [^] # Re: Et RISC-V?

                      Posté par  . Évalué à 3 (+0/-0).

                      Le doc est intéressant, je ne connaissais pas le "vectorielle classique". Mais il n'y a pas plus de scatter/gather de données en RAM, qui permettrait de vectoriser plus ou moins n'importe quel code (vecteur de pointeur pour faire un load/store vectoriel).

                      "La première sécurité est la liberté"

              • [^] # Re: Et RISC-V?

                Posté par  (site Web personnel) . Évalué à 4 (+4/-0).

                Dans la vie réelle, il y a l'exemple de Cray qui avait un principe de fonctionnement similaire au niveau des vecteur de longueur variable et qui fonctionnait très bien.

                Côté ARMv8 SVE, qui est tout de même un peu différent je l'admet, il y a quand même le supercalculateur Fugaku qui arrive premier au Top 500 sans utiliser de GPU.

              • [^] # Re: Et RISC-V?

                Posté par  . Évalué à 3 (+2/-0).

                J'aurais tendance à penser que ce genre d'ISA serait lente (latence entre instructions pour décoder l'info de taille à chaque fois, voir une batterie de switch pour gérer la taille dynamique).

                Ça me fait penser à des problèmes un peu similaire (bon, seulement un peu) avec AVX512, pas tant pour gérer un taille dynamique, mais pour gérer la consommation électrique des CPU

                "Regular" lets you use any 128-bit wide instructions and "light" 256-bit instructions (shuffles and integer adds/logic/shifts OK, no FP, nothing that powers on the 256-bit multiplier whether int or FP)

                "AVX2 heavy" lets you use all 256-bit wide instructions and "light" 512-bit wide ones. Base and turbo frequencies are about 15% lower than baseline.

                "AVX512 heavy" lets you use anything. Forces the frequencies to be about 25-30% lower than regular.

                Using any instructions outside the current power bin makes the core request a higher power license, which takes a long time. Quoting the Intel optimization guide:

                When the core requests a higher license level than its current one, it takes the PCU up to 500 micro- seconds to grant the new license. Until then the core operates at a lower peak capability. During this time period the PCU evaluates how many cores are executing at the new license level and adjusts their frequency as necessary, potentially lowering the frequency. Cores that execute at other license levels are not affected. A timer of approximately 2ms is applied before going back to a higher frequency level. Any condition that would have requested a new license resets the timer.
                

                En gros, il y a 3 modes de puissance (Regular, AVX2 heavy et AVX512 heavy) avec chacun une réduction de la fréquence d'horloge du CPU, et le fait d'utiliser des instructions AVX2 ou AVX512 bascule le CPU vers le mode de puissance adapté pour plusieurs millisecondes.

                • [^] # Re: Et RISC-V?

                  Posté par  . Évalué à 4 (+1/-0).

                  Ils doivent avoir des multiplieurs sous des power domaines différents, donc, pour tous les utiliser il faut leur laisser le temps de s'allumer, mais à moins d'avoir un gros TDP et une grosse ventilation, cela peut impliquer de baisser la fréquence (ce qui est absurde quelques part, car vous vous êtes fait chier à ajouter plein de bascules pour faire un long pipline pour aller plus vite, tout ça pour baisser la fréquence ! (d'ou l'archi big.little de arm, d'ailleurs)).

                  "La première sécurité est la liberté"

    • [^] # Re: Et RISC-V?

      Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

      Top le complément à la dépêche, cimer !

  • # stats

    Posté par  . Évalué à 3 (+1/-0). Dernière modification le 22/07/21 à 09:29.

    D'abord merci pour la dépêche, j'ai rarement commenté les dépêche noyau et malheureusement jamais participé à leur rédaction (je ne m'estime pas assez compétent pour cela), mais depuis qu'elles existent, je les ai toujours assidument lues.

    En voyant les stats d'ajouts/retraits de lignes pour les RC, je suis surpris de voir qu'ils sont relativement constants tout au long des RC, je voyait ça beaucoup plus dégressif.
    Quelqu'un sait si c'est un cas particulier de cette version ou si c'est toujours le cas ?

    PS: comme quoi faut toujours mieux aller chercher des stats plutôt que je fier à son ressenti…

    • [^] # Re: stats

      Posté par  . Évalué à 4 (+1/-0). Dernière modification le 22/07/21 à 10:29.

      J'imagine que c'est le nombre de ces changements qui décide de sortir une nouvelle RC à la place de la finale.

      "La première sécurité est la liberté"

  • # Landlock

    Posté par  (site Web personnel) . Évalué à 4 (+1/-0).

    Quelqu'un pour dire un mot dessus ? Je suis curieux !

Envoyer un commentaire

Suivre le flux des commentaires

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