Journal BFS : le retour de la revanche

Posté par  .
Étiquettes : aucune
13
14
sept.
2009
Résumé des épisodes précédents : la guerre est déclarée entre l'Empire du Completely Fair Scheduler et les rebelles du Brai Fuck Scheduler.
Lire http://linuxfr.org/~patrick_g/28745.html pour un résumé complet.

Ingo Molnar a publié un comparatif très flatteur pour BFS, mais qui tombait totalement à plat car fait sur sur bête de course : http://thread.gmane.org/gmane.linux.kernel/886319

Cette fois-ci, Phoronix effectue ses tests sur une machine "desktop" beaucoup plus modeste (un Atom bi-coeur à 2Ghz) : http://www.phoronix.com/scan.php?page=article&item=bfs_sched(...)

Le comparatif est sans appel : aucune différence de vitesse pour un usage desktop (étonnamment par contre, pour faire du Apache BFS semble nettement plus rapide).

Fin de l'histoire ?

  • # Perf Apache

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

    Si le gain de performance avec apache est avéré, BFS a toute sa légitimité pour exister, même si son usage est cantonné aux serveurs web. Car avec 65% de gain en terme de requêtes par secondes et vu le nombre de serveurs web sous Linux, ce serait dommage de laisser BFS mourir sans chercher à connaître la raison d'une telle différence de performances.

    Donc pour moi ce n'est pas la fin de l'histoire loin de là, c'est ce que j'appelle un rebondissement (/me va chercher le pop-corn).

    • [^] # Re: Perf Apache

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

      Il faut voir aussi que le CFS en dev est différent de celui dans le kernel actuel.

      Pour clouer le bac, il faudrait un test qui mesure la réactivité à un stimuli. Il s'agit de mesurer le temps qu'il faut entre un clic de souris et la réponse sous différente type de charge.

      "La première sécurité est la liberté"

  • # correction...

    Posté par  . Évalué à 10.

    Ingo Molnar a publié un comparatif pas très flatteur pour BFS

  • # bench

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

    en même temps que mesurent ces benchs ? des temps de compiles, des nombre de quequettes par seconde, des temps d'encodage etc.
    BFS n'est pas là pour gagner 0.01 seconde sur une compile du kernel, il est là pour améliorer l'experience utilisateur, aucun des benchs de phoronix ne mesurent quoique ce soit par rapport à ça

    • [^] # Benchmarker la rapidité ressentie

      Posté par  . Évalué à 5.

      Est-ce qu'il existe des protocoles de mesure de la rapidité ressentie par l'utilisateur ?

      Je me souvient d'avoir été médusé au début des années 2000 après avoir lu des benchmarks entre BeOS et Linux : l'écart de rapidité ressentie était exactement l'inverse des performances mesurées.
      Pourtant, j'échangerai bien deux barils d'OS rapide mais peu réactif contre un tout petit bidon d'OS ultra-réactif.

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Benchmarker la rapidité ressentie

        Posté par  . Évalué à 6.

        > Est-ce qu'il existe des protocoles de mesure de la rapidité ressentie par l'utilisateur ?

        A la grande époque du kernel "-ck", Con Kolivas avait développé Interbench, un bench de simulation d'interactivité, pour essayer de mettre des nombres en face de ce "ressenti utilisateur". Difficile d'évaluer sa pertinence dans l'absolu, mais c'était au moins un bon indicateur pour comparer des scheduleurs et détecter les éventuelles régressions qui les affectaient d'une version à l'autre.

        http://users.on.net/~ckolivas/interbench/

        • [^] # Re: Benchmarker la rapidité ressentie

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

          Effectivement Con avait développé Interbench spécifiquement pour mesurer l'interactivité. On peut donc penser que, vu par Con Kolivas du moins, ce bench est pertinent pour évaluer BFS par rapport à CFS.

          L'emmerde c'est que les résultats d'Interbench montrent un résultat sans appel : CFS est meilleur (moins de latence que BFS) !!!!

          Voir ici : http://marc.info/?l=linux-kernel&m=125240476527775&w(...)

          • [^] # Re: Benchmarker la rapidité ressentie

            Posté par  . Évalué à 1.

            Et pourquoi ne pas mesurer ce que voit directement l'utilisateur?
            C'est à dire utiliser des caméras ultra-rapide pour constater en réel, de visu, le nombre de milli-secondes/secondes pour que le système effectue telle ou telle opération?

      • [^] # Re: Benchmarker la rapidité ressentieIl

        Posté par  . Évalué à 1.

        Il existe des méthodes pour mesurer le temps de réponse d'une application.

        Pour un serveur web, c'est encore assez facile : tu mesures le temps entre le moment où la requête entre et le moment où la page complète est renvoyée. Avec ça, tu peux calculer des moyennes, écarts-types, temps de réponse maximal, etc... et tu peux facilement optimiser (par exemple en faisant la même chose pour chaque sous-système, par ex. la BDD).

        J'ai entendu dire qu'un système d'exploitation pour serveurs d'IBM, z/OS, fait ce genre de mesures en standard pour toutes les applications, et qu'ils arrivaient à avoir des systèmes réactifs, même avec une charge supérieure à 90%. Ils ont une construction spéciale nommée "enclave", qui permet de suivre et mesurer une transaction à travers toutes les applications qu'elle utilise.
        L'inconvénient de la méthode, c'est que ça consomme pas mal de CPU et de mémoire, car rien n'est gratuit.

        Pour une application bureau (desktop), c'est plus difficile. Tu as plusieurs couches qui interagissent de manière non synchronisée : souris, noyau, application, serveur X, GUI. La réactivité ressentie peut être très mauvaise, alors que le système est dans son ensemble assez rapide, pour peu qu'un des divers sous-systèmes soit trop lent.

        Par exemple, pour moi, c'est le rafraichissement des éléments de Gnome/KDE qui pêche. Et si je fais glisser une fenêtre, elle laisse une traine du plus mauvais effet.

        Toute la difficulté, c'est d'indiquer à l'OS à quels sous-systèmes il doit fournir de la puissance à l'instant T.
        Une idée serait par exemple que le WM puisse indiquer à X et au kernel quelle application est actuellement active, et lui fournir du CPU et la faire redessiner en priorité.
        Mais je crois que c'est techniquement très difficile. Est-ce que quelqu'un a déjà essayé de le faire ?

    • [^] # Re: bench

      Posté par  (Mastodon) . Évalué à 3.

      +1

      Mais c'est également ce qui est reproché au commentaire de Con : il ne précise rien d'autre que "une meilleure expérience, une meilleure sensation, pour l'utilisateur". Ce qui est assez vague.

      Par exemple s'il avait explicitement nommé quelque chose du genre "les entrées standarts ont toujours priorité absolue : sur n'importe quel autre process et dans n'importe quel cas de charge système".

      Ou encore "nous avons décidés d'appliquer aux entrées standarts la même politique qu' aux systèmes de fichiers et à la mémoire vive : une réservation pour être opérationnel dans tout les cas".

      Ou plus mr michu "fini le lag 'clique sur une appli lorsque le système lit une vidéo hd' : l'application cliquée se lance avec la même vitesse que sans la lecture simultanée de la vidéo hd".

      Mais ce n'est pas le cas, pourtant c'est bien que ce sous entends "une meilleure expérience utilisateur" entre autre. Et cela aurait collé avec (dans le cadre de) sa remarque qualifiante pour bfs "ridiculement simple". Ce n'est pas le cas car un tel exemple aurait forcément été réducteur pour un ordonnanceur.

      En plus Phoronix, ben heu, je fait nettement plus confiance à Ingo Molnar pour présenter des résultats vrais et cohérents. (phoronix a un peut trop tendance à mon goût à 'oublier' certains résultats pour favoriser son champion). Mr Molnar a fait le choix d'utiliser des machines puissantes, mais après tout il reste dans le cadre d'utilisation cité en exemple par Con lui même.

      Le résultat intéressant sera lorsque les industriels utilisant massivement linux en embarqué testeront eux mêmes et choisiront. Là, il pourrait bien y avoir des surprises.

Suivre le flux des commentaires

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