RFC Fast Kernel Headers très prometteur pour le noyau Linux

Posté par  (site web personnel) . Édité par patrick_g et Julien Jorge. Modéré par Julien Jorge. Licence CC By‑SA.
Étiquettes :
133
13
jan.
2022
Noyau

Ingo Molnár, vieux contributeur du noyau Linux et employé de Red Hat depuis 2013, vient de soumettre sur la mailing-list linux-kernel une gigantesque série de 2300 patchs nommée « Fast Kernel Headers ».

Plus de détails dans la suite de la dépêche.

Comme le savent les utilisateurs de Linux qui recompilent leur noyau eux-même, celui-ci contient plus de 10000 fichiers d'include .h. Au cours des 30 années de développement, ce nombre n'a fait qu'augmenter en ajoutant des dépendances croisées complexes et difficiles à maitriser, ce que les contributeurs nomment « Dependency Hell » (« un enfer de dépendances »).

L'objectif de ces travaux est de réduire cette complexité et par voie de conséquence d'améliorer significativement les temps de compilation du noyau.

À partir de ses travaux qui ont débuté fin 2020, il obtient une amélioration de 50 à 80% des temps de compilation du noyau pour les architectures supportées, suivant la configuration utilisée.

Pour l'instant, les architectures supportées sont : ARM64, MIPS, Sparc et x86. Les autres architectures ne compilent pas à cause d'une modification essentielle qui doit être portée. Un des objectifs est de résoudre ce problème afin que son arborescence de travail puisse être mergée dans la branche principale du noyau

Ingo Molnár décrit dans ses posts les différentes étapes pour arriver aux objectifs fixés, ce qui lui a pris plus d'un an au final. Il fût même surpris des gains de performance obtenus puisqu'il s'était d'abord fixé un gain de performance atteignable de l'ordre de 20%.

Son 1er post est très complet sur les stratégies utilisées pour obtenir ses résultats. Le point principal a été de réduire le post-preprocessing des fichiers include essentiels : taille des fichiers réduite d'1 à 2 ordres de grandeur, calculée à partir du nombre de lignes de code (LOC).

Son post contient plus de précisions techniques pour obtenir ces résultats, qui représente au final 2200 commits répartis dans 25 sous-arborescences : 25,288 files changed, 178,024 insertions(+), 74,720 deletions(-).

L'auteur estime que ces modifications sont tellement importantes que son post est un RFC (Request for Comment). Il n'hésite pas à qualifier son post de « the largest single feature announcement in LKML's history ».

Il a depuis soumis une 2ème version de ses travaux présentant des améliorations de performance de compilation encore plus importantes et le support de Clang/LLVM.

Comme on pouvait s'y attendre, ces soumissions ont suscité un grand intérêt de la part des autres contributeurs du noyau et son lot de compliments (Speed up is very impressive, nice job !). Devant l'ampleur des modifications, il y a déjà beaucoup de discussions techniques sur les apports mais pas de refus ou blocage à priori, d'après ce que j'ai pu lire. On peut espérer que ce travail soit rapidement intégré dans des versions de tests du noyau, avant d'être intégré par Linus Torvalds dans la version mainline.

NdA : vieux contributeur de LinuxFr (1er post en juin 1999 d'après les archives), ça fait plus de 13 ans que je n'avais pas écrit ici :)

Aller plus loin

  • # Risques de régressions ?

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 13 janvier 2022 à 21:24.

    Je ne suis pas un expert du noyau, mais ce genre de modification en masse fait un peu peur: les risques d'introduction de bugs ou de régressions me semblent importants.

    Je me trompe ?

    • [^] # Re: Risques de régressions ?

      Posté par  . Évalué à 10.

      En l'occurence il ne s'agit que de peu de changements de code mais surtout des changements sur les fichiers en-têtes. Certes cela peut avoir un impact sur le code, mais si ça continue de compiler c'est déjà un très bon signe. L'idée est surtout que quand tu inclus toto.h, ça ne va pas include marcel.h parce que un élément dans toto a besoin de marcel.
      Il y a seulement un changement dans ce lot qui impacte du «vrai» code il me semble, et vu que ça impacte une structure majeure du noyau, nul doute que ce sera relu/testé moultes fois.

      • [^] # Re: Risques de régressions ?

        Posté par  (Mastodon) . Évalué à 5.

        +1
        Comme c'est dans la partie essentiellement déclarative du code, non seulement il y a peu de chances que ça change le comportement, mais en plus ça se verra tout de suite puisque ça lèvera une erreur à la compilation.

      • [^] # Re: Risques de régressions ?

        Posté par  (site web personnel, Mastodon) . Évalué à 9.

        Héhé, cela me rappelle une discussion récente sur le fait de réduire le nombre d'inclusions et en contrôler l'ordre…
        lien ici : « Mise à jour du guide de l'ANSSI pour le développement sécurisé de logiciels en langage C » ; fil : « Ordre des en-têtes »

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Risques de régressions ?

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        Pour être plus précis, en touchant dans un fichier entête tu peux très bien introduire un bug (par exemple en changeant le type ou la taille d'un champ) sans forcément faire planter la compilation.

        Cependant son travail ne consiste pas vraiment a changer les headers en sois mais a éviter que A include B et C qui include D. Mais a mettre directement A include B, C, D et du coup a dire que A peut include juste B et D, il n'a plus besoin de C. Autrement dis souvent par simplicité on include tout et on laisse le compilo ne prendre que ce dont il a besoin. Donc dans ce cas c'est plus de la simplification du travail du compilo que du changement de code.

        Après cela ne veut pas dire qu'il ne fasse pas d'autres changement en plus et qu'il ne puisse pas induire des bugs. Mais au final le code ajouté/supprimé n'est pas très élevé a priori. C'est surtout le nombre de fichiers concernés et le fait que ce soit central qui rends le patch particuliers. Ca devra être bien tester, cela ne fait aucun doute.

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Risques de régressions ?

      Posté par  (site web personnel) . Évalué à 5.

      Vu l'ampleur des modifications proposées, on peut imaginer qu'il va y avoir de nombreuses étapes d'intégration et de tests : merge sur des branches de travail, review croisée du code, recompilation du noyau dans plein de configurations/architectures différentes et tests.

      Le patch concernant quasi exclusivement les fichiers d'include, le risque principal de régression est de s'assurer que le noyau compile correctement avec une grande variété de configuration des options choisies.

  • # Un sacré jeu de piste

    Posté par  (site web personnel) . Évalué à 10.

    J'ai eu l'occasion d'aller voir les Kernel Headers pour rechercher comment étaient paramétrées quelques valeurs. On voit des fichiers qui ont besoin d'autres fichiers et quand on arrive au bout, on a presque oublié ce qu'on vient y chercher.
    Certes, c'est nécessaire si on veut un code qui compile en 32 ou 64 bits, sur Intel ou ARM pour ne citer que ces cas.

    Je dis bravo et merci à Ingo Molnár, car il y peu de gens capables de faire ce travail ingrat.

    • [^] # Re: Un sacré jeu de piste

      Posté par  (site web personnel) . Évalué à 10.

      Alors qu'on pourrait mettre tout le code dans un unique fichier source !
      -->[]

      • [^] # Re: Un sacré jeu de piste

        Posté par  . Évalué à 4.

        Et oui, le mono-fichier est l'évolution naturelle du mono-repo --> []

        • [^] # Re: Un sacré jeu de piste

          Posté par  (site web personnel) . Évalué à 3.

          Et on pourra même y conserver tout l’historique, dans le mono-fichier, avec les conversations discutant de tel ou tel aspect ! ➡️🚪

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Un sacré jeu de piste

            Posté par  . Évalué à 6. Dernière modification le 20 février 2022 à 20:22.

            Il suffirait de dupliquer et commenter le code modifié ou supprimé, avec une date de modif dans le commentaire.
            Et on pourrait mettre des norloges dans les discussions pour que tout reste clair!

            Attendez-moi, j'arrive!
            -----> [ ]

            • [^] # Re: Un sacré jeu de piste

              Posté par  . Évalué à 2.

              Mais au fait, qu'y a-t-il derrière cette [] ?
              Devant elle, je vois très bien le bordel souhaitant la prendre, mais derrière ?

              Avez-vous des idées ou faut-il organiser un sondage ?

      • [^] # Re: Un sacré jeu de piste

        Posté par  . Évalué à 2. Dernière modification le 24 février 2022 à 15:41.

        Alors qu'on pourrait mettre tout le code dans un unique fichier source !
        -->[]

        … et on pourrait même le versionner avec la fantastique méthode cpold, qui comme indiqué

        "ne souffre d'aucun des problèmes récurrents des autres outils :
        - pas de format de fichier complexe et susceptible de corruption
        - pas de conflits
        - aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues)
        - aucune limitation sur la gestion des branches
        - une rapidité insurpassable
        - une simplicité de mise en œuvre et d'apprentissage enfantine
        - pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles)
        - des sauvegardes facilitées
        - etc.        "

        • [^] # Re: Un sacré jeu de piste

          Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 24 février 2022 à 16:40.

          C'est exactement ce que font certaines boîtes avec les partages Windows…

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Molnár

    Posté par  . Évalué à 7.

    Meunier, tu dors pas assez,
    Ton ventilo ventilo va trop viiiiiiteuuuu…

  • # Et pour moi ?

    Posté par  (Mastodon) . Évalué à 4. Dernière modification le 14 janvier 2022 à 22:19.

    Ai-je bien compris ?

    Ingo Molnár a réalisé un gros et super travail qui va permettre à termes de compiler beaucoup plus rapidement le noyau Linux. Super pour plein de gens ! Mais pour moi qui n'ai jamais compilé moi-même de noyau et qui ne le ferai peut-être jamais, cela ne change rien de manière directe. Linux en lui même ne va pas fonctionner plus rapidement.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Et pour moi ?

      Posté par  (Mastodon) . Évalué à 10.

      Oui, mais des développeurs qui passent moins de temps à compiler, c'est des développeurs qui boivent moins de café, et qui sont donc moins énervés, et enfin moins susceptible de laisser des bugs.

      Et il y a besoin de machines moins puissantes, donc potentiellement plus de développeurs…

      On peut en imaginer plein comme ça !

      • [^] # Re: Et pour moi ?

        Posté par  (site web personnel) . Évalué à 10.

        Titre de l'image

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Et pour moi ?

        Posté par  (site web personnel) . Évalué à 6.

        des développeurs qui passent moins de temps à compiler, c'est des développeurs qui boivent moins de café

        cool, les contributeurs au noyau vont pouvoir boire plus de bière le soir :-)

      • [^] # Re: Et pour moi ?

        Posté par  (site web personnel) . Évalué à 7.

        Des lancements de test plus rapide, donc des retours plus rapides.

        Et rien que d'occuper la CI 50% de moins fait que ça va coûter 50% de moins (grosso modo).

      • [^] # Re: Et pour moi ?

        Posté par  (Mastodon) . Évalué à 2.

        des développeurs qui passent moins de temps à compiler, c'est des développeurs qui boivent moins de café,

        2022, enfin l'année de Linux sur le desk… ah, non pas encore… année de l'effondrement de toute l'industrie du café.

    • [^] # Re: Et pour moi ?

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Oui mais 99% des patch ne concernent pas l'utilisateur lambda. Même quand il y a des optimisations importante cela ne concerne que des cas précis pas forcément ton utilisation ou alors qu'une partie de ton utilisation. Et plus encore, quand bien même Linux tournerait de manière instantané, le verrais tu vraiment? Ce qui prends du temps c'est tout le reste, les autres logiciels (et leur lancement à commencer par le gestionnaire de fenêtres). En fait si tu veux un PC qui tourne plus vite, utilise des applications plus simplifié (genre vim) et autrement, le plus simple est de prendre un PC plus puissant ;)

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Et pour moi ?

      Posté par  (site web personnel) . Évalué à 10.

      Ce genre de refactoring permet d'augmenter la vitesse de développement, non seulement parce que « ça compile plus vite » mais surtout parce qu'il devient moins difficile de raisonner sur comment ça marche. Ça veut dire qu'il devient plus facile de débugger ou de ne pas introduire certains bugs. Des fonctionnalités peuvent être ajoutées plus rapidement sans perte de qualité. C'est pas forcément facile à quantifier de bout en bout mais tout cela bénéficie aux utilisateurs indirectement.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Et pour moi ?

      Posté par  . Évalué à 2.

      Ca t'arriveras peut-être si tu viens à utiliser une distribution source comme Gentoo ou Slackware ou même à utiliser un kernel custom sur Arch.

      Sur des vieilles bécanes, selon les modules et les options de compilation, ça peut devenir très rapidement très long à compiler (plusieurs dizaines de minutes voir beaucoup +).

      Sur une machine récente (AMD 5900x, 32Go RAM 4000Mhz, NVMe), je compile le kernel zen en grosse quinzaine de secondes (pifométrie au doigt humidifié). Peu importe le gain, vu la rapidité actuelle, c'est pas ça qui me fera gagner beaucoup de temps dans ma journée.

      Dans tous les cas, même si c'est une amélioration surtout profitable aux développeurs, on en profitera tous indirectement. Comme l'ont dit les autres moules, moins de temps de compil = plus de développement.

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # quid de la sécurité ?

    Posté par  . Évalué à 3.

    Bonjour,
    Un tel commit est un endroit rêver pour glisser une backdoor: le codereview semble complexe à gérer, ça "ne change rien" pour l'utilisateur final et tous les dev sont heureux de compiler beaucoup plus vite et donc favorable à l'idée. Loin de moins l'idée de dire que c'est le cas, qu'il y a intention de ou autre.

    Ensuite, si on ne touche qu'au header, le checksum du binaire de sortie ne devrait pas changer si ?
    peut importe dans quel ordre tu inclus tes .h dans tes .c
    peut importe si t'ajoute des define, en retire, ajoute des prototypes (…)

    Au final le compilateur se sert des .h pour aller chercher des informations qui lui sont utile à la compilation, si on a pas changé ces informations (le contenu d'un define par exemple), pas de raison que le binaire change …

    Autant je fais un tests avec un main.c a.h et b.h, quelques modifs et sha1sum et je suis sur de moi, autant sur la taille d'un noyau, je le suis moins '

    • [^] # Re: quid de la sécurité ?

      Posté par  . Évalué à 3.

      Les headers contiennent aussi des variables et fonctions static.
      Il est probable que certains changements modifient l'ordre dans lequel les fichiers headers sont chargés. Dans ce cas, l'ordre d'apparition des objets static sera aussi modifié dans le binaire.

      • [^] # Re: quid de la sécurité ?

        Posté par  (site web personnel) . Évalué à 4.

        Dans ce cas, l'ordre d'apparition des objets static sera aussi modifié dans le binaire.

        oui, j'imagine que nos amis de https://wiki.debian.org/ReproducibleBuilds sont dans la boucle (ya la même démarche côté RHEL et d'autres distributions).

        • [^] # Re: quid de la sécurité ?

          Posté par  (site web personnel) . Évalué à 10.

          Il n'y a pas vraiment de rapport entre ce changement et les compilations reproductibles.

          L'objectif de la compilation reproductible c'est qu'à partir d'un code source donné et quelques paramètres, on peut générer le même binaire à l'octet près quelque soit la personne qui compile.

          L'intérêt est de vérifier par exemple si un paquet Debian a bien été compilé conformément au code source prétendument employé pour le générer, sans changements cachés. Ce qui est utile en cas de mainteneur malveillant ou s'il a été victime d'une attaque de sa machine par exemple.

          Le but de la compilation reproductible n'est pas de vérifier si deux codes sources différents produisent le même binaire même si les changements sont très minimes fonctionnellement parlant. Pour ce genre de cas la compilation reproductible n'aidera pas : il faut analyser le correctif pour s'assurer qu'il n'y a pas d'effets de bords. Et tester, tester, tester.

        • [^] # Re: quid de la sécurité ?

          Posté par  . Évalué à 8.

          Je ne suis pas sur. Pour moi l'ordre dans le binaire va se faire sur des optimisations d’alignement et autre joyeuseté.

          main.c

              #include <stdlib.h>
    #include "a.h"
    #include "b.h"

    int main(void)
    {

      return EXIT_SUCCESS;
    }

          a.h

          #ifndef _A_H__
#define A_H__

#define STR "12345"
int a = 42;

#endif

          b.h

          #ifndef _B_H__
#define B_H__

#define STR2 "12345"
int b = 42;

#endif
          gcc main.c -o out1
sha1sum out1
fcd713188a4f1c14a596dd85179088d361ee2f40  out1

          Si je modifie l'ordre de mes vars

          a.h

          #ifndef _A_H__
#define A_H__

#define STR "12345"

#endif

          b.h

          #ifndef _B_H__
#define B_H__

#define STR2 "12345"
int b = 42;
int a = 42;

#endif
          gcc main.c -o out2
sha1sum out2
fcd713188a4f1c14a596dd85179088d361ee2f40  out2

          Après, avec plusieurs struct, enum, globale, static et autre je dis pas que ça peut pas se produire, c'est justement le questionnement.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 5. Dernière modification le 17 janvier 2022 à 10:55.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: quid de la sécurité ?

              Posté par  . Évalué à 3. Dernière modification le 18 janvier 2022 à 19:21.

              A priori, ça ne change pas le binaire, même en changeant les valeurs de a et b et en return a + b dans le main :)

              19:19 domble@ifrit ~/test % gcc main.c -o out1
19:19 domble@ifrit ~/test % emacs a.h
19:19 domble@ifrit ~/test % emacs b.h
19:19 domble@ifrit ~/test % gcc main.c -o out2
19:19 domble@ifrit ~/test % sha1sum out1 out2
ac1c858ee57af78cc5b1eebb8b7fc19e3aa926af  out1
ac1c858ee57af78cc5b1eebb8b7fc19e3aa926af  out2
19:19 domble@ifrit ~/test %

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 2. Dernière modification le 19 janvier 2022 à 09:46.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 3.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 3.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: quid de la sécurité ?

                      Posté par  . Évalué à 4.

                      Dans le premier cas b=24 et dans le deuxième b=25.

                      Du coup, ben c'est différent !

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 4. Dernière modification le 19 janvier 2022 à 19:20.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: quid de la sécurité ?

                          Posté par  . Évalué à 4.

                          On peut voir la différence avec godbolt, l'ordre change aussi dans l'assembleur.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: quid de la sécurité ?

                            Posté par  (site web personnel) . Évalué à 7.

                            Une compilation reproductible cherche plutôt à s'assurer qu'à partir des même sources, on obtient toujours le même binaire. Par contre, si les sources changent, c'est normal que le binaire change.

              • [^] # Re: quid de la sécurité ?

                Posté par  (site web personnel) . Évalué à 2.

                Bien mais j'aurai aussi activé la compilation optimisé -O2 utilisée par le noyau.
                Il se passe plus de choses dans cette situation.

                Que l'ordre changeant influence la compilation. Mais dans le processus de validation vérifier la compatibilité du binaire pourrait être la première étape.

                Bravo à l'auteur quand même c'est un travail de patience, mais il y a du être bien motivé quand il a constaté les améliorations de résultat.

      • [^] # Re: quid de la sécurité ?

        Posté par  . Évalué à 3.

        Je ne comprends et suis très curieux : pourquoi mettre des variables et/ou fonctions "static" dans un .h ? Je trouve cela antinomique.

    • [^] # Re: quid de la sécurité ?

      Posté par  (site web personnel) . Évalué à 4.

      J'ai jamais vraiment regardé aux tests autour du noyau mais a priori il ne me semble pas idiot de systématiser/automatiser ce genre de vérification pour tous les changements qui sont censés êtres du refactoring sans modification de fonctionnalités. Il y a inexorablement des complications mais je ne serais pas trop étonné d'apprendre que ça se fait déjà.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Commentaire supprimé

    Posté par  . Évalué à -1. Dernière modification le 21 janvier 2022 à 16:56.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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