Linus a commencé l'inclusion des modifications de Andrew Morton (patches mm, partie "non-blocking page writeback system") apportées sur la gestion de la mémoire virtuelle dans son arbre BK du noyau de développement 2.5.39.
Les buts de ces améliorations sont d'améliorer le comportement du noyau au niveau des entrées/sorties vis à vis de la montée en charge.
Au vu des gains de performance, c'est à ce demander comment on a put vivre sans! (à voir dans le fichier attaché) *******************************************************
Example: with `mem=512m', running 4 instances of
`dbench 100', 2.5.34 took 35 minutes to compile a kernel.
With this patch, it took three minutes, 45 seconds.
*******************************************************
*******************************************************
This code can keep sixty spindles saturated - we've never
been able to do that before.
*******************************************************
Another significant akpm mm patch which should get merged soon: read-latency.patch
*******************************************************
On IDE it provides a 100x improvement in read throughput
when there is heavy writeback happening. 40x on SCSI.
*******************************************************
... which is important because ...
*******************************************************
This problem has become much more severe lately because the
VM is now capable of keeping the write queue full all the
time, without stumbling over its own feet. (In fact it can
keep 10 queues saturated, and most likely 100).
*******************************************************
Con Kolivas posted updated contest results for 2.5.38-mm2, and the results look good:
From: Con Kolivas
To: linux-kernel
Subject: [BENCHMARK] 2.5.38-mm2 contest results
Date: Mon, 23 Sep 2002 17:24:14 +1000
Here follow the contest benchmarks for 2.5.38-mm2
NoLoad:
Kernel Time CPU
2.4.19 66.56 99%
2.5.38 68.25 99%
2.5.38-mm1 67.17 99%
2.5.38-mm2 67.48 99%
Process Load:
Kernel Time CPU
2.4.19 81.29 80%
2.5.38 71.60 95%
2.5.38-mm1 70.49 95%
2.5.38-mm2 70.82 95%
IO Half Load:
Kernel Time CPU
2.4.19 101.39 69%
2.5.38 81.26 90%
2.5.38-mm1 82.52 87%
2.5.38-mm2 78.46 91%
IO Full Load:
Kernel Time CPU
2.4.19 170.70 41%
2.5.38 170.21 42%
2.5.38-mm1 434.41 16%
2.5.38-mm2 108.15 66%
Mem Load:
Kernel Time CPU
2.4.19 93.33 77%
2.5.38 104.22 70%
2.5.38-mm1 92.97 77%
2.5.38-mm2 90.89 80%
As akpm has said, mm2 should fix the write starves read problem in mm2 and this
is clearly shown in the IO full load results being substantially better.
This is on an IDE system.
Other results removed for clarity. All tests are done with gcc2.95.3 :
Con.
Aller plus loin
- Les patches de la série -mm : (3 clics)
- La news sur Kerneltrap.org : (2 clics)
# Ben dis donc !
Posté par Stéphane Del Pino . Évalué à 10.
En effet, l'autre jour, grâce au mega patch de l'ordonnanceur, on passait de 15 mn à 2 secondes, soit un facteur 450 (pour un test pas très réaliste c'est vrai). Aujourd'hui on gagne un facteur 100, notament pour les accès disque, ma question est donc la suivante, est-ce que les gars d'avant programmaient avec leur pied ? Et plus encore, si dans ces conditions Linux rivalisait (voire battait) MS-Windows en performance, que penser alors des gars de Redmond ?
Et en pratique, ça donne quoi ?
[^] # Re: Ben dis donc !
Posté par zeDek . Évalué à 10.
Le but de MS c'est de vendre du logiciel. Il faut que ça marche quelqu'en soit la qualité (cf les alertes de sécu, les SP, etc...)
Les programmeurs du noyau Linux eux le font pour le plaisir, c'est un hobby et rares sont ceux qui vivent de ça (malheureusement).
Cela étant dit, je pense que l'arrivée du 2.6 dans nos chaumières risquent d'avoir des répercussions non négligeables pour MS. Ca va faire l'effet d'une bombe et nul doute qu'après ça, nombre d'utilisateurs du Mal(tm) risquent de rejoindre le côté du Bien(tm). Je suis curieux de voir comment va réagir la firme de Redmond dans cette situation.
est-ce que les gars d'avant programmaient avec leur pied ?
Je ne pense pas qu'ils programment avec les pieds car même sans avoir les performances qu'il aura avec le 2.6, le kernel Linux est unanimement reconnu pour sa robustesse et sa stabilité. Chez MS ça fait plus de 20ans qu'ils essaient de faire quelque chose qui marche et AMA ils sont pas prêts d'y arriver. Pendant que chez MS on s'empresse de crée de nouveau protocole proprio et qu'on intègre de plus en plus de chose (palladium, etc..), dans l'OpenSource on consolide/améliore l'éxistant.
C'est AMHA la solution la plus réaliste et la plus sage.
[^] # Re: Ben dis donc !
Posté par Beretta_Vexee . Évalué à 10.
Le but premier de Microsoft c'est de vendre de licences, et dans ce domaine ils sont trés fort ( bien plus que dans la conception de logiciel ), que ce soit .NET, le futur Palladium et autre, la politique de MS n'est orienté que par ca. Méme si demain les solutions libre plus perfomante et trés peux couteusent a mettre en place apparaissent il n'y aura personne pour rivaliser point de vue marketing et promotion avec MS, la force de Microsoft c'est qu'elle ne vous vend pas un OS ou une suite bureautique, mais elle vous vend du Microsoft, la situation en est a un point ou beaucoup de petite entreprise sont préte a changé des softs qui marche(tm) pour du .NET en devenir uniquemant parce qu'elles sont travailliés au corps par les marketteux, donc non MS n'a pour le moment pas grand chose a craindre du Kernel linux en lui méme, ce qu'elle craint plus c'est l'interoperabilitée MS/Linux/* et dans un futur proche l'arrivée de solution grand publique pour le desktop et la bureautique et les PME.
Du moment que ces trois conditions ne sont pas remplie MS a assez peut de chose a craindre, sans interoperabilitée compléte/parfaite il sera toujours plus simple et moin couteux d'opter pour des solutions tous MS pour une PME ( pas d'admins ou techno a double competence, qui sont plus chers etc etc ), méme pour de petits serveurs. Donc si le kernel fait des étincelles c'est plus le marché des gros et moyen serveur qui sera touché, marché qui n'est pas escentiel pour MS et sur le quel linux fait reculer les unix proprio plus que Microsoft.
est-ce que les gars d'avant programmaient avec leur pied ?
Nop, mais il faut quand méme savoir que l'ordonnanceur et la mémoire virtuel sont les parties plus difficile d'un OS, et que contrairemant au croyance tous n'a pas déjà été fais des ces domaines, la preuve en est.
Je sais pas ce que vous en pencez mais je trouvais que le passage du 2.2 au 2.4 hors mit Netfilter et le support de l'USB n'apportait pas un grand changemant niveau perfs, alors que le 2.6 s'annonce beaucoup plus ambitieu que ne l'etait le 2.4 n'est pas un mal ( preempt, mm, alsa, etc ... ).
[^] # Re: Ben dis donc !
Posté par Jacolin Robert . Évalué à 7.
Ils existent des entreprises qui vendent des services à base de logiciels libres. Ca avance moins vite que si ces entreprises-là auraient un marketing comme celui de Microsoft, mais ca avance.
[^] # Re: Ben dis donc !
Posté par franck villaume (site web personnel) . Évalué à 10.
Voici mon expérience personnelle :
j'ai la même machine depuis trois ans. Je fais les mêmes choses avec depuis trois ans. En trois ans, ses performances se sont améliorées. Et pourtant je n'ai pas changé le hardware.
Les gens avant ne programmaient pas avec leur pied, loin de là. Aujourd'hui ils peaufinent les programmes. Ils réécrivent les parties lourdes.
Bref, les programmes sont de plus en plus performants (kernel, XFree, etc... ) et cela pour mon plus grand plaisir.
</mavie>
[^] # Re: Ben dis donc !
Posté par Stéphane Del Pino . Évalué à 10.
Je n'ai pas dit que Linux n'était pas performant. Je n'ai pas dit non plus qu'il n'était pas normal qu'il gagne en performance au vue des optimisations.
Ma remarque porte simplement sur le fait qu'on parle de facteurs de l'ordre de 100 !
Je ne sais pas si je suis le seul, mais pour moi, 100 c'est beaucoup : pensez à un grand nombre comme 70, et bien 100 c'est beaucoup plus !!!
[^] # Re: Ben dis donc !
Posté par zeDek . Évalué à 8.
[^] # Re: Ben dis donc !
Posté par kesako . Évalué à 10.
Le genre de choses qu'on met de coté au debut d'un developement pour se concentrer sur la stabilité et la fiabilité en fonctionnement normal.
Pour une machine pas trop chargee, avec suffisament de memoire ca ne change pas grand chose.
Perso,j'ai parfois eu des gains x100 dans les perfs de cgi , mais le cgi "lent" etait deja en production et remplissait correctement son role.
[^] # Re: Ben dis donc !
Posté par Simon_N . Évalué à 10.
Et pour l'utilisateur moyen qui n'en retire pas de bénéfice direct (à part de pouvoir se vanter d'utiliser un OS allant 100 fois plus vite qu'hier, ce qui ne veut rien dire), on en retirera de bonnes choses. Je pense par exemple aux serveurs d'applications J2EE et aux BD, ces gros monstres qui utilisent énormément de threads et de mémoire... Ils tourneront probablement bien mieux. Et donc les entreprises continueront à aider les développements autour de "Linux", ce qui aura sûrement un impact positif même sur nos applis de tous les jours.
Donc ce sont de bonnes nouvelles.
[^] # Re: Ben dis donc !
Posté par Vanhu . Évalué à 10.
Imagines une fonctionnalité importante à implémenter.
Tu as 3 facons de faire:
- une rapide à mettre en oeuvre, assez propre, assez fiable, mais pas super performante
- une très rapide à mettre en oeuvre, qui est super performante, mais super crade, sujette aux bugs d'implémentation (parceque super crade) et difficile à maintenir (parceque super crade).
- une très optimisée, d'une beauté conceptuelle à te faire chialer, générique, modulaire, réutilisable...... mais que tu vas mettre 2 ans pour en pondre une version béta, et que pendant ce temps, faut surtout pas toucher à quoiquecesoit qui a vaguement un rapport.....
Ben le mieux amha, c'est d'implémenter la première, et de prévoir que "plus tard", tu la remplaceras par la 3eme....
A +
VANHU.
[^] # Re: Ben dis donc !
Posté par _seb_ . Évalué à 6.
Ensuite, il faut espèrer que ce patch ne déborde pas sur la stabilité. Si mon ordinateur va 100x plus vite qu'avant mais qu'il plante aussi 100x plus, je ne vois pas trop l'utilité. Cependant, la stabilité et la robustesse du noyau est l'une des priorités dans le developpement de Linux.
Ces patches montrent qu'en terme de recherche en informatique, on est loin d'avoir tout vu. Et que finalement, les C# & co ne font que réinventer la roue.
[^] # Re: Ben dis donc !
Posté par Fabimaru (site web personnel) . Évalué à -2.
-1
[^] # Re: Ben dis donc !
Posté par Alan_T . Évalué à 10.
La qualité du code transparait sur la stabilité et le nombre de bugs. Après tout, un programmeur ne fait qu'implémenter un algorithme. Il se trouve que les dernières avancées du kernel sont algorithmiques. De nouveaux algorithmes sont testés et marchent avec plus ou moins de succès.
L'implémentation, elle, reste toujours de la même qualité (je pense). Il est d'ailleurs très intéressant de noter que le grand nombre d'améliorations sur le noyau Linux est la conséquence directe du fait que Linux est Open-Source ! En effet, Linux est une sorte de "laboratoire" pour informaticiens qui peuvent tester leurs idées. Des fois bonnes, des fois mauvaises. Mais la plupart du temps, Linus filtre celles qui sont bonnes de celles qui sont mauvaises (excepté pour les problèmes avec la mémoire virtuelle).
Au passage, on peut remarquer que bon nombre de ces innovation viennent directement d'idées piochées chez les universitaires en 'computer science' ou en mathématiques.
Par exemple pour le cas du scheduler, son inventeur a fait des études en math:
http://kerneltrap.com/node.php?id=336(...)
Bref, ces dernières 'accélérations' est le fait de nouveaux algorithmes ou méthodes et comme l'a dit justement quelqu'un d'autre sur le forum, tout n'a pas encore été exploré... :-)
Il est d'ailleurs amusant de repenser à ce qu'avait dit Microsoft à un moment, les porte-paroles de cette firme prétendaient que l'Open-Source tuait l'innovation (à mon humble avis, c'est plutôt le contraire).
http://people.redhat.com/drepper/(...)
[^] # Re: Ben dis donc !
Posté par Ramon Maceiras . Évalué à 2.
# Allez, je bascule !
Posté par Christophe Merlet (site web personnel) . Évalué à 8.
Sans dépenser un centime, ma machine va aller 100 fois plus vite !! :-)
[^] # Re: Allez, je bascule !
Posté par zeb . Évalué à 10.
[^] # Re: Allez, je bascule !
Posté par Gaël Le Mignot . Évalué à 10.
1/ Le facteur 100 dont ils parlent, c'est par rapport au pacth -mm1 qui dans certains cas créait des congestions, pas par rapport au noyau 2.4...
2/ Le gain n'est visible qu'à très haute charge
3/ Il faut toujours se méfier des benchmarks, on peut faire dire ce qu'on veut à un benchmark... En particulier, dbench, est très spécifique...
Alors, oui, c'est bien, mais relativisons et essayons de comprendre au lieu de crier des chiffres comme ça...
# but des développements
Posté par mickabouille . Évalué à 5.
[^] # Re: but des développements
Posté par Julien Danjou (site web personnel) . Évalué à 9.
[^] # Re: but des développements
Posté par zeDek . Évalué à 10.
Donc il n'y a vraiment pas à polémiquer la dessus. Ils avaient leur roadmap et ils l'appliquent pour moi il n'y a rien de surprenant à cela.
[^] # Re: but des développements
Posté par PLuG . Évalué à 10.
Les developpeurs du noyau sont concentrés sur les problèmes sexy: faire tourner le noyau dans les moments difficiles.
Mais on se retrouve de plus en plus avec un noyau parametré aux petits oignons pour ces profils de serveurs et de plus en plus loins des petites machines.
Un exemple ?
Le noyau 2.4 consomme plus de swap, ce qui sur une machine avec un disque LENT n'est pas du tout une bonne idée.
le nouveau scheduleur en O(1) qui a défrayé la chronique est peut etre plus lent dans le cas général ? en tout cas il consomme surement des structures de data (hash ...) pour y arriver et donc plus de RAM ... bref c'est clair: ton P133 64Mo RAM gagne surement a tourner sur un bon vieux 2.2.x
Mais d'un autre coté, il faut bien évoluer. Et laisser tous les choix dans le kernel/config n'est pas faisable... et puis je fait tourner pas mal de config serveurs qui en profitent pleinement ...
[^] # Re: but des développements
Posté par Gaël Le Mignot . Évalué à 10.
Quel noyau 2.4 ? La VM (gestion de la mémoire) du 2.4 a été complètement modifiée avec le 2.4.10. Il y a 3 VMs pour le 2.4:
* la VM de rik originale (2.4.0=>2.4.9)
* la VM d'Andrea (2.4.10=>2.4.20pre...)
* la VM -rmap (-ac récents, -mjc)
Pour chacune, il y en a plusieurs variantes. Donc parler du "noyau 2.4" en ce qui concerne la gestion de la mémoire, ça n'a pas beaucoup de sens.
La VM -rmap, en théorie tout du moins, permet de choisir plus vite et plus précisément quelle page "virer" de la mémoire lorsqu'il est nécessaire de swapper, et profite donc plus aux machines qui ont en besoin. De plus, elle permet de trouver plus facilement des pages dans une zone donnée de la mémoire (comme une page dans les 16M pour le DMA des cartes ISA, et la encore, ce sont les vieilles machines qui en profitent).
[^] # Re: but des développements
Posté par PLuG . Évalué à 6.
c'est la VM d'Andrea, pour laquelle tu es prié de filer au moins 2x la quantite de RAM sinon pas sur qu'il puisse swapper les pages comme il veut, alors qu'avant c'etait pas le cas (kernel 2.2)
que je sache cette particularité n'as pas changée du 2.4.0 au 2.4.20 ...
en pratique, je fais tourner des machines qui ne respectent pas cette loi. Mais elles sont clairement hors spec.
en pratique aussi, en passant d'un 2.2 a un 2.4 on remarque effectivement plus de consommation du swap. Le but est de swapper plus tot pour se premunir d'une carence grave de RAM ... c'est une bonne idée pour un serveur. Pour un portable qui ne lancera plus rien d'autre que mozilla+X11 c'est pas forcement optimal (vaudrait mieux consommer a 100% la RAM et ne pas swapper sur le disque lent).
bon on peut tuner tout ca dans /proc/sys pour essayer de retrouver un comportement plus proche du 2.2 mais c'est pas encore tout a fait ca.
bref je me repete, c'est l'évolution et elle est souhaitable. de toutes facons les P133 ca disparait de la nature, il est devenu facile de récuperer des PII pour faire des firewalls a la maison ... et ce sera de plus en plus comme ca (il fut un temps ou on recuperait des 486DX33 pour faire des routeurs ...).
[^] # N'importe quoi!!!!!
Posté par oliv . Évalué à 10.
Complètement faux!!!!
je dois te rafraîchir la mémoire avec quelques liens:
http://old.lwn.net/2001/0607/kernel.php3(...)
A cette date, le kernel est le 2.4.5
"About that swapping problem. Problems with the use of swap space in 2.4.x were also mentioned last week. The amount of complaining has gone up recently, as more people try out the 2.4.5 kernel, which appears to be worse.
The response from the kernel hackers so far has been "make sure your swap area is at least twice as large as the amount of RAM in the system." That allows the kernel, essentially, to waste half of the swap space as a copy of what is currently in RAM, and actually swap to the other half. That technique helps, but a number of people are, not surprisingly, unimpressed with that requirement. 2.2 systems seemed to work better, after all. In fact, 2.2 had the same problem with swapping, but the more aggressive approach to caching in 2.4 has made the problem bite a lot more people."
Et cette série d'emails sur la liste de diffusion du Kernel:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.0/0556.html(...)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.0/0482.html(...)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.0/0458.html(...)
Où tu apprendras que la limite qui était dans la VM de rik a été levée avec le 2.4.8
Je sais pas si le plus ennuyeux, c'est de lire de telles bévues, ou bien de voir que ce genre de mail est scoré + !
[^] # Re: N'importe quoi!!!!!
Posté par PLuG . Évalué à -3.
quelques hints:
-je dis bien que ca marche si on ne respecte pas le x2
-je dis bien que le 2.4 swap plus tot que le 2.2 pour garder du mou
-je dis bien que tout ca est reglable dans /proc/sys
bon je veux bien que tu défendes ton OS préféré bec et ongles, MAIS LIS LES MESSAGES AVANT DE REPONDRE.
[^] # Re: but des développements
Posté par Guillaume POIRIER . Évalué à 3.
Cela dit, je ne peux pas empêcher de penser que si le noyau tourne super bien sur un gros système chargé, logiquement, il devrait aussi très bien tourner sur ton P133 "hors d'âge". Après tout, qu'est-ce qui les différencie dans les configurations où tous deux sont à pédaler dans la choucroute?
Bon, maintenant, il est évident que les nouveaux algos déployés, ainsi que les nouvelles structures de données du noyau doivent tout de même avoir un "coût forfaitaire" plus important. Un exemple pourrait être de classer certaines structures de données du noyau dans un arbre là où il n'y avait qu'une liste chaînée (que les experts me pardonnent si je dis une grosse connerie, je n'ai encore pas en de cours algorithmique).
Tout ça pour dire, que tu devrais tout de même essayer le nouveau noyau quand il sera plus stable, car tu risquerais bien d'être agréablement surpris (c'est pas pour les euros que ça coûte!!!).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.