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 Jaimé Ragnagna (site web personnel) . Évalué à 7.
trad : "En fait, j'aime les deux"
Voila, je crois que tout est dit ...
Mouarf !
[^] # Re: La conclusion ...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
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 Anonyme . Évalué à 0.
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 Anonyme . Évalué à 4.
[^] # Re: La conclusion ...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: La conclusion ...
Posté par kalahann . Évalué à 4.
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 Guillaume Plessis (site web personnel) . Évalué à 10.
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 Anonyme . Évalué à 8.
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 G. R. (site web personnel) . É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, ...
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 fantomaxe . Évalué à 10.
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 G. R. (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 4.
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 Anonyme . Évalué à 2.
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 Blackknight (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Et bah voila!
Posté par fantomaxe . Évalué à 10.
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 pasBill pasGates . Évalué à 10.
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 VACHOR (site web personnel) . Évalué à -6.
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 pasBill pasGates . Évalué à -7.
<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 VACHOR (site web personnel) . Évalué à -8.
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 Yohann (site web personnel) . Évalué à -1.
Simple curiosite...
[^] # Re: Euh...
Posté par VACHOR (site web personnel) . Évalué à -3.
J'aurais du mettre des balises ? ;-)
[^] # Re: Euh...
Posté par Yohann (site web personnel) . Évalué à -3.
[^] # Re: Euh...
Posté par wismerhill . Évalué à 8.
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 Anonyme . Évalué à 3.
Pour un benchmark de la VM c'est effectivement assez bizzare
[^] # Re: Euh...
Posté par Robert Palmer (site web personnel) . Évalué à 7.
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 pasBill pasGates . Évalué à 9.
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 PLuG . Évalué à 5.
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 Anonyme . Évalué à 3.
[^] # Re: eux... un test plus étendu ?
Posté par concoillotte . Évalué à 3.
[^] # Re: Euh...
Posté par Annah C. Hue (site web personnel) . Évalué à 3.
s/ des VM// dans le titre...
# Quelques remarques
Posté par Anonyme . Évalué à 2.
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 Anonyme . Évalué à 0.
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 Anonyme . Évalué à 4.
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 Anonyme . Évalué à 1.
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.