Nouvelle branche du noyau: -mjc

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
2
jan.
2002
Noyau
Un dénommé Michael Cohen vient d'anoncer sur la LKM (Linux Kernel Mailinglist) la création d'une nouvelle branche du noyau 2.4, axée sur les performances.

Au menu:
Reverse Mapping patch #9 (Rik van Riel)
Preemptible Kernel Patch (Robert Love)
Lock-Break Patch (Robert Love)
CPU affinity /proc entry (Robert Love)
Netdev-random (Robert Love)
Software Suspend (Gabor Kuti?)
Real Time Scheduler for Linux (?)
IDE updates (Taskfile IO and others) (Andre Hedrick}

A vos compilateurs !

Aller plus loin

  • # Et gcc?

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

    Je me suis demander apres avoir lu un chapitre du Black Book de Abrash si notre compilateur preferee (gcc bien sur :) etait capable de paralelliser du code? Kelk'un as des infos la dessus? Gcc 3.0 le fait? Pasque cela ne sert a rien d'avoir un kernel optimizer si le compilo vous sort du code pour 386 no ? :)

    • [^] # Re: Et gcc?

      Posté par  . Évalué à 2.

      Ce n'est pas au compilateur de "paralleliser" le code, c'est au programmeur de le faire, en utilisant les threads (light ou pseudo ou autres). C'est ensuite l'OS qui va paralleliser les threads sur les différents CPU.

      • [^] # Re: Et gcc?

        Posté par  . Évalué à 3.

        Je me demande s'il ne parlais pas de pipelining plutôt que de multitheading... De toute façon la question est bizarre.

      • [^] # Ca dépend :-)

        Posté par  . Évalué à 8.

        J'ai "presque" fait un thése sur un compilateur parallélisant.

        Certains compilateurs sont capables d'extraire certains type de parallélisme tout seul comme des grands, mais pour extraire plus de parallélisme, l'intervention d'un programmeur peut aider.

        Pour autant que je sache, gcc n'est pas capable d'extraire automatiquement du parallélisme.

        Il n'y a pas un parallélisme mais plusieurs type, par exemple: les threads, les vecteurs (ex 3DNow! ou MMW/SSE), le pipeline.

        • [^] # Re: Ca dépend :-)

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

          Donc gcc n'est pas "capable" de parallelise les instruction dans les pipeline de mon proc :(
          Et quant est il des projets tel que PentiumGCC ? (qui est abondonner depuis pas mal de temps ...)
          Car je me souviens avoir reussi a compiler un noyau 2.2 avec ce compilo et gagner pas mal en perf :)

          PS : desoler je parler de pipelining dans le commentaire precedant :))

        • [^] # Re: Ca dépend :-)

          Posté par  . Évalué à 7.

          Oui justement. Et malheureusement au point de vue des performances pures, gcc tient rarement la comparaison...
          Au niveau de la parallélisation, c'est du côté de PGI qu'il faut chercher (http://www.pgroup.com(...)). Sinon, d'une façon générale, il existe pour linux icc (d'Intel) avec une licence de merde (on est loin du libre), des rpms uniquement mais les résultats sont éloquents : +-20% de gagnés en moyenne, et parfois beaucoup plus dès que le code n'est pas optimal (car certaines optimisations sont faites automatiquement).

          • [^] # Re: Ca dépend :-)

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

            J'utilise le flag -march=k6 pour compiler sur mon k6 c'est deja ca ! Savez vous ce que fait ce flag ?
            Quelqu'un sait si AMD prepare un patch pour gcc ? histoire d'ameliorer les perf sur les k6/k7

  • # Lien

    Posté par  . Évalué à 7.

    Le patch à ,déjà changé de place, il est maintenant sur le site oficiel du kernel
    http://www.kernel.org/pub/linux/kernel/people/mjc/(...)
    ou ftp si vous voulez
    ftp://www.kernel.org/pub/linux/kernel/people/mjc/(...)

  • # C'est mieux comme ça...

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

    Je crois que c'est préférable de faire une nouvelle branche pour ce noyau... même si cela peut poser des problèmes de choix/diversifications et de test un peu moins pousser...

    Mais le fait d'avoir le patch pour le noyau préemtible directement intégré dans le noyau de base me faisait peur...

    Comme cela, ça permet d'être sûr que cela marche sur un noyau de test.

    • [^] # Re: C'est mieux comme ça...

      Posté par  . Évalué à 3.

      Le patche pour rendre le noyau pré-emptible ne doit pas et -j'espère- ne sera pas intégré au noyau standard.

      A quoi sert ce patche ? à assurer des temps de réponses très rapides aux applications qui en ont besoin, ceci par une modification du scheduler.

      Ainsi, on peut par exemple faire de l'acquisition et du montage video/son dans d'excellentes conditions.

      Par contre, ce patche implique un nombre beaucoup plus élevé de changement de contextes, ce qui signifie que si tu as beaucoup de processes qui tournent en meme temps sur ta bécane, l'ensemble du système sera fortement ralenti.

      C'est pour cette raison que c'est un patche et que cela doit le rester. Linux sert plus comme serveur à tout faire que comme station de montage vidéo.

      Si ce n'est plus un patche, ce doit être au plus une option du noyau.

      • [^] # Re: C'est mieux comme ça...

        Posté par  . Évalué à 8.

        1/ Le patch ne modifies pas le sheduler, mais rend le code s'exécutant en mode noyau interruptible au même titre que le code user-space;
        2/ Oui, il augmente la fréquence des changements de contexte, mais ce n'est pas son but. Si tu veux modifier la fréquence des changements, tu changes les #define sur le timeslice. Le but là est d'éviter qu'une appli qui a épuisé son temps puisse garder parce qu'elle s'exécute en mode noyau; cela n'a rien à voir.
        3/ Le patch se contente de rajouter une option de compile (CONFIG_PREEMPT) qui est désactivée par défaut, donc intégrer le patch au noyau ne vaut pas dire qu'il soit activé par défaut.

Suivre le flux des commentaires

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