Comparatif des VM de Linux et FreeBSD

Posté par  . Modéré par dumonteil jerome.
Étiquettes :
0
14
nov.
2001
Noyau
Suite à son article sur la nouvelle VM (Virtual Memory) apparue avec le noyau 2.4.10, Moshe Bar a mis à jour son comparatif des VM de Linux et FreeBSD. L'ancien comparatif (Linux 2.4.0 et FreeBSD 4.1.1) laissait apparaître un net retard de Linux.

Le nouveau comparatif remet les 2 OS sur un pied d'égalité.

Aller plus loin

  • # La conclusion ...

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

    In fact, I love both ...
    trad : "En fait, j'aime les deux"

    Voila, je crois que tout est dit ...

    Mouarf !
    • [^] # Re: La conclusion ...

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

      Tout à fait d'accord.
      Chacun a ses avantages et ses inconvénients comme d'hab. En plus, la VM de Linux est en cours de changement, on peut donc pas encore lui demander la lune mais ça va changer, j'en suis sûr. En plus, cette nouvelle version a été une profonde modif de l'architecture.
      • [^] # Re: La conclusion ...

        Posté par  . Évalué à 0.

        La dernière VM semble dans ses dernières versions tout à fait correcte sous Linux et même l'ancienne fonctionnait assez bien après tout.
        Les cas où la VM est vraiment soumise à un effort restent, avec les prix réduits de la Ram aujourd'hui, un peu plus rare :-)

        --
        Gilbou
        (gilbertf@posse-press.com)
        • [^] # Re: La conclusion ...

          Posté par  . Évalué à 4.

          C'est vrai que la RAM est de moins en moins chère mais la VM n'est pas que la gestion de la RAM, elle gère aussi les transferts vers le swap et donc des pages mémoire plus que de la RAM physiquement parlant. Enfin, au moins sur FreeBSD, je suis pas rentré dans le détail de la VM Linux.
          • [^] # Re: La conclusion ...

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

            Pour résumer ce que je disais juste avant (en Anonyme, satané login d'une journée !!!!!!!), La VM ce n'est pas que de la RAM. C'est d'ailleurs pour ça qu'elle est virtuelle ;-)
        • [^] # Re: La conclusion ...

          Posté par  . Évalué à 4.

          Il y avait un autre problème que la gestion de la RAM: le SWAP.
          D'après tout ce que j'ai pu lire, sous certaines conditions de stress les linux < 2.4.10 se mettaient à swapper comme des gorets pendant plusieurs minutes, ce qui mettait la machine complètement à genoux et inutilisable (voire la planait)
          En plus quand tu dois charger/décharger des pages, ça induit un certain temps de latence qui est assez important et qui joue sur les perfs de ta machine.
  • # Et bah voila!

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

    Tout ceci est bien rassurant quand même.

    L'introduction de la toute nouvelle VM ne pouvait pas se faire sans mal a mon avis. On ne fait pas d omelette sans casser des oeufs :)

    De tels changements auraient été plus judicieux dans la branche instable du noyau, cette fameuse branche 2.5 que Linus tarde a ouvrir...
    • [^] # Re: Et bah voila!

      Posté par  . Évalué à 8.

      Oui bof, le comparatif se deroule sur une base faussee.
      FreeBSD tourne avec un filesystem journalise, alors que linux tourne avec un ext2.
      Les resultats auraient ete valables si les deux avaient utilise le meme style de fs.

      De plus dans le cadre d'un serveur ext2 est loin d'etre la meilleure solution en terme de securite des donnees en cas de crash.

      M'enfin bon, moi ce que j'en dis ...
      • [^] # Re: Et bah voila!

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

        Parler de serveur en général ne veux pas dire grand chose.

        Sur un serveur web par exemple, où l'accès rapide aux fichiers est primordial, un ext2 peut être une bonne solution.
        Sur un serveur de fichiers où c'est la sécurité des données qui prime, alors un système journalisé sera préférable, comme ReiserFS, ext3, XFS, JFS, ...

        L'un des points forts de Linux, c'est justement de pouvoir adapter son système au plus près de ses exigences, comme le File System.

        Pour en revenir à la VM, la nouvelle est déjà meilleure (dans le sens performante) que celle présente dans les noyaux 2.2.x, ce qui justifie amplement son utilisation et son existence.
        • [^] # Re: Et bah voila!

          Posté par  . Évalué à 10.

          Sur un serveur web par exemple, où l'accès rapide aux fichiers est primordial, un ext2 peut être une bonne solution.
          Sur un serveur de fichiers où c'est la sécurité des données qui prime, alors un système journalisé sera préférable, comme ReiserFS, ext3, XFS, JFS, ...


          Peut-être un peu simpliste comme raisonnement, et généralement vrai, mais dans la pratique, si tu regarde les benchmarks de près, ce n'est plus tellement flagrant. voir http://www.namesys.com/benchmarks/mongo/2.4.8_vs_2.4.9_vs_2.4.10_ta(...)
          • [^] # Re: Et bah voila!

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

            Attention à ne pas déformer ou mal comprendre mes propos.

            D'abord, je n'ai pas dit que Reiserfs était moins rapide que ext2, toutes choses égales par ailleurs.

            Ensuite les tests comme celui que tu présentes ont un gros défaut, c'est qu'ils ne présentent qu'un aspect des choses, pour un type de travail particulier, et surtout dans un contexte spécifique.

            Maintenant, oui, bien sûr mon commentaire était simpliste, ce n'était pas une étude complète et détaillée sur les différents systèmes de fichiers sous Linux (et je serais bien incapable de le faire). C'était une réponse que je pense adaptée au commentaire précédent.
        • [^] # Re: Et bah voila!

          Posté par  . Évalué à 4.

          Sur un serveur de fichiers où c'est la sécurité des données qui prime, alors un système journalisé sera préférable

          Un système de fichier journalisé ne t'assure pas la sécurité des données, mais la sécurité de la table d'inodes.

          Il t'assure que tous les blocs du disque dur contenant des données sont répertoriés, et que tous les blocs répertoriés contiennent bien des données.

          Si le contenu est niqué, il est niqué, que ce soit avec un système de fichier journalisé ou non.

          Si tu veux une sécurité de tes données, il te faudrait un système de fichier transactionnel (ça existe, d'ailleurs ?)
      • [^] # Re: Et bah voila!

        Posté par  . Évalué à 2.

        Je ne crois pas, sauf bêtise de ma part, que le FFS soit effectivement journalisé. Ils emploient les dernières petites avancées comme le Soft Updates du vénérable docteur Kirk Mc Kusick mais il n'est pas journalisé, bien que dans une relative mesure les Soft Updates en soient proches en l'esprit.
        La journalisation n'est pas nécessaire, sauf si on n'est pas foutu de développer son FS correctement, selon quelques dévelopeurs ;-)
        Mais bon, chu pas un expert des FS donc je sais pas trop mais l'ext2 m'avait plu pour les quelques années où j'ai utilisé Linux. Quelqu'un a essayé le ext3 ? On m'a dit que c'était un ext2 avec des capacités de journalisation :-)

        --
        Gilbou
        (gilbertf@posse-press.com)
        • [^] # Re: Et bah voila!

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

          Attention, les SoftUpdates ne sont pas si récents que ça. Le SoftUpdates ne sont que la sauvegarde de méta-data ce qui permet de garder une table d'inodes propre mais pas le contenu des fichiers qui peut toujours être perdu.
    • [^] # Re: Et bah voila!

      Posté par  . Évalué à 10.

      Au niveau du premier comparatif, il ne faut pas oublier que le passage du pre-beta au noyau 2.4.0 a surtout été une barrière psychologique... le noyau 2.4.0 a été considéré comme suffisament stable pour entrer sur nos petits PC et faire avancer le schmilblick :), mais il était loin d'être parfait.
      C'est vrai que maintenant que la vm a été améliorée, c'est beaucoup mieux.

      Rappelons-nous ce jour heureux :

      Date : Thu, 4 Jan 2001 16 :01 :22 -0800 (PST)
      From : Linus Torvalds torvalds@transmeta.com
      To : Kernel Mailing List linux-kernel@vger.kernel.org
      Subject : And oh, btw..

      In a move unanimously hailed by the trade press and industry analysts as
      being a sure sign of incipient braindamage, Linus Torvalds (also known as
      the "father of Linux" or, more commonly, as "mush-for-brains") decided
      that enough is enough, and that things don't get better from having the
      same people test it over and over again. In short, 2.4.0 is out there.

      Anxiously awaited for the last too many months, 2.4.0 brings to the table
      many improvements, none of which come to mind to the exhausted release
      manager right now. "It's better", was the only printable quote. Pressed
      for details, Linus bared his teeth and hissed at reporters, most of which
      suddenly remembered that they'd rather cover "Home and Gardening" than the
      IT industry anyway.

      Anyway, have fun. And don't bother reporting any bugs for the next few
      days. I won't care anyway.

      Linus
  • # Euh...

    Posté par  . Évalué à 10.

    Je veux pas dire mais je ne vois pas en quoi ce comparatif a quoi que ce soit a voir avec la VM.

    Il est la question de stack reseau, de base de donnees,... ca fait tout un tas de parametres qui peuvent avoir un comportement different d'un OS a l'autre et fausser la comparaison.

    Selon moi ce comparatif ne signifie absolument rien au niveau VM mais plutot compare le comportement de plusieurs elements interagissant ensemble d'un point de vue global, on ne peut rien en tirer quand aux perfs des VM vu le nombre de parametres externes qui ont une incidence sur l'usage de la VM dans chaque cas.
    • [^] # Re: Euh...

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

      Evidemment Zindoz ca aide pas à faire les différences entre les organes d'un OS. D'ailleurs, tout ca est trop complexe : "ca fait tout un tas de parametres". On est-ce qu'on clicke ?
      Toujours est-il qu'il reste les performances intrinsèques d'un système face à une situation de tâches à accomplir, ce qui est le lot de la plupart des systèmes (même les jeux !).
      • [^] # Re: Euh...

        Posté par  . Évalué à -7.

        Bon le gamin(vu l'intelligence du post j'en deduis que tu en es un) tu evites de faire des allusions stupides a un sujet(Windows) qui n'a rien a faire ici svp, merci.

        <moment frime>
        Ensuite si tu veux te mesurer point de vue connaissances OS au debile qui sait pas faire la difference entre les organes d'un OS parce qu'il utilise 'Zindoz' c'est volontiers, mais tu risques fort de te sentir tres tres con apres et tu te rendras peut-etre compte qu'il y a pas besoin d'avoir un e-mail frenchhacker@xxx et utiliser Linux pour comprendre l'informatique
        </moment frime>
        • [^] # Re: Euh...

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

          Haha c'est qui le gamin ?
          Je suis tres fort au niveau OS nananinanèreeuuuuuhhh ;-) -> BillGates (ou pas).
          Viens y au niveau connaissances. J'en ai rien a foutre. Je suis meilleur que toi mais je n'ai pas ambition de le montrer.
        • [^] # Re: Euh...

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

          Waouh ! punaise tu sais ce que 'frimer' veux dire ;)
    • [^] # Re: Euh...

      Posté par  . Évalué à 8.

      En effet il y a beaucoup de paramètres qui entrent en ligne de compte dans ce test et la vm n'est que l'un d'entre eux.
      Cependant il me semble que la vm est le seul changement important depuis le 2.4.0 (si je me trompe c'est pas la peine de lire la suite), le fait que les résultat de linux soient plus prochent de ceux de freebsd peut donc se voir comme une stabilisation du noyaux dans son ensemble ou le fait que la nouvelle vm est meilleure (probablement les deux à la fois).
    • [^] # Re: Euh...

      Posté par  . Évalué à 3.

      D'autant plus qu'a aucun moment, il n'est donné d'information sur l'état de la mémoire : on sait combien de mail on peut envoyer par secondes avec sendmail mais on ne sait pas du tout comment réagit la mémoire. Tout ce qu'on sait c'est qu'il y'a 512 Mo de Ram dans l'ordinateur, mais il n'y a pas une seule sortie d'une commande liée a la mémoire (genre free)...

      Pour un benchmark de la VM c'est effectivement assez bizzare
    • [^] # Re: Euh...

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

      Dixit Moshe Bar :

      Because this benchmark is about VM and the other main subsystems...

      Cependant, entre le 2.4.0 et le 2.4.12, la VM est sans doute ce qui a le plus changé dans le noyau et la différence entre le deux tests le prouve.
      Le test est suffisament "stressant" pour que la VM soit l'élément limitant.

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

      • [^] # Re: Euh...

        Posté par  . Évalué à 9.

        Ben oui Moshe Bar a raison, mais le titre de la news est de travers lui.

        Sinon le test je maintiens que l'on ne peut rien en tirer niveau VM, exemple:

        - disons que la stack IP de Linux atteint une limite de perf au niveau X et pas freeBSD (pas de troll c'est juste imaginaire pour l'exemple)

        La VM du 2.4.0 etait pas assez bonne pour que la limite de la stack IP soit atteinte, le test montrait donc la limite de la VM

        Maintenant avec le 2.4.12 la VM peut theoriquement faire mieux mais est limitee par les perfs de la stack, resultat tu vois dans le comparatif une VM qui est X% plus rapide, alors qu'en fait elle est peut-etre X+10% plus rapide mais la stack IP t'empeche de le constater.
        • [^] # Re: Euh...

          Posté par  . Évalué à 5.

          effectivement, le seul truc qu'il a fait c'est abaisser la memoire disponible pour etre sur de stresser la VM. il ne donne pas suffisement de
          mesures pour que l'on voit si d'autres parametres sont venus limiter les perfs.
          il aurait fallu donner les courbes cpu/network/io/... sur les serveurs et sur les injecteurs pour en savoir plus.

          Je note quand meme autre chose de ce bench: le scheduleur de BSD m'est toujours apparu comme plus rapide que celui de linux. Dans ce test, on voit de nouveau que linux est plus lent pour creer et detruire des process... si je me souviens bien la tendance est inversée pour les threads (plus rapide sous linux). Peut etre le prochain bouleversement du kernel sera de travailler sur le scheduleur ?
    • [^] # Re: Euh...

      Posté par  . Évalué à 3.

      Il faudrait un 'bonnie' pour la VM
    • [^] # Re: eux... un test plus étendu ?

      Posté par  . Évalué à 3.

      un test sur deux machines identiques avec des version de VM différentes (noyaux différents ?) aurait dû être ajouté pour montrer les évolutions en terme de performance de la VM
    • [^] # Re: Euh...

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

      Tout à fait, le titre de la news induit en erreur. C'est un comparatif freebsd/linux, bien classique, avec un linux qui gagne des fois et un freebsd qui gagne les autres fois.

      s/ des VM// dans le titre...
  • # Quelques remarques

    Posté par  . Évalué à 2.

    Je ne met aucunement en doute le comparatif propose, bien qu'il ne soit pas specifiquement porte sur les performances de la VM des 2 OS.
    Bien que la VM de linux aille mieux depuis le kernel 2.4.10, on peut quammeme pas dire qu'elle soit utilisable sur un serveur de production ! Et pas nonplus la comparer a celle de FreeBSD!

    Je m'explique: ces tests (bien que je pense que des benchmarks me pousseront jamais a utiliser un OS plutot qu'un autre) sont peut etre interessants pour certains, pour comparer en gros les performances des 2 OS dans des domaines precis. Mais ils n'ont rien a voir avec la VM, et en particulier a ce qui est reproche a la VM de linux, en cas de swapage intense, au moment ou le systeme n'a plus beaucoup de swap libre. Selon ma propre experience, meme si l'approche de Rik Van Riel avait tendance a prendre 100% du CPU pour rechercher les process a killer au moment critique pendant un _tres_ long moment. L'approche de Andrea Arcangelli n'est pas nonplus
    la panace. Et si mon systeme, avec cette nouvelle VM, met moins longtemps a se debarrasser des process trop gourmands, il n'en est pas moins completement indisponible pendant un _long_ moment pendant ces moments critiques. Alors que sous FreeBSD, le systeme reste quammeme disponible, et met beaucoup moins longtemps a killer les process incrimines dans la penurie de memoire.

    D'ailleurs, aux dires d'un des developpeurs de FreeBSD, l'approche de Rik Van Riel etait la bonne, mais elle aurait pris beaucoup de temps avant de se stabiliser, d'ou l'interet d'avoir une VM stable dans un kernel stable, et d'attendre le 2.5.
    • [^] # Re: Quelques remarques

      Posté par  . Évalué à 0.

      > D'ailleurs, aux dires d'un des developpeurs de FreeBSD...

      Ah bon, d'ou tu tires tes sources ???


      Moi je trouve cela plutot encourageant pour la nouvelle VM. Elle est depuis tres peu de temps en place et fonctionne a priori tres correctement. Et il y aura peut etre encore un peu de place pour quelques ameliorations dans de prochaines versions.
      • [^] # Re: Quelques remarques

        Posté par  . Évalué à 4.

        de cette interview de Matt Dillon, qui est un des auteurs du code actuel de la VM de FreeBSD :

        http://www.osnews.com/story.php?news_id=153(...)

        le passage suivant :

        7. From the technical point of view, how would you rate the Linux 2.4 kernel compared to BSD's?

        Matt Dillon: I don't know enough about recent linux kernels to be able to rate them, nor would it be P.C. I do follow the VM work being done in Linux and in particular Rik van Riel's work. I think Linux is going through a somewhat painful transition as it moves away from a Wild-West/Darwinist development methodology into something a bit more thoughtful. I will admit to wanting to take a clue-bat to some of the people arguing against Rik's VM work who simply do not understand the difference between optimizing a few nanoseconds out of a routine that is rarely called verses spending a few extra cpu cycles to choose the best pages to recycle in order to avoid disk I/O that would cost tens of millions of cpu cycles later on. It is an attitude I had when I was maybe 16 years old... that every clock cycle matters no matter how its spent. Bull!


        sinon par rapport a ton post, je pense que le meilleur moyen d'encourrager quelquechose, c'est d'etre realiste et pragmatique a son egard, et de ne ne jamais s'eloigner des faits et de la realite.
        • [^] # Re: Quelques remarques

          Posté par  . Évalué à 1.

          J'aime bien la référence au développement Wild-West/Darwiniste.
          C'est pas tout à fait faux en fait, mais je pense que c'est une caractéristique du développement collaboratif massif (i.e. avec tout plein de gens) sans réel "coaching" ou sans réels objectifs prédéfinis....

Suivre le flux des commentaires

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