Comparaison entre les noyaux 2.4.25 et 2.6.4

Posté par . Modéré par Christophe Guilloux.
0
29
mar.
2004
Noyau
Le site www.2cpu.com nous propose un article comparant les performances des noyaux 2.4.25 et 2.6.4 sur une machine SMP.

Y sont comparés entre autres l'utilisation d'un point de vue station de travail et serveur. On y trouve notamment une comparaison portant sur :
. le couple apache/mysql en tant que serveur web ;
. Samba en tant que serveur de fichiers ;
. d'autres logiciels pour des activités comme la compression mp3 en tant que station de travail.

L'article tient en 5 pages et est vraiment intéressant à lire, puisqu'il aborde la comparaison d'un point de vue station de travail et serveur, et permettra à chacun de trancher entre le passage au 2.6.4 et rester en 2.4.25 selon l'utilisation de la machine.
Bonne lecture !

Aller plus loin

  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à -4.

    Ils trichent : ils utilisent Gentoo, le noyau a été recompilé

    sortons vite avec qu'on ne me voit ----->[ ]
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à -1.

      Oui mais sauf que dans Gentoo y a un gros problème, à savoir impossibilité de compilé la glibc avec l'option linux-thread (flag nptl) pour le kernel 2.6, ou alors c'est instable par rapport à une slackware compiler dans les règles!.

      c'est triste qu'un facteur si important soit négligé.

      Gentoo c'était bien un moment.... mais à force de trop vouloir customiser/patcher, on se retrouve avec aucuns des gains attendus/prévus.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par (page perso) . Évalué à 3.

        C'est tout a fait possible, je l'ai fait sur une machine de test (parti de stage 1, en ~x86, avec flag ntpl et noyeau 2.6 y compris pour le bootstrap) et ca marche tres bien...

        Et justement, c'est dommage que l'article n'en parle pas, parceque ca donne probablement de bien meilleures perfs ...
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à -1.

          quelle exécution dans mes XP's, wow quoi!

          sinon, j'persiste et signe, j'obtiens de bien meilleurs résultats avec une slack adaptée plutôt qu'en passant pas les ebuilds de Gentoo. Et je ne suis pas un fou de l'optimisation, je laisse tel quel pour être le moins exotiques possible.


          Enfin voilà, exploser mes XP's à cause de cette histoire, d'ailleurs ce n'était pas un troll, désolé si vous y avez cru mais je n'ai pas vot' tic.


          troll <-- je hais ce mot! à croire qu'il y a un quota dont vous vous sentez dans l'obligation d'assurer sur linuxfr.org


          ce sera sans doute mes derniers mots, la censure va frapper encore une fois.
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par (page perso) . Évalué à 2.

            sinon, j'persiste et signe, j'obtiens de bien meilleurs résultats avec une slack adaptée plutôt qu'en passant pas les ebuilds de Gentoo. Et je ne suis pas un fou de l'optimisation, je laisse tel quel pour être le moins exotiques possible.

            Bah forcement, si tu n'est pas un fou de l'optimisation tu dois avoir "-march=i386" comme CFLAGS. Forcement ça aide pas pour avoir de meilleurs performance ;-)

            Sinon je ne sais pas sur quoi tu t'appuis pour dir que ntpl sous Gentoo c'est instable. Déjà il n'y a pas deux Gentoo qui se ressemble et personnelement je l'utilise sur deux machines depuis longtemps et je n'ai aucun problème de stabilité !
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 2.

            troll <-- je hais ce mot! à croire qu'il y a un quota dont vous vous sentez dans l'obligation d'assurer sur linuxfr.org

            Et bien ! Mais que voilà un bien étrange discours. Sachez-le, linuxfr à tendance à être une matrice inéxtinguible ou les trolls se créent spontanément au gré des discussions et des nouveaux journaux.

            Il n'y à pas de volonté propre de troller, mais le fait est que souvent le troll s'impose de lui même dans ce qu'on qualifie communément "sujet à troll". Il se trouve seulement que tout est sujet à troll sur linuxfr.

            Même la critique des trolls.

            Les trolls de linuxfr sont courtois et pondérés. Ils ont le poils soilleux, la len fraiche, le regard brillant, ils sont gentils, affectueux, joueurs, cannibales.

            D'ailleurs, les XPs ne sont-ils pas une des conséquences à la prolifération de messages à caractères trollesque, voir trollier ? Ne voit -on pas, souvent, un utilisateur hurlant à la perte de ses XPs, et créant un troll pour l'occasion ? Ou un message anodin vilipandant vertement le système de vote de linuxfr dégénérer en une suite de message tendant invariablement vers le point Godwin ?

            Rien que le fait de parler de troll, va, dans un esprit perturbé comme le mien créer une réflexion sur la société trolltech, et dérivé invariablement sur "Qt c'est bien ? et GtK, alors ?"


            Tout ça, pour répondre, finalement à ta question : oui, il y a des quotas imposé sur linuxfr. Cela fait parti de règles transmisent seulement à l'oral par ce qui est communément appellé la cabale, qui rappelons le, n'existe pas.

            Voilà. Et moi, je vient de remplir mon quotas ^^

            Mitsuaki, qui empreinte la traditionelle porte de sortie -->[]
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 1.

          Est ce que quelqu'un peut m'expliquer rapidement ce que permet cette option de compilation et ce qu'apporte l'utilisation du flag ntpl ?
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 3.

        Bein si... Tu as juste à ajouter "nptl" dans ton USE.
        Tous mes serveurs fonctionnent comme ça depuis longtemps.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 2.

        Ça fonctionne ici aussi! (glibc2.3.2 kernel2.6.5_rc1 kernel-headers2.6.4)
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par (page perso) . Évalué à -3.

        C'est triste ton opinion sur les facteurs....

        (((_/) ===============> [_] !!!
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à -1.

        C'est trise, ton point de vue sur les facteurs.
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à 3.

    /!\ CECI N' EST PAS UN APPEL AU TROLL /!\

    Je serai curieux d' avoir une comparaison avec un des Windows, j' ai aucune idée ou se trouve les performances d' un 2.4 ou d' un 2.6 par rapport aux solutions Microsoft ...

    Pour les trolls d' autres s' en occuperont à ma place ...
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      Pour un bonne comparaison 2.4.25, 2.6.4 avec un noyau de chez Microsoft, faudrait pouvoir au moins recompiler le noyo avec le source.

      Il se peut que les labos de microsoft en soit capable mais ils n'ont aucune crédibilité.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 1.

        L'un des avantages de certains GNU/Linux est qu'on puisse recompiler pour optimiser. Window$ n'a pas cet avantage et ce n'est pas ça qui devrait empêcher les benchs. Au contraire utilisons ce défaut de Window$ pour comparer avec GNU/Linux. Les seules choses à avoir en commun, pour ce type de bench, sont le matériel et les logiciels.
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par (page perso) . Évalué à 4.

          Avant de dire ça, faudrait d'abord arriver a prouver que recompiler apporte un gain
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 1.

            Ok, certes.
            Toujours cette même question :-)
            À quand une réponse sûre...
            Mais de toute façon, si la recompliation n'apporte pas de gains, alors le comparatif GNU/Linux - Window$ sera d'autant plus facile et rapide à réaliser.
            • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

              Posté par . Évalué à 3.

              La compilation apporte certainement des différences.

              Mais il faut quand même se rendre compte que:

              si tu utilises ton ordinateur 40 heures par semaines, et que tu gagne en recompilant 10%, tu gagne 4 heures. Mais pour recompiler tu a mis:

              1/2 heures pour le noyau
              10h pour OOo,
              2h pour xfree
              etc....

              Quand tu fais le bilan c'est pas sûr du tout que la couche d'ozone y gagne. C'est surement mieux si ta distrib fait une optimisation spécifique.

              Je viens de mettre mplayer (de chez marillat), marche très bien et c'est 586 et plus 686. Mais qu'est-ce que je gagnerais à recopiler en 686?

              Par contre, il me semble avoir vu passer l'information suivante; gcc optimise très mal sur 386, beaucoup mieux sur 486, 586 et 686. http://debian-i586.sourceforge.net/(...)
              • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

                Posté par . Évalué à 1.

                Il me semble que ce projet est mort, du moins c'est ce qui transparait de l'indicateur "Activity Percentile (last week): 0%" sur la page du projet sous Sourceforge. Dommage, j'aurais bien essayé. Moi, j'avais plutôt entendu dire que gcc ne fournissait plus du vrai code i386, et que c'est en partie pour cela que Slacware était devenue i486 et non plus i386. Ca serait bien qu'un pro de gcc complète parce que je n'en suis pas un.
              • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

                Posté par . Évalué à 1.

                oulala, je ne voulais pas lancer un troll.
                De toute façon, windows ne peut pas être recompilé donc la question ne se pose que pour linux.
                Et comme la question de l'apport réèl de l'optimisation traine depuis longtemps, on peut être à peu près sûr que cet apport n'est pas gigantesque.
                Donc pour un comparatif, on peut largement se contenter d'un GNU/Linux précompilé.
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 1.

            Recompiler apporte un gain.

            Maintenant je l'ai dit !

            Plus sérieusement recompiler apporte un gain certain, déjà de place mais aussi en rapidité. Le plus belle exemple et pour l'hyperthreading (mais c'est pareil pour mmx ou sse) sur une machine standard l'hyperthreading ne peu pas être utlisé donc il n'est pas compilé, en recompilant avec le support de l'hyperthreading tu peu gagner beaucoup de temps pour certain calcul.

            Maintenant il doit être possible pour microsoft de supporter l'hyperthreading en 'patchant' le noyau je suppose.
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 1.

          Attention, sais tu au moins qu'elle compilateur est utilisé pour compiler les sources de windows ? Parce que peut être que ce compilateur génére des executables plus optimisé par defaut que gcc ... ou peut-être que non (non je ne suis pas normand)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par (page perso) . Évalué à 3.

      bah demande à microsoft, il te l'explique ici :
      http://www.microsoft.com/mscorp/facts/default.asp(...)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 3.

      Samba 3 vs Windows 2003

      En serveur de fichier
      samba 3 : 2.5 x plus rapide que MS windows 2003.

      http://www.kegel.com/nt-linux-benchmarks.html(...)

      (c'est tres discutable, car comme tous les benchs, on ne sait rein du pourquoi et du comment ....)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 3.

      /!\ CECI N' EST PAS UN APPEL AU TROLL /!\

      Pareil.

      Je serai curieux d' avoir une comparaison avec un des Windows,

      Ici le bench est intéressant car il ne fait varier que le "paramètre" noyau sans toucher aux "paramètres" applis. Si tu veux faire le même test avec Windows les différences de performances seront dûes à la différence entre Windows et Linux, certes, mais surtout à la qualité du portage des applis sous Windows, voire carrément à l'application elle même lorsqu'il faudra comparer samba sous Nunux avec le système natif de Windows. Bref quelque soit le résultat d'un tel bench il n'apportera probablement rien de nouveau sous le soleil.
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par (page perso) . Évalué à 6.

    IDM developerworks :
    Kernel comparison: Web serving on 2.4 and 2.6
    New features add up to faster, more reliable Web performance
    Level: Intermediate
    http://www-106.ibm.com/developerworks/linux/library/l-web26/index.h(...)
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par (page perso) . Évalué à 6.

    Il ne faut pas oublier non plus de préciser que ce benchmark a ete fait sur un bi processeur et donc qu'une partie de l'augmentation sensible des résultats avec Mysql peut etre due à une meilleure gestion SMP. (ce qui n'enleve rien a la qualité du 2.6 ou du benchmark :)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 4.

      Très bonne remarque !
      L'amélioration spectaculaire avec Samba (+89%) des performances me laisse plutôt penser que c'est la partie SMP qui est largement responsable des gains avec un noyau 2.6.4.
      Le travail de réécriture de la partie SMP a été relativement important et j'avais déjà noté une amélioration des performances sur les versions antérieures au 2.6.4.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 4.

        Pas seulement. Le 2.6 a d'énormes améliorations au niveau de l'ordonnancement des entrées/sorties disque (et oui, c'est important, car comme bouger la tête de lecture prend du temps, il faut optimiser l'ordre dans lequel sont faites les requêtes pour minimiser ses mouvements...).
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 2.

          La couche IDE a également été revue en profondeur.
          Un commentaire sur le site du bench signale pertinemment que les améliorations peuvent provenir essentiellement de cette amélioration, dans la mesure où ce sont justement les tests qui sollicitent les I/O disques qui montrent les plus grands gains de performance.
          Il aurait été intéressant de refaire le bench avec des disques SCSI, la supériorité du 2.6 pourrait être bien moindre.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par (page perso) . Évalué à 0.

        Et à mon avis, avec un monstre à 8 proc ou plus, le résultat serait encore plus flagrant.
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 1.


          Et à mon avis, avec un monstre à 8 proc ou plus, le résultat serait encore plus flagrant.


          Justement, jusqu'à combien de processeurs peuvent être gérés par ces noyaux ? Avec quel niveau de performances ?
          Ce serait également intéréssant d'avoir un comparatif avec d'autres noyaux de systèmes Unix (et pouvoir ainsi les comparer avec des programmes identiques d'un système à l'autre).
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 1.

            Justement, jusqu'à combien de processeurs peuvent être gérés par ces noyaux ? Avec quel niveau de performances ?

            Ca dépend de ce qu'on appelle gérer, c'est à dire juste fonctionner, ou bien correctement exploiter (c'est à dire avec des performances qui ne s'écroulent pas à cause des verrous noyau à gérer).

            Je crois que pour le 2.4, l'efficacité diminue à partir de 8 processeurs, alors que pour le 2.6, on peut monter à 64 processeurs, grâce à la gestion plus fine du SMP et des verrous qui vont avec (verrous sur les entrées/sorties, sur les diverses structures internes). Dans les premiers temps du noyau SMP, il ne pouvait y avoir qu'un seul processeur dans le noyau à la fois, avec le "big kernel lock" (il a disparu à présent).
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à -2.

    Et pour résumer, ca dit quoi ?
    (dslé, mais j'ai pas trop le tps de lire les 5 pages surtout en anglais)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à -1.

      Lis rien que les schémas !
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à -1.

      Ben tu fais comme moi, tu parcours les pages à la recherche des graphiques...

      Je pense qu'on pourrait résumer :
      Utilisation en poste de travail : avantage au 2.4
      Utilisation serveur : avantage au 2.6

      Par contre je trouve un peu inutile de comparer les deux étant donné que le 2.4 n'avance plus... C'est comme si on faisait un bench entre le 2.0 et le 2.6... imaginons que le 2.0 soit 25% supérieur au 2.6... ok, mais s'il n'évolue plus... Quel est l'intérêt de l'utiliser ? (mis à part pour le vieux matériel et les vieux drivers)
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 1.

        Beaucoup de features ont été backporté du 2.6 vers le 2.4 ....
        Il évoluera moins vite, c'est certain ;-)

        Sinon ce genre de benchmark peut justement inciter à "basculer" des machines vers la branche 2.6, samba par exemple. Ca peut aider dans un choix.

        3 semaines avant, il m'aurait bien aidé dans les miens. ;-)
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à -1.

        Merci Pierre Tramo, j'en demandais pas plus :)

        Décidément, ce Pierre Tramo, il est fort !!!
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 1.

        En tous cas, je suis content de constater que les dev du noyau ont bien tenu leurs promesses su début du lancement du 2.5.x, à savoir que cette nouvelle branche était vraiment plus ciblée gros systèmes, avec beaucoup de RAM, de process (ordonnanceur O(1), NTPL, ...)
        Comme quoi, contrairement à la politique, en informatique, on tient ses promesses!!!
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 1.

        Quel est l'intérêt de l'utiliser ?

        Beaucoup de gens préfèrent attendre encore un peu et continuer à utiliser le 2.4 plutôt que de passer à un 2.6 encore jeune avec lequel des problèmes peuvent encore apparaître (pas forcément dus au noyau lui-même et son développement).
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à -4.

          Oui et grâce à ces gens qui se contentent d'attendre, le 2.6 est moins testé, donc il y a moins de rapports de bogues, donc les développeurs ne sont pas au courant des problèmes que les gens ont, donc le 2.6 a encore des problèmes, etc.

          Attendre... attendre... tout tombe du ciel... attendre... attendre... en espérant que quelqu'un d'autre se bouge les fesses un jour pour expliquer un bogue que l'on vient pourtant de rencontrer... c'est bien, ça fait évoluer les choses.
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par (page perso) . Évalué à 1.

            Un des avantages de Linux vis-à-vis de certains OS proprios, c'est justement de ne pas exiger que les utilisateurs soient des bêta-testeurs. Ça peut être utilie pour des appli en prod, dans la vraie vie.
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 1.

            Parce que tu crois que les admins serveurs ont le temps pour ça? Tu crois que celui qui veut simplement utiliser une station de travail sans connaître de problèmes va avoir le temps pour ça? Tu sais, il y a des gens pour qui l'informatique n'est pas forcément une passion, ils attendent de l'efficacité; il y en a d'autres qui n'ont qu'une seule machine et n'ont donc pas de machine "suicide" :-) et qui ne peuvent pas se permettre d'être bloqués.
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 3.

        De manière générale:« If it ain't broken, don't fix it. » (Si ce n'est pas cassé, ne le répare pas)

        Un projet actif a beaucoup plus de chance d'introduire de nouveaux bug/trous de sécurité. Donc si un noyau 2.0 fait ce que je veux, je le garde. Si en plus, il est 25% plus rapide qu'un 2.6, je m'accroche encore plus à lui. Pour moi, mon bon vieux 2.0 est BEAUCOUP mieux qu'un 2.6.

        Frédéric
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à 1.

    Le comparatif sur le serveur de fichiers SAMBA m'a fait halluciner.
    89% de gain supplémentaire en sortie pour le 2.6.4 !!!
    http://www.2cpu.com/articles/98_5.html(...)

    On fut nombreux à hésiter à basculer nos serveurs de fichiers en noyau 2.6. Le support des ACL pour le système de fichiers XFS donna l'avantage au 2.6.

    Après dbench, il aurait été interessant de voir un comparatif avec tbench ... Histoire de comparer les mesures en sortie en occultant complètement le FS.
    Ceci afin d'être sûr que c'est bien le FS qui est à l'origine d'un gain de 89% sur les 2.4.

    En tout cas, très instructif ces benchmarks.

    Ankill
  • # -mm

    Posté par . Évalué à 3.

    C'est dommage que des variantes du noyau n'aient pas été testées, comme la branche -mm (avec le scheduler CFQ) ou celle d'Andrea.
    • [^] # Re: -mm

      Posté par . Évalué à 4.

      de plus, on ne sait pas si le serveur X tournait ou pas pendant son bench. J'ai vu que le preempt ne semblait pas active, alors je sais pas trop.

      Il semble attribuer au schedduler la diff de perf au debut. Alors pourquoi ne donne t-il pas le nombre de thread/process de chaque bench ? sur un bi proc, c'est important de savoir.
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à 0.

    d'autres softs d'autres logiciels ...
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par . Évalué à -1.

    Il y a une chose qui me fait bondir :

    Autant le bench pour l'utilisation en serveur me parrait correct,
    autant pour la station de travail, il manque une partie certe subjective,
    mais primordiale :

    Avec un 2.4.25 lorsque vous utilisez le CPU à 100%, vous ne pouvez rien faire d'autre !
    Alors qu'avec un 2.6.x, en preemptif, c'est du bonheur : (a niveau de nice egal) tu encode de DV en DVD (mpeg2) en meme temps que tu rédiges un rapport sous OO.org, sans meme t'apercevoir que ton CPU est à 100%.
    Ca c'est vraiement important ! C'est ce qui fait toute la différence entre les kernels d'ancienne générations (Win32,2.4.x) et ceux de la nouvelle 2.6.x.

    De plius ce bench ne nous dit pas les options de compilation, qui ont somme toutes leur importances !

    Guillaume
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      Avec un 2.4.25 lorsque vous utilisez le CPU à 100%, vous ne pouvez rien faire d'autre !

      Une remarque comme ça me fait bondir instantannément ! hého il est quand même pas trop trop mal le scheduler du noyo 2.4 !!! As-tu essayé le CPU à 100% chez microsoft ??? là oui on ne peut vraiment plus rien faire d'autre..

      par contre je suis d'accord pour dire que le 2.6 réagit mieux, evidemment
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par . Évalué à 4.

        Si j'etais toi, j'eviterai de comparer le scheduler du kernel 2.4 et le scheduler de Windows >=2000... , histoire d'eviter une deplaisante realite...

        soft affinity
        hard affinity
        scheduler O(1)
        I/O priority boost
        foreground thread boost
        etc...

        tout cela etait deja dans le scheduler de Win2000, il y a 4 ans.

        Le scheduler du 2.4 etait loin, tres loin, derriere le scheduler de 2000 et c'etait flagrant sur les grosses machines(>=8 cpu).
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par (page perso) . Évalué à 2.

          Vi peut etre bien, mais le monsieur là, il a raison.

          Au boulot on est sous 2000 et on developpe une appli multi thread et multi process deploye sur une vingtaine de postes.
          Lorsqu'un processus occupe 100% du CPU, ca freeze toute la machine.
          Ca c'est une constatation.

          Sous Linux 2.4 ca rame mais ca ne freeze pas.

          Maintenant, je n'ai pas essaye avec XP. J'espere que c'est mieux.
          • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

            Posté par . Évalué à 1.

            Si ton process a une priorite elevee et qu'il a du boulot, il va avoir le CPU, c'est normal, c'est le scheduler qui veut ca, si ca ne te plait pas, faut changer la priorite du process, si tu veux eviter que tes users fassent les malins avec des process haute priorite, tu limites leur acces aux hautes priorites avec des jobs.

            Remarque, j'esperes que ton soft utilise par une priorite REALTIME si il passe son temps a 100% CPU...
            • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

              Posté par (page perso) . Évalué à 1.

              Non, priorite "normale" : on a rien touche.
              Quand ce process prend la main pour un calcul, il bouffe 100% du CPU au point que l'IHM ne se rafraichit meme plus.
              Meme la souris et le CTRL-ALT-SUP ne repondent pas parfois.
              Pourtant la machine n'est pas plante, juste chargee !
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 1.

          Qu'est-ce que tu pense du scheduler du 2.6 par rapport au scheduler de 2000 ou de 2003 ?
          Est-ce que tu pense qu'il y a un domaine ou Linux (2.4 ou 2.6) est meilleurs que Win 2003 ?
        • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

          Posté par . Évalué à 1.

          Je suis d'accord avec toi pBpG sur le scheduler de win2000 pour 8 proc ou plus... Par contre en monoproc, un process à 100% ne te mange pas toute la réactivité de ta machine, alors que sous XP promis juré, ça mouline complètement :-(

          Alors ... y'a plusieurs points de vues.. sachant que mon commentaire est incomplet, et que je ne décrit pas seulement un process qui prends 100% du temps machine, mais qui effectue aussi des E/S sur disque, et qui enfin prends pas mal de mémoire.

          Tout ce que je peux constater c'est que sous linux on a toujours la réactivité de la machine (i.e. utiliser d'autres tâches sans patienter derrière un sablier) alors que sous XP on en est déjà plus loin.
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par (page perso) . Évalué à 1.

      Avec un 2.4.25 lorsque vous utilisez le CPU à 100%, vous ne pouvez rien faire d'autre ! »

      Ca se discute. L'autre jour, je me suis amusé à faire du apt-build de la glibc sur deux ordis, consécutivement. Ils s'utilisaient très bien alors qu'ils étaient à 100 %. Le fait qu'ils soient à 100 % n'empeche pas qu'il y ait une gestion des priorités. Si tu ne peux rien faire quand ton CPU est à 100 %, c'est soir que tes priorités sont mal gérée, soit que ton CPU est pas assez puissant pour faire tourner l'appli que t'utilise. Mais si ton CPU est à 100 % parce que tu compiles, tu devrais pouvoir vaquer à tes occupations avec pratiquement la même fluidité.

      Bref, si c'est ça qui fait la différence, c'est pas franchement pertinent !
      • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

        Posté par (page perso) . Évalué à 1.

        C'est clair, la différence en poste de travail n'est vraiment pas flagrante... Ca réagit différemment mais en terme de confort; je serais incapable de dire lequel je préfère....
        Quand au délire de dire : si le CPU est à 100%, un 2.4 ne fait plus rien d'autre... Il faut vraiment qu'il en prenne plein la tête (genre charge 10 pour un monoproc) pour que le kernel 2.4 ne réponde plus très bien. Pour ce que j'ai pu constater, la grosse différence semble être plutot sur les I/O : il y a moins de dégradation des temps de réponse quand il y a une forte charge I/O sur 2.6.
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      De plus ce bench ne nous dit pas les options de compilation, qui ont somme toutes leur importances !

      ?

      Si. Tu as les deux .config de chaque noyau, le configure utilisé pour chaque source et le CFLAGS utilisé pour la compilation.

      qu'avec un 2.6.x, en preemptif
      # CONFIG_PREEMPT is not set (Dans le .config du 2.6.4)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      Les .config sont en page 2
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      «l y a une chose qui me fait bondir [...]
      Avec un 2.4.25 lorsque vous utilisez le CPU à 100%, vous ne pouvez rien faire d'autre !»


      Moi, c'est ce que tu écris qui me fait bondir! :)

      Je sais pas avec quoi tu a mesuré ton «100%», mais 100%, c'est (presque) pas beaucoup.
      Si le processeur est a 100% et que tout les processus sont servis, tout va bien. Si, par contre il y en a 4 ou 5 qui attendent, c'est déjà moins bien. Il vaut mieux vérifier la charge à l'aide de uptime ou /proc/loadavg. En tout cas, moi, sur un 2.4 avec une charge de 2 ou 3, ça reste utlisable (suivant les applications) et même le bureau reste réactif ! tout ça avec des valeurs de nice = 0.
  • # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

    Posté par (page perso) . Évalué à 1.

    Il y a un biais de départ : il porte sur une machine récente, dont le matériel est donc probablement bien mieux gérer sur un noyau très récent (en développement récent ; je rappelle que malgré les apparences, le 2.4 n'est plus censé être développé depuis un an).

    Si le 2.6 tourne mieux sur une machine très récente que le 2.4, sur une machine qui a un an (c'est pas extremement vieux), il est possible que ces différences soient moins notables... Ensuite, esperons tout de même que le 2.6 tourne mieux que le 2.4 :)
    • [^] # Re: Comparaison entre les noyaux 2.4.25 et 2.6.4

      Posté par . Évalué à 1.

      Justement, il indique qu'il avait initialement prévu de faire ses benchs sur des machines plus modestes aussi, mais qu'après avoir rencontré des problèmes il n'a conservé que ceux du serveur bi xeon. Suprenant tout de même, je ne vois pas quel problème aurait pu l'empecher de faire la meme chose, si ce n'est un disque dur qui prend feu! :) En tout cas c'est bien dommage, mais son bench reste intéressant pour les serveurs.

Suivre le flux des commentaires

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