Le tour du noyau Linux en ... moins de 8 secondes

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
23
mar.
2002
Noyau
"à l'aide, je suis troublé !" Tel est le message posté par Anton Blanchard sur LinuxKernelMailingList.

En effet, compiler un noyau x86 en moins de 8 secondes, sur des machines ppc64 (et en gcc s'il vous plait !), c'est pas banal.

Le message de la fin :

" make[1]: Leaving directory `/home/anton/intel_kernel/linux/arch/i386/boot'
128.89user 40.23system 0:07.52elapsed 2246%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (437084major+572835minor)pagefaults 0swaps"

Aller plus loin

  • # Pas assez long mon fils

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

    Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

    Réflexion 2 : pfff c'était déjà pas assez cher, trop facile à recompiler, maintenant c'est trop court. Comment vous voulez intéresser les décideurs pressés avec.

    • [^] # Re: Pas assez long mon fils

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

      Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

      Mais il faudra toujours l'exécuter le noyau hein ;)

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

    • [^] # Re: Pas assez long mon fils

      Posté par  . Évalué à 10.

      > Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

      Si j'ai bien tout lu freud ... les procs utilisés sont des IBM power. Donc à tout les coups il s'agit d'une mainframe. Donc tu ne rebootes pas la machine, mais une partition logique de la machine, et vu la bete, ca se pourrait meme que les partitions logiques bootent en moins que 8 sec.

      Quant à la main frame, tu ne la reboot pas. Elle est sensée tourner pdt 20 ans sans panne.

      De plus, il a "ajouté" 8 processeurs à la partition logique et donc on ne sait pas trop combien il en a actuellement en tout.

    • [^] # Re: Pas assez long mon fils

      Posté par  . Évalué à 2.

      Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

      Non non le vrai défi c'est changer de noyau à la volée, sans rebooter !

      • [^] # Re: Pas assez long mon fils

        Posté par  . Évalué à -6.

        exact.
        Le vrai chalange, c'est de permuer le noyau tellement vite, en moins d'un tour d'horloge, pour ne pas arreter la machine.
        ceci dit, en 8s, meme plus le temps d'aller vérifdier si la machine à café marche.

      • [^] # Re: Pas assez long mon fils

        Posté par  . Évalué à -1.

        Avec un µnoyau + des serveurs comme ceux du Hurd, y a plus besoin de rebooter (sauf éventuellement pour changer le µnoyau, mais c'est tellement rare et il fait tellement peu de trucs...)
        C'est d'ailleurs une fonctionnalité prévue pour un (le ?) futur Solaris...

      • [^] # Re: Pas assez long mon fils

        Posté par  . Évalué à 10.

        Il y a un patch qui permet de faire ça, charger un nouveau noyau et redémarrer avec ce noyau http://sourceforge.net/projects/monte(...)
        Bien sur il faut que le noyau actuel intègre ce patch pour pouvoir charger le nouveau noyau sans redémarrer.

        PS: j'ai trouvé ce lien parmis l'énorme liste de patch du site http://kernelnewbies.org(...)

    • [^] # Re: Pas assez long mon fils

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

      Une autre remarque aussi. Que sait-on du noyau qui a été compilé ? Est-ce que c'est un noyau "normal" (qu'on trouve dans les distributions) ou un noyau "minimum" conçu uniquement pour être rapide à compiler ? Quid des modules ?

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

    • [^] # Re: Pas assez long mon fils

      Posté par  . Évalué à 1.

      Réflexion 1 : il faut plus de temps pour redémarrer la machine que pour compiler le noyau... Reste donc à permettre la compilation du noyau pendant le démarrage.

      La va y avoir un problème entre l'oeuf et la poule : a priori faut un noyau pour compiler.

  • # Traduction...

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

    La traduction de "I think Im addicted. I need help! " serait plutôt quelque chose du genre "A l'aide, je pense que je suis atteint !", ce qui n'a pas vraiment le même sens. Non ? Ou mon anglais a-t-il besoin d'une révision ? :-)

    • [^] # Re: Traduction...

      Posté par  . Évalué à 7.

      Je pense que je suis accro (orthographe non certifiée) J'ai besoin d'aide.

      • [^] # Re: Traduction...

        Posté par  . Évalué à -2.

        Je pense que je suis accro

        Oui c'est tout à fait ça.

        D'après mon Robert & Collins :
        - addict : (Med) intoxiqué; (fig) fanatique
        - addicted : adonné; addicted to drugs : adonné à la boisson; fana, mordu

  • # Mouais

    Posté par  . Évalué à -4.

    Bon, donc on a un concours de celui qui a la plus grosse. Si cela les amuse...

    Bref, ce que je remarque quand même, c'est que l'on n'a aucune idée de ce qui a été compilé. Ah si, kernel compiled: 2.4.18 x86 with Martin's config. Moi ça me fait une belle jambe. Si quelqu'un trouve cette config, je serais heureux de voir ce qui est effectivement compilé.

    • [^] # Re: Mouais

      Posté par  . Évalué à -4.

      laurent@vodka:/usr/src/linux$ grep "y\|m\$" .config
      # ISDN subsystem
      laurent@vodka:/usr/src/linux$

      Hmmm.....

    • [^] # Re: Mouais

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

      Ca change pas grand chose la config utilisée, parce que même 16 secondes, ca aurait été un temps canon. Sur mon (maigre) bi-p3, j'arrive pas à descendre sous les 4 minutes, quelque soit la config.

      • [^] # Re: Mouais

        Posté par  . Évalué à 0.

        Puisque le concours est ouvert, autant connaitre exactement les règles du jeu. Même si je sais que ma machine n'en est pas capable, et que j'ai mieux à faire que jouer à ça.
        C'est plus par curiosité, quoi.

      • [^] # Re: Mouais

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

        Sur un Athlon XP2000, je ne tombe jamais en dessous de 3m20s (make -j 2 aprés un make clean avec ma config habituelle) donc 8 ou 16 secondes, ça laisse un peu réveur quand même !

        J'aimerais aussi bien connaitre les conditions de leur test.

        • [^] # Re: Mouais

          Posté par  . Évalué à -1.

          ce que je trouve bizarre c'est de cross-compiler du x86 à partir d'un power... ca doit pas tourner sous linux le bestiaux... :-|

        • [^] # Re: Mouais

          Posté par  . Évalué à -5.

          pfff, les gars vous etes nuls...

          Plus de deux heures sur mon 486dx100 ca c'est de la vraie perf! :))

          • [^] # Re: Mouais

            Posté par  . Évalué à -7.

            comment je fais ??

            Je lance, je compile 15 noyaux differents sur mon P III, et je reviens... pas bête, non ??

      • [^] # Re: Mouais

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

        moi je propose pour ceux qui ont un peu de mémoire vive de creer un ramdisk de 150 Mo, de le monter, detarer le kernel dedans et d'essayer de compiler en -j 3 ou 4, ca pourrait peut etre donner des bonnes perf....

        Moi ce que j'en dit, c'est juste une suggestion...

        • [^] # Re: Mouais

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

          Vu la façon (excellente) dont Linux gère ses caches, ça ne sert à rien du tout.

          Le simple fait de détarer les sources sur ton disque place les fichiers dans le cache. Ce qui fait que lors de la compilation, il n'y aura pas d'accès physique du disque aux sources (à condition évidement qu'il y ait assez de Ram pour aussi cacher le compilateur et tout ce qui sert à compiler le noyau).

          • [^] # Re: Mouais

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

            A condition de rien faire pendant la compilation du kernel, ce qui n'est pas mon cas... Comme tu le dis, le fait de détarer les sources place bien le kernel en RAM (c'est à dire dans le cache disque), mais il peut aussi facilement en sortir si tu accèdes au disque dur avec d'autres applications. Donc la méthode du disque en RAM doit être plus rapide, car on est sûr que les sources sont bien en RAM.

          • [^] # Re: Mouais

            Posté par  . Évalué à -7.

            les .o et les fichiers en /tmp, faut bien les écrire quelque part, non ?

            • [^] # Re: Mouais

              Posté par  . Évalué à 3.

              les .o et les fichiers en /tmp, faut bien les écrire quelque part, non ?

              Si je me souviens bien, il y a moyen de ne pas passer par /tmp pour la compilation, en disant à gcc d'utiliser des pipes, je crois même que c'est fait par défaut pour la compil du noyau. Par contre les .o seront toujours écrits sur disque.

  • # C'était vraiment la peine ...

    Posté par  . Évalué à 4.

    ... de mettre cette news kekette 2002 en première page ?

    • [^] # Re: C'était vraiment la peine ...

      Posté par  . Évalué à -1.

      je trouve qu'elle a sa place sur la première page, mais je l'aurai bien mise en section "Humour" par contre ! :p

    • [^] # Re: C'était vraiment la peine ...

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

      Pas de technique en première page, les gens râlent.
      Technique en première page, les gens râlent :)

      Savoir que l'on peut compiler un noyau Linux sur du multi-pro, avec gcc cross-compiler, que tout ça marche et compile en 8s, cela me semble intéressant.

      • [^] # Re: C'était vraiment la peine ...

        Posté par  . Évalué à 0.

        Sauf que c'est pas présenté comme ça...

      • [^] # Re: C'était vraiment la peine ...

        Posté par  . Évalué à 3.

        >Pas de technique en première page, les gens râlent.
        >Technique en première page, les gens râlent :)

        Normal ici c'est linuxFR et comme tout le monde le sait, les Français sont des gros râleurs (et moi le premier!)

        Donc râlons, râlons, il en restera touours quelques chose

      • [^] # Re: C'était vraiment la peine ...

        Posté par  . Évalué à 3.

        >Savoir que l'on peut compiler un noyau Linux sur du multi-pro, avec gcc cross-compiler, que tout ça marche et compile en 8s, cela me semble intéressant.

        Oui, c'est intéressant, mais à condition qu'on nous l'explique, si c'est pour simplement dire "moi je le fais en 8 secondes sur ma bête de course", ca importe peu.

        Pour ma part, je ne trouve pas cela vraiment didactique et constructif.
        On a vraiment l'impression que ceux qui ont des gros serveurs passent leur temps à s'amuser avec.
        Je crois qu'il serait intéressant d'expliquer les avantages d'une telle rapidité.

        c'est un peu comme si je disais que j'ai une voiture qui roule à 320km/h (ce que je n'ai pas :o) ) sans préciser que je suis un pilote de F1....


        Alors oui, pourquoi pas du technique en première page, mais quelquechose de plus concret, un HOWTO compilation de kernel optimisé vitesse ou autre (je n'ai pas pris la précaution de vérifiér s'il existait, pardonnez moi).

    • [^] # Re: C'était vraiment la peine ...

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

      "...de mettre cette news kekette 2002 en première page ?"
      Tiens, c'est une idée ça. Un nouveau thème: "vise la taille de mon kernel" :)
      mais on s'égare là...-1

  • # 32 way logical partition ?

    Posté par  . Évalué à 10.

    using a 32 way logical partition, 1.1GHz POWER4, 60G RAM
    not a bad result for something running under a hypervisor

    Est-ce quelqu'un peut expliquer ce qu'est exactement cette machine ?
    S'agit-il d'une machine avec un seul processeur Power4 et configuré comme 32 machines indépendantes avec ce qui semble s'appeler un "hyperviseur" ?
    Ou s'agit-il d'une machine avec 32 processeurs Power4 ?
    Et qu'est-ce qu'un hyperviseur ?

    Merci.

    • [^] # Re: 32 way logical partition ?

      Posté par  . Évalué à 10.

      Je pense qu'il faut comprendre cela comme une machine virtuelle (typiquement IBM S/370, S/390 - zSeries - et autres) dans chacune desquelles on peut faire tourner un environnement étanche. Toutes les machines virtuelles sont contrôlées par l'hypervisor. De plus, le nombre de machines virtuelles n'est pas nécessairement lié au nombre de processeurs. Sur les AS/400 (iSeries) il y a également la possibilité de créer des partitions logiques d'environnement d'exécution. Du reste, c'est dans une de ces partitions dédiées que tourne Linux sur l'AS/400.

      Voilà voilà.

    • [^] # Re: 32 way logical partition ?

      Posté par  . Évalué à 10.

      a priori ça serait un truc dans ce genre là :
      http://commerce.www.ibm.com/content/home/shop_ShopIBM/en_US/eServer(...)

      ça commence à $480000 quand même : compiler son noyeau plus vite que tout le monde, c'est pas pour toutes les bourses. ya pas l'air d'avoir de modèles à moins de 8 proc.

      d'après les détails donnés ici :
      http://www-1.ibm.com/servers/eserver/pseries/hardware/datactr/p690_(...)
      les power4 vont toujours au moins par 2 parce qu'il ont mis deux procs en une seule puce.

      La carosserie est moche mais ce qu'il y a à l'intérieur est drôlement chouette.

      Sinon le coup des partitions logiques, moi je comprend qu'il a une machines avec 32procs et qu'il les a tous assignés à son instance de linux.

      • [^] # Re: 32 way logical partition ?

        Posté par  . Évalué à -2.

        ben,j'ai juste un commentaire :

        ÇA TUUUUUUUUUUE !!!!!!!

        j'en veux un comme celui là chez moi !!!
        euurrh,mouais,je sais pas si j'ai l'allimentation électrique necessaire.....

        Mais j'ai un beau projet qui s'en viens pour dans 1 ans et demi!!

        Monter un cluster de 8 processeurs monté pour fonctionner comme un bus interne,je dis bus interne par rapport a la rapidité du système entre les clients et le serveur : communication en SCSI !!!

        peut-être 8 Athlon XP 2.5 ghz (quand ca va sortir) avec 512 megs de DDR 333(ou 400).. Les clients vont être diskless,et un Bios Linux pour controler les clients... Le tout refroidit par un refroidissement liquide!

        Ça va demander de l'électronique et pas mal de $$$$ mais putain,ça va être le pied!!!

        • [^] # Re: 32 way logical partition ?

          Posté par  . Évalué à 5.

          C'est vrai que les performances de cette bete sont assez grisantes !
          Ceci dit, une description plus complete de la plate-forme aurait ete la bienvenue...

          P.S. :Beau projet que tu as la...
          Il faudra prevoir une petite doc et un post sur linuxfr pour partager ton experience une fois que la machine tournera !

      • [^] # Re: 32 way logical partition ?

        Posté par  . Évalué à -4.

        surtout qu'à mon avis, il y avait au moins 64 procs

  • # Il s'est trompé, non?

    Posté par  . Évalué à -7.

    Je crois qu'il y a tromperie.
    Si on regarde la ligne de fin c'est 40.23 secondes qu'il faut voir et pas 7.52.
    Il me semble que la seule valeur importante est le temps utilisateur, non ? (le temps système est compris dedans).

    • [^] # Re: Il s'est trompé, non?

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

      Si je ne me trompe, dans le cas d'un multipro, le temps user, c'est la somme du temps user consommé sur chaque CPU donc on peut arriver à avoir temps user > temps écoulé.

      • [^] # Re: Il s'est trompé, non?

        Posté par  . Évalué à -4.

        je ne crois pas, non. Quelques tests sur bi-Pro ne m'ont pas fait apparaître cette caratéristique.
        En tout cas ça ne marche pas comme ça avec 'times' ou 'rusage' (puisque j'arrive à mesurer une accélération sur un bi-pro avec ces 2 appels).

        • [^] # Re: Il s'est trompé, non?

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

          Bon, comme j'ai aussi un vieux bi-PII 266, je viens de faire le test avec un "time make -j 3" :

          real 12m57.700s
          user 24m13.590s
          sys 1m32.570s

          Donc on a bien le temps user qui est égal à environ 2*le temps real sur un bi CPU.

          C'est à comparer avec les 3m20s que j'obtiens pour faire exectement la même chose avec un seul Athlon à 1667 MHz. C'est un cas de calcul dont l'évolution du temps d'execution est relativement linéaire par rapport à la somme des MHz qu'on a sous la main.

  • # - de 2min

    Posté par  . Évalué à -3.

    noyau 2.4.18 smp sur un bi athlon 1800 mp
    support smp / dri et une carte rezo

    moins de 2 min

    j ai meme pas eu le tps de passé sur mon canapé ...

    Dés que je peux je test ca sur un quadri xeon

Suivre le flux des commentaires

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