URL: https://linuxfr.org/users/patrick_g/journaux/bfs-la-revanche Title: BFS : La revanche Authors: patrick_g Date: 2009年09月07日T17:52:45+02:00 Tags: bfs et lwn Score: 32 Après [le journal](http://linuxfr.org/~tankey/28731.html) de Tankey sur BFS voici la suite de la saga. Pour ceux qui ont raté l'épisode précédent : Con Kolivas a posté un patch pour le noyau Linux qui remplace le l'ordonnanceur de processus [CFS](http://en.wikipedia.org/wiki/Completely_Fair_Scheduler) (Completely Fair Scheduler) par le sien (BFS pour "Brain Fuck Scheduler"). Le code de CFS a été écrit en grande partie par Ingo Molnar et Con critique ce design en soutenant qu'il ne vise que les machines très puissantes et qu'il n'est pas adapté aux petites machines et à la minimisation des temps de latence d'une utilisation de bureau classique. Ingo a donc testé BFS pour le comparer à son bébé et il a posté le résultat sur la LKML : [http://thread.gmane.org/gmane.linux.kernel/886319](http://thread.gmane.org/gmane.linux.kernel/886319) On peut noter le ton courtois d'Ingo qui salue le retour de Con : "_First and foremost, let me say that i'm happy that you are hacking the Linux scheduler again_". Il souligne également l'intérêt du code de Con : "_BFS is an interesting and bold new approach, cutting a _lot_ of code out of kernel/sched*.c, so it raised my curiosity and interest_". Ingo passe ensuite aux tests sur une machine dual quad-core avec hyperthreading (une machine qui est donc vue comme ayant 16 coeurs par l'OS). Il configure sa machine exactement comme Con a recommandé de le faire (HZ=1000) et il invite les gens a faire aussi les tests pour se rendre compte par eux-même. Vous pouvez aller [lire en détail les résultats](http://thread.gmane.org/gmane.linux.kernel/886319) mais si on veut faire court on va dire que BFS se fait éclater sur tous les tests. Con Kolivas a répondu sur un ton beaucoup moins courtois en qualifiant le travail d'Ingo de : "_bullshit meaningless benchmarks (...) Do you know what a normal desktop PC looks like? No_". Les commentaires de [l'article LWN](http://lwn.net/Articles/351058/) prennent acte du fait qu'Ingo a bossé et a produit des chiffres alors que Con ne présente aucun chiffre pour soutenir la supériorité technique de BFS. le ton agressif et dédaigneux de Con a aussi fait lever pas mal de sourcils. Toutefois Con a bien spécifié que BFS n'était pas fait pour les superordinateurs et que sa limite était d'environ 16 coeurs et donc le choix de la machine de test d'Ingo a été critiqué. Elle a été jugé comme trop puissante et pas représentative par les supporteurs de Con. Pas chien Ingo a refait tous les tests avec un simple quad-core...et les résultats sont presque les mêmes. CFS [éclate largement](http://people.redhat.com/mingo/misc/bfs-vs-tip-pipe-quad.jpg) BFS. Juste un extrait : Test du dual quad-core hyperthread : BFS: Pipe latency: 4.9703 microseconds sched-devel: Pipe latency: 2.6137 microseconds [90.1% faster] Test du quad-core BFS: Pipe latency: 4.6978 microseconds sched-devel: Pipe latency: 2.6860 microseconds [74.8% faster] La critique a ensuite porté sur les tests choisis par Ingo qui ne seraient pas représentatifs de la "sensation" de fluidité et de réduction de la latence qu'apporterai BFS. C'est sûr que c'est dur de mesurer une "sensation" mais le test pipe d'Ingo semble pourtant taillé pour refléter les performances de latence de la machine (Deux processus qui s'attendent l'un l'autre en alternance). Au bilan ? Ben c'est un journal donc je donne mon opinion franche et claire: Comme d'habitude Ingo travaille dur et il soutient ses affirmations par des benchmarks et des chiffres. Quand il lit une critique il essaye d'y répondre (le nouveau test qu'il a refait entièrement avec un quad-core). Il reste également courtois tout au long de la discussion. Du coté de Con Kolivas on a un soft dont on nous dit qu'il est bien meilleur que le scheduler de la branche principale...mais cette affirmation n'est pas étayée par des chiffres. Quand les développeurs essayent de discuter et d'argumenter rationnellement avec lui, Con se braque et refuse le dialogue ("_I'm not interested in a long protracted discussion about this since I'm too busy to live linux the way full time developers do_"). Il ne répond absolument pas aux arguments techniques et se contente de dire que les benchs ne peuvent pas mesurer la "sensation" de fluidité qu'apporte BFS ("_demonstrating yet again why benchmarks fail the desktop_"). Pour moi le comportement de Con Kolivas c'est la définition même d'un troll.