Journal BFS

Posté par .
Tags : aucun
19
3
sept.
2009
Cher journal,

Ces quelques lignes pour signaler la sortie de BFS, un nouveau scheduler, écrit par Con Kolivas : Con Kolivas est le célèbre anesthésiste (Australien), grand contributeur au noyau Linux devant l' éternel :)

Pour mémoire, il stoppa pendant un temps ses contributions lorsque le scheduler d' Ingo Molnar fût préféré au sien. Le principal argument retenu étant que Ingo était un employé de Redhat et à ce titre on pouvait compter sur ses contributions de manière permanente. Ainsi l'avenir de CFS était assuré pour le noyau. Alors que Con n'est pas un professionnel de l'informatique, on ne peux avoir de certitudes quant à l'avenir de ses contributions. Or un élément aussi primordial que l'ordonnanceur a besoin d'assurance concernant le rythme d'évolution, il ne s'agit pas d'un driver tiers pouvant être facilement/rapidement repris. C'est clairement un argument massue, et je ne sais s'il a servi a cacher d'autres types d'arguments afin de ne froisser personne. En tout les cas, ce fût quant même un coup dur pour Con, qui décida alors de prendre du recul vis à vis du noyau.

BFS, accrochez vous, signifie "Brain Fucker Scheduler".
Il s'agit d'un ordonnanceur orienté "desktop" (dans le sens "machine de mr michu"), également conçu pour des machines dont les qualités techniques sont loin des "stations de travail" (encore une fois, pour "mr michu").

Considérant que les solutions d'architecture des divers ordonnanceurs ne sont pas adaptées à une utilisation "bureautique" d'une station, elles ne seraient efficaces que sur un certain type d'usage. Elles ne garderaient pas assez le contrôle de votre matériel pour les tâches courantes, ne permettant pas d'exploiter pleinement les capacités du matériel lors d'une utilisation "souris" (hihhi) de votre ordinateur.

Con Kolivas qualifie son BFS de "ridiculement simple". On notera qu'il n'est pas possible de faire joujou avec le "nouvel" outil CGROUPS, si on choisi d'utiliser BFS. "Parcequ'un utilisateur de 'desktop' n'a pas besoin de ce genre d'options auquelles il ne comprends rien" (gros sniffff .... autant sur l'absence de cgroups que sur cet argumentaire plus que contestable). Con recommande fortement d'activer la preemption faible (sans spécifier laquelle, on peux penser qu'il parle des patchs déjà présents, et de longue date, dans le noyau) ainsi que DynTicks (et une horloge à 1000 hz, tiens donc....). Enfin on (mr michu, presque) pourra lancer sa session complète avec l'utilitaire schedtool. (ça c'est bourrin... en fait Con donne l'exemple schedtool -I -e amarok )

Mes talents de traducteur étant plus que piètres, je préfère vous laisser lire par vous même le readme de Con, disponible sur son site :

http://ck.kolivas.org/patches/bfs/bfs-faq.txt











Pour finir, une question en forme de petite reflexion : on pourra se demander ce que vont décider les diverses distributions proposant des solutions "desktop" toutes prêtes. A l'issu de banc de tests sur les gains réels, et les impacts éventuels, vont elles proposer une version "desktop / multimédia" vraiment taillée pour ? (et pas seulement avec ce sheduler, mais c' est une pierre de plus dans la potentielle nécessité d'arrêter les "distributions à tout faire" (à reserver aux geeks et admin et ...) du genre option de boot "installation serveur ou installation desktop ?" mais plutôt de proposer des "produits, des distributions parfaitement adaptées au besoin cible.
  • # Woh Pitaing Con !

    Posté par (page perso) . Évalué à 5.

    On va bientôt appeler ces types de comportement des « colivasseries »...
  • # Caste.

    Posté par . Évalué à 10.

    > Le principal argument retenu étant que Ingo était un employé de Redhat
    > et à ce titre on pouvait compter sur ses contributions de manière
    > permanente. Ainsi l'avenir de CFS était assuré pour le noyau.
    > Alors que Con n'est pas un professionnel de l'informatique, on ne
    > peux avoir de certitudes quant à l'avenir de ses contributions.
    > Or un élément aussi primordial que l'ordonnanceur a besoin
    > d'assurance concernant le rythme d'évolution, il ne s'agit pas
    > d'un driver tiers pouvant être facilement/rapidement repris.
    > C'est clairement un argument massue,

    C'est une surtout un argument à la con oui;
    Depuis quand une personne travaillant pour une boite d'info à plus de pertinence qu'une autre personne ?
    Je suis désolé, mais moi, ca me casse les bolox ce genre de sectarisme "si t'es pas de ma caste, alors ton travail est moindre".
    Bizarrement, ca me fait penser à une certaine caste "scientifique" qui - si on a pas fait tels études ou passé dans tels écoles - on pas le droit à la parole ... ou nos travaux ne sont pas considérés comme sérieux.
    Ecarter le boulot de Con Kolivas parce qu'il est anesthésiste, c'est purement et simplement une connerie

    En espérant, comme tu le laisses supposer, que ce soit qu'un prétexte pour "cacher d'autres types d'arguments afin de ne froisser personne" (dans ce cas, pourquoi l'avoir plus ou moins considéré depuis le début du développement...)
    • [^] # Re: Caste.

      Posté par (page perso) . Évalué à 9.

      Ce n'est pas que son travail n'est pas considéré comme sérieux parce qu'il est anésthésiste, mais que son travail est plus difficilement maintenable parce qu'il est moins disponible pour travailler dessus que quelqu'un qui est employé pour travailler spécifiquement dessus. Il aurait été informaticien mais ne travaillant sur Linux que sur son temps libre, le problème aurait été le même.
      • [^] # Re: Caste.

        Posté par . Évalué à 10.

        > son travail est plus difficilement maintenable parce qu'il est moins disponible pour travailler dessus que quelqu'un qui est employé pour travailler spécifiquement dessus.

        Ça me semble pas très convainquant comme argument.
        Le modèle collaboratif de Linux permet justement de s'affranchir de ce genre de détails.
        Il n'y a pas qu'un seul spécialiste des ordonnanceurs, de nombreuses parties du noyau sont maintenus par des personnes qui n'en sont pas les auteurs originaux.
        Vous imaginez le merdier si pour chaque pièce de code du noyau, il n'existerait qu'une seule et unique personne capable de la maintenir ?
        Le problème de la disponibilité est un faux problème si CK fait faux-bond, un autre prendra sa place. À moins que son ordonnanceur soit tellement génial/abscons que personne puisse le comprendre, je ne vois pas pourquoi ça ne serait pas le cas. Où alors, faut se faire à l'idée que Linus n'est pas immortel ...

        Si l'ordonnanceur de CK n'a pas été retenu, c'est soit les alternatives étaient supérieures, soit pour des raisons plus mesquines.
        • [^] # Re: Caste.

          Posté par . Évalué à 7.

          À moins que son ordonnanceur soit tellement génial/abscons que personne puisse le comprendre

          C'est encore pire que ça : son ordonnanceur est asbconkonlivas...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Caste.

          Posté par . Évalué à 5.

          Merci pour de la réponse, c'est ce que j'allais répondre :)

          Du même point de vue que toi, ca me choque quand on avance "il aura pas le temps". J'ai envie de rétorquer "Hey mec! tu connais pas la co-responsabilité du code ?, tu crois que t'es le seul à connaitre ton bout de code ? depuis quand un mec est « propriétaire » ad-vitam-eternam de son code ?"

          Ou alors Linus a franchement pas envie de s'emmerder avec son bout de code.

          .. Ou bien comme avance quelqu'un en dessous: Con Kolivas aime pas trop les critiques. Enfin bon, venant de Linus, c'est un peu l'hôpital qui se fout de la charité :-)
          • [^] # Re: Caste.

            Posté par . Évalué à 4.

            peut-être qu'il y a d'autres problèmes sous jacent avec son code / avec le personnage, mais à fonctionnalités égales, si j'étais un décideur pressé ou un geek zélé, j'avais à choisir entre un code produit par un développeur travaillant pour le noyau linux, et un autre, tout aussi talentueux, par le faisant sur son temps libre pour le plaisir, je prendrais celui qui offre le plus la garantie que si on a besoin de lui à un moment donné pour travailler dessus lors d'un coup de bourre, il soit disponible, et qu'il ne dise pas, "désolé, j'ai du travail avec mon vrai boulot en ce moment".

            Après, bien sûr qu'il est toujours possible de trouver un autre développeur pour travailler dessus s'il devenait complètement indisponible, mais c'est toujours du temps de perdu, et c'est plus facile de choisir s'il y a un autre projet à côté qui fait la même chose...

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Caste. / Quoi Linus n'est pas immortel?!!!

          Posté par (page perso) . Évalué à 1.

          Quoi Linus n'est pas immortel?!!!
          On m'aurai menti!

          C'est dingue...

          Désolé je prends de l'avance sur vendredi
          :)
    • [^] # Re: Caste.

      Posté par . Évalué à 3.

      > Le principal argument retenu étant que Ingo était un employé de Redhat
      > et à ce titre on pouvait compter sur ses contributions de manière
      > permanente. Ainsi l'avenir de CFS était assuré pour le noyau.
      > Alors que Con n'est pas un professionnel de l'informatique, on ne
      > peux avoir de certitudes quant à l'avenir de ses contributions.
      > Or un élément aussi primordial que l'ordonnanceur a besoin
      > d'assurance concernant le rythme d'évolution, il ne s'agit pas
      > d'un driver tiers pouvant être facilement/rapidement repris.
      > C'est clairement un argument massue,

      C'est l'argument que j'avais soutenu dans une précédente discussion et quelqu'un m'avait fort aimablement fait remarqué que ma mémoire était défaillante et que j'avais tord.
      Visiblement, l'argument principal qui avait motivé la décision de Linus Torvald est, hors la supériorité technique du scheduler d'Ingo Molnar, la grande difficulté qu'à Con Kolivas a à supporter et tirer parti des critiques de son travail.
      • [^] # Re: Caste.

        Posté par . Évalué à 1.

        s/remarqué/remarquer/g
        s/tord/tort/g
        s/qu'à Con Kolivas a à/qu'a Con Kolivas à/g

        Ne pas se relire quand on a l'estomac vide est une mauvaise idée...
      • [^] # Re: Caste.

        Posté par . Évalué à 3.

        Il me semble que c'est là le propre de l'indépendance : Lorsqu'on tenu aux résultats, on ravale sa fierté et on continue en faisant le tri et ne gardant que les remarques permettant d'avancer. Lorsqu'on est indépendant, l'égo peut jouer un plus grand rôle, et ravaler sa fierté pour faire le tri peut prendre plus de temps. C'est naturel et humain.
        D' où le "difficulté qu'à Con Kolivas a à supporter et tirer parti des critiques".

        D'un autre côté on observe largement que ce type de comportement dans le modèle collaboratif GNU - BSD est nettement moins présent, moins visible. Le travail en réseau et les outils utilisés tendent largement à apaiser ce type de comportement d'une part. Et d'aute part à mieux le comprendre et le supporter, en laissant le temps à chacun pour sa 'digestion'.

        Bref, c'est un argument valable selon moi (bien que me plaçant du côté de "ceux qui ne sont pas passé par l'école). Mais je crois que peut être ce n'est pas le seul argument. Car par exemple quid de toutes les intégrations des améliorations apportées par la branche -rt en utilisant le bfs ? N'y a t il pas là un risque de ralentissement de l'évolution par cause de manque de cohésion ? Je ne sais pas. En tout cas je vais tester dès ce soir bfs sur kernel-rt (ou plutôt patch bfs puis patch rt, en essayant de comprendre (hum hum, disons plutôt les corrections possibles par mr michu) les modifications nécessaires à faire s'il y avait lieu).
        • [^] # Re: Caste.

          Posté par . Évalué à 2.

          zut il manque plein de "je ne sais pas" et de "?"
        • [^] # Re: Caste.

          Posté par . Évalué à 5.

          D'un autre côté on observe largement que ce type de comportement dans le modèle collaboratif GNU - BSD est nettement moins présent, moins visible.

          Alors ça ça se discute, quand on lit certains mails de Theo de Raadt, Daniel J. Bernstein, Alan Cox, Linux Torvalds ou autre :-P
  • # C'est doublement con...

    Posté par . Évalué à 3.

    "On notera qu'il n'est pas possible de faire joujou avec le "nouvel" outil CGROUPS, si on choisi d'utiliser BFS."
    "vont elles (les distrib') proposer une version "desktop / multimédia" vraiment taillée pour ?"
    Je note que les CGROUPS, même s'ils sont trop complexes pour mr. Michu, auraient peut-être pu servir aux mainteneurs de distrib', non ?
    • [^] # Re: C'est doublement con...

      Posté par . Évalué à 3.

      Et oui ...
      snifff :(

      au début on aurit pû penser qu'ils attendaient une ""api"" simple. Maintenant que Cgroup n'est plus un gros fichier unique, mais est -beaucoup- plus simplement configurable, on peux se demander pourquoi les distributions (que je connais bien, soit Fedora et Mandriva) ne l'utilisent pas. Et la doc (touffue, pas le petit txt de départ) aussi est là maintenant, plus besoin d'y aller à 'tatons pour tests'.

      A propos de docc sur le sujet :
      http://broadcast.oreilly.com/2009/06/manage-your-performance(...)
      D'autant plus intéressant qu'il compare avec la solution (qui-pue-cul) de Solaris. Cette dernière non-intégrée dans le noyau, est en plus mal configurée par défaut... Mort de rire quant il faut attendre 15 minutes pour que la réponse à la demande de connection de root soit lancée... mouarf :)

      Solaris propose un ensemble extrèment simple (même moi j'ai compris) pour configurer cela (et avec toujours plus de possibilités par défaut, dans la facilité d'administration) c'etait un avantage indéniable.

      Linux à mis plus de temps pour avoir un équivalent, mais celui-ci est dans le noyau, et aujourdhui facilement configurable.

      Je ne connais pas de distribution qui en font l'usage par défaut. C'est vraiment dommage et j'aimerai bien comprendre pourquoi ?
  • # Petites Inexactitudes

    Posté par . Évalué à 8.

    C'est le Brain Fuck Scheduler (et pas fucker) ... c'est bien moins vulgaire

    et il conseille de désactiver le tick dynamique et pas de l'activer comme tu le dis.
  • # BFS

    Posté par (page perso) . Évalué à 10.

    >>> Le principal argument retenu étant que Ingo était un employé de Redhat et à ce titre on pouvait compter sur ses contributions de manière permanente

    Ouais enfin Linus a aussi bien insisté sur le fait qu'Ingo tenait compte des rapports de bugs des utilisateurs de son scheduler et qu'il corrigeait rapidement le code.
    de son coté Con Kolivas a passé beaucoup de son temps a nier les problèmes de son scheduler et semblait bien moins enclin a corriger son code.
    Il n'y a donc pas qu'un problème de "temps disponible".


    Sinon il y a un article sur LWN (avec beaucoup de commentaires) a propos de ce nouveau scheduler BFS : http://lwn.net/Articles/350100/

    A noter que j'ai appris en lisant ces commentaires que les noyaux Debian ne sont pas compilés avec l'option CONFIG_PREEMPT donc on a par défaut un noyau qui est bien plus adapté aux serveurs qu'aux machines de bureau.
    Pourquoi est-ce que Debian ne propose pas 2 sortes de noyaux ? Le profil d'utilisation d'un serveur et d'un laptop n'ont rien à voir et il serait bien d'avoir un noyau un peu plus adapté.
    • [^] # Re: BFS

      Posté par . Évalué à 2.

      Donc pour résoudre le problème, il suffit d'inclure l'algo de Con dans le trunk et que tout le monde soit responsables de son code ?
      - Plus de temps disponible pour le scheduler de Con (les autres s'en occuperont)
      - Les problèmes liés à son scheduler seront éprouvés sur le terrain (voire approuvés)
      - Du fait de la co-responsabilité du code, tout le monde connaitra le code

      En fait, ce qui me dérange dans tout ceci, c'est qu'un contributeur actif, qui fait cela sur son temps libre, que son principal job n'a aucun lien avec l'info, et bien on lui dit d'aller limite se faire f.. voir ailleurs; Je trouve cela limite.
      • [^] # Re: BFS

        Posté par (page perso) . Évalué à 0.

        et bien on lui dit d'aller limite se faire f.. voir ailleurs; Je trouve cela limite.

        Si tu considères que quand il y a x compétiteurs pour un truc donné, le fait de choisir un gagnant signifie dire aux x-1 autres d'aller se faire foutre, tu vas avoir un gros problème avec tout les "concours" qu'il y a sur la terre, et tu vas avoir un problème avec ton boulot aussi (on est toujours en compétition dans notre monde...)

        Pourquoi parler "d'aller de faire"?

        Des gens ont pesé le pour et le contre, un contre mais pas le seul est sa disponibilité.
        Si il avait un "pour" qui effaçait ce défaut, ça irait, mais non, il se prendre d'autres "contres" (non prise en compte des commentaires...)

        Et franchement, entre un code parfait + un mainteneur, et un code parfait sans mainteneur, en tant que gestionnaire de code je choisi aussi la première solution : ça fera moins de charge pour les autres.

        C'est un peu trop facile de mettre tout sur le dos du "pauvre petit qui travaille à côté", mais il faut rester pragmatique : en plus du côté "meilleure prise en compte des commentaire", la solution d'en face a aussi "j'arrive avec du fric pour payer un mainteneur", et ça joue, oui, pragmatique.

        Maintenant, si il veut passer au dessus et être le gagnant, il a le choix : trouver un mec qui sera payé pour être mainteneur, proposer une solution qui soit meilleure, vraiment meilleure, et j'en passe.

        Ca reste une compétition, rien de plus, mettre des sentiments dans l'histoire est du n'importe quoi.
        • [^] # Re: BFS

          Posté par . Évalué à 3.

          > tu vas avoir un gros problème avec tout les "concours"
          > qu'il y a sur la terre, et tu vas avoir un problème
          > avec ton boulot aussi (on est toujours en compétition dans
          > notre monde...)

          Je t'arrêtes de suite, tu vas directement te calmer sur les attaques personnelles et les petites piques de dessous-les-fagots. Cela devient une fâcheuse habitude dans tes réponses.


          [-1 parce que hors sujet]
      • [^] # Re: BFS

        Posté par . Évalué à 2.

        On lui a pas dit d'aller se faire foutre, c'est juste qu'il yavait meilleur que lui, donc il a pas ete choisi.
        Apres, c'est toujours la meme rengaine de calimero de soutenir celui qui a perdu face a l'encule de gagnant.

        Sur un projet de cette envergure, on demande pas uniquement du code, mais aussi un mainteneur.
        Mainteneur dans ce cas voulant plutot dire "lead developper" ou "team leader" que simple grouillot qui bouffe du disque dur pour chier du code.

        Et objectivement, entre un leader qui n'ecoute pas la critique sur son bebe et qui n'est pas toujours disponible, face a un autre qui ecoute et est paye pour etre disponible, avec une solution technique comparable en termes de resultats, ben le choix est vite fait...
        • [^] # Re: BFS

          Posté par . Évalué à 2.

          Sauf erreur de ma part, mais Con et Ingo n'était pas fifty-fifty sur la qualité du code et de ses fonctionnalités ?
    • [^] # Re: BFS

      Posté par . Évalué à 3.

      Pourquoi est-ce que Debian ne propose pas 2 sortes de noyaux ? Le profil d'utilisation d'un serveur et d'un laptop n'ont rien à voir et il serait bien d'avoir un noyau un peu plus adapté.

      Le problème, c'est que tu commences comme ça, et ensuite, tu ne peux plus t'arrêter: pourquoi autant de drivers pour les netbooks limités en ressources et peu extensibles, comparés aux desktops? Faisons un noyau de plus!

      Pourquoi telle option qui fonctionne bien pour son utilisation mais pas la mienne? On ne pourrait pas faire un noyau dédié?

      Et Debian va finir avec 12 noyaus x n_plateformes, le tout non maintenable, et surtout probablement difficilement testable (trop de combinaisons!). Donc il faut faire un choix.

      Et ça ne me choque pas que Debian préfère soutenir un noyau de serveur et laisser les utilisateurs desktops se débrouiller que le contraire. ;)
      • [^] # Re: BFS

        Posté par . Évalué à 4.

        sans aller jusque dans les détails, certaines distribs fournissent un éventail de noyaux plutôt pas mal

        server, desktop, realtime(rt), vanilla(aussi appelé linus), tmb (pour le support en avance de certains matériel, mais potentiellement moins stable), et netbook.

        Mais il est vrai que cette distrib ne gère pas autant d'architecture que débian.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: BFS

          Posté par (page perso) . Évalué à 1.

          La distribution dont il parles s'appelle Mandriva pour vous éviter de chercher, sortie de la 2010.0 pour octobre je crois ;)
      • [^] # Re: BFS

        Posté par . Évalué à 8.

        Personne ne dit de tuner des noyaux très spécifiques, mais la différence de besoins basiques entre serveur et ordinateur personnel est très notable. La différence de l'expérience utilisateur est très très sensible avec un noyau adapté. Il y aurait simplement deux types de noyaux de base ce ne serait pas la mort, ce n'est pas le genre d'option qui va nécessiter trop de tests non plus et ferait gagner du temps à beaucoup de leurs utilisateurs (c'est un truc qui m'a toujours beaucoup énervé avec debian). Et puis l'argument de la multitude ne noyaux est plutôt périmé quand on voit les dépôts de debian...
        • [^] # Re: BFS

          Posté par (page perso) . Évalué à 3.

          Effectivement un noyau serveur et un autre desktop ce serait quand même pas la mer à boire (surtout que les différences c'est juste quelques options en plus ou en moins).
          Y'a un moyen de voter pour des bugreports ?

          http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539209

          PS : que fait Ubuntu à ce sujet ? Il me semble qu'il y a deux sortes de noyaux non ?
          • [^] # Re: BFS

            Posté par . Évalué à 3.

            amha, suffit de se proposer mainteneur du nouveau noyau, surtout si c'est "pas la mer à boire" :P
      • [^] # Re: BFS

        Posté par . Évalué à 3.

        /*mode 2 cents*/

        Le problème, c'est que tu commences comme ça, et ensuite, tu ne peux plus t'arrêter: pourquoi autant de drivers pour les netbooks limités en ressources et peu extensibles, comparés aux desktops? Faisons un noyau de plus!
        Il me semblait que c'était l'une des forces : portabilité, adaptabilité.
        J' imagine que ceux utilisant du Debian en embarqué sensible tunent finement le tout. (ha d'ailleurs j'imagine pas, j'en suis sûr ;) ) Et pourtant cela reste une Debian.

        Pourquoi telle option qui fonctionne bien pour son utilisation mais pas la mienne? On ne pourrait pas faire un noyau dédié?
        Et Debian va finir avec 12 noyaus x n_plateformes, le tout non maintenable, et surtout probablement difficilement testable (trop de combinaisons!). Donc il faut faire un choix
        Là, la réponse devrait peut être : "ben fait le pour toi, chez toi" ?

        Et ça ne me choque pas que Debian préfère soutenir un noyau de serveur et laisser les utilisateurs desktops se débrouiller que le contraire
        Moi non plus :) ! C'est une situation nettement préférable, certainement.
        Par contre un noyau de plus, juste un, pour les netbooks, ça serait peut être pas un mal, pour et chez personne.

        et ensuite, tu ne peux plus t'arrêter
        Espérons que non :) Blague à part, si bien sûr ! La problématique d'une distribution étant sans commune mesure avec la personne recompilant chez soi, il est certain que des choix draconiens doivent être fait. Proposer 2 noyaux ne (me) semble pas la mère à boire.... Et avec un meta-paquet "mr michu" qui s'occupe aussi de pam en général, de limits.conf en particulier, du serveur x une tty suffit, de sysctl, et de qq autres trucs au passage... okok je sort, c'était pour rire :) (désolé)
  • # brain fuck

    Posté par (page perso) . Évalué à 1.

    J'intégrerais le BFS dans mon noyau lorsqu'il sera écrit en brainfuck:

    http://en.wikipedia.org/wiki/Brainfuck

    J'imagine que le nom BFS vient de son minimalisme, comme pour le langage brainfuck.
  • # Inquiétant

    Posté par . Évalué à 3.

    Toute cette histoire est inquiétante:
    - Con Kolivas n'est pas informaticien de formation. Même si je ne remets pas cause ces compétences dans ce domaine, il avoue lui même avoir des lacunes sur certains points techniques.
    - Le noyau Linux est aujourd'hui reconnu par la communauté scientifique, communauté mondiale et composée de nombreuses personnes dont c'est le métier, la passion par certaines.

    Je suis assez surpris qu'une personne propose un nouvel ordonnanceur, extrêmement simple et performant (d'après ses dires). Je le suis encore plus lorsque j'apprends que cette personne "n'est pas du métier".

    C'est un coup dur pour les spécialistes d'autant plus que les critiques formulées sur BFS sont au choix: le nom est déjà utilisé par un système de fichier, le source n'est pas écrit en brainfuck, la qualité du code est déplorable, les performances dans des conditions d'utilisation "serveur surchargé" sont moins bonnes, qui sera le mainteneur de cette brique du noyau, etc.
    L'implémentation d'un système de plugin pour l'ordonnanceur du noyau Linux, permettant ainsi de choisir quel ordonnanceur l'on souhaite utiliser, semble avoir été refusé (information à confirmer).

    Pour marquer la fin de cette histoire, il va falloir se retrousser les manches pour que le noyau Linux possède un ordonnanceur capable de réagir parfaitement dans toutes les situations d'utilisation. La tâche est difficile...
    • [^] # Re: Inquiétant

      Posté par (page perso) . Évalué à 7.

      Je n'ai pas bien compris ce qui t'inquiète ici
    • [^] # Re: Inquiétant

      Posté par . Évalué à 2.

      Si j'ai bien compris, le fait que quelqu'un qui "n'est pas du métier" ait écrit un ordonnanceur plus performant (dans certains cas) que le CFS serait en fait une preuve qu'il n'est pas bon, ou pas "professionnel" ?

      J'interprète ce que tu as écris, alors je peux me tromper. Je comprends pas très bien non plus ton inquiétude.
      • [^] # Re: Inquiétant

        Posté par . Évalué à 3.

        Je n'ai jamais dis que CFS n'était pas bon ou même "professionnel".

        Je dis simplement que la solution proposée par Con Kolivas a été rejettée de façon peu élégante. Les principaux arguments apportés sont peu scientifiques et une sorte de coalition s'est créée contre BFS, de ce que je constate.

        J'ai l'impression que certaines parties du code du noyau devient une chasse gardée réservée à certaines personnes et que les règles du jeu ne sont pas bien définies.

        C'est en cela que je trouve inquiètante cette histoire.
    • [^] # Re: Inquiétant

      Posté par (page perso) . Évalué à 5.

      >>> Je suis assez surpris qu'une personne propose un nouvel ordonnanceur, extrêmement simple et performant (d'après ses dires). Je le suis encore plus lorsque j'apprends que cette personne "n'est pas du métier".

      Pourquoi est-ce que tu est surpris ?

      >>> C'est un coup dur pour les spécialistes

      N'importe quoi.

      >>> L'implémentation d'un système de plugin pour l'ordonnanceur du noyau Linux, permettant ainsi de choisir quel ordonnanceur l'on souhaite utiliser, semble avoir été refusé (information à confirmer).

      Effectivement tous les mainteneurs du noyau, Linus en tête, refuse cette solution bâtarde qui consiste à ne pas choisir et à laisser entrer tous les scheduler en mainline.

      >>> Pour marquer la fin de cette histoire, il va falloir se retrousser les manches pour que le noyau Linux possède un ordonnanceur capable de réagir parfaitement dans toutes les situations d'utilisation.

      CFS est déjà excellent dans la grande majorité des cas de figure.
      Con a choisi de privilégier un "use case" au détriment de tous les autres (il dit lui même que BFS n'est pas fait pour les machines NUMA alors que les processeurs récents ont souvent une telle architecture).
    • [^] # Re: Inquiétant

      Posté par . Évalué à 4.

      Peut être qu'au contraire, l'avenir est à la spécialisation.

      vue de mon niveau presque-michu :
      je n'ai pas le même besoin dans mon cellulaire que dans mon netbook, que dans des bancs d'intégration et validation 'machin'nique, que pour une station 'simulation', que dans ma station de travail portable, que dans ma station de travail 32go de ram quadri-pro, que dans mes serveurs interne réseau, que dans mes serveurs en frontal toile.

      Le gars qui met le même kernel dans tout ça, ouahou, j'ai peur.
      • [^] # Re: Inquiétant

        Posté par (page perso) . Évalué à 0.

        >>> Le gars qui met le même kernel dans tout ça, ouahou, j'ai peur.

        Pourtant les superordinateurs les plus puissants du monde tournent sous Linux....et les téléphones/gadgets GPS/télévisions Sony/Tux droid/etc tournent aussi sous Linux.

        >>> Peut être qu'au contraire, l'avenir est à la spécialisation.

        Si tu veux spécialiser les scheduler alors cela signifie qu'il faut un système de plugin puis qu'il faut multiplier les scheduler, chacun adapté à un type d'utilisation, déboger/tester/valider/maintenir les différents scheduler, etc

        Sur le long terme cela ne paye pas du tout. Il vaut mieux un seul scheduler d'excellente qualité.
        J'ai même lu sur la LKML que les mainteneurs regrettaient beaucoup d'avoir choisi la solution plugins pour les scheduler d'entrées/sorties (ou tu peux choisir en "Anticipatory", "Deadline", "CFQ", etc) et qu'ils préféreraient n'en avoir qu'un seul.
        • [^] # Re: Inquiétant

          Posté par . Évalué à 3.

          heu t'as pas compris

          du moins, pour moi, c'était, enfin je re-formule :

          Le gars qui met la même config de linux dans tout ça, ouahou, j'ai peur
          parceque dans tout ça, ici y a que Linux, c'est évident, la base est identique ;)

          parfois il y a des hyperviseurs dessous, mais c'est déjà un autre sujet
        • [^] # Re: Inquiétant

          Posté par . Évalué à 2.

          J'ai même lu sur la LKML que les mainteneurs regrettaient beaucoup d'avoir choisi la solution plugins pour les scheduler d'entrées/sorties (ou tu peux choisir en "Anticipatory", "Deadline", "CFQ", etc) et qu'ils préféreraient n'en avoir qu'un seul. Merci de l'info.
          Perso ça ne m'étonne pas.

          D'autant plus qu'il est assez simple (petit toussette) d'en choisir un autre de manière "extérieur" dès lors que ce patch s'intègre pas trop mal. (c'est le cas ici de BFS, il est facilement testable).
    • [^] # Re: Inquiétant

      Posté par . Évalué à 2.

      Et je vous présente mes excuses si ce journal déclenche des 'flames war' sur : "ce-qu'aurait-du-être-c'est-pas-bien". C'était pas du tout le but. Loin de moi l'idée de soutenir tel ou tel choix, je me dit juste qu'il y a des bonnes raisons, et ça me suffit.

      CFS est une "révolution" (et le mieux est que tu ailles toi même lire les diverses sources d'informations de "l'époque" pour te faire toi même ton avis sur cette question. Perso il me semble me souvenir que les deux étaient considérés comme excellent (on notera que DeadLine est toujours présent mais n'est simplement plus activé par défaut, par exemple). Il y en a déjà 2, l'historique et le nouveau... Pour les autres, ben après tout c'est bien le travail -éventuel- des distributions, non ?

      Faudrait pas confondre noyau vanille avec ceux des distros, ou alors c'est parceque tu utilises Fedora ;) ;) ;)
  • # Kolivas vs Ingo

    Posté par . Évalué à 1.

    Le principal argument retenu étant que Ingo était un employé de Redhat et à ce titre on pouvait compter sur ses contributions de manière permanente.

    Je ne crois que l'argument était là.
    Linus n'était pas que Kolivas refuse toute critique. Linus a donc dit un truc du genre : "je ne veux pas d'un développeur avec qui je ne peux discuter".
    Le scheduler de kolivas a donc été refusé et peut-être même avant la proposition d'Ingo.

    Ton argument ne tient pas car si le boulot de Kolivas était "fabuleux", d'autres (peut-être des employés de Red Hat ou autre) l'aurait maintenu/développé.
    Toute contribution, si elle est bonne, si elle va dans la bonne voie, est accèptée.

    on pourra se demander ce que vont décider les diverses distributions proposant des solutions "desktop" toutes prêtes.

    Elles ne vont rien "décider". Elles veulent le même ordonnanceur pour la grande majorité des cas d'utilisation (et donc desktop et serveur).
    • [^] # Re: Kolivas vs Ingo

      Posté par . Évalué à 7.

      Toute contribution, si elle est bonne, si elle va dans la bonne voie, est accèptée.

      C'est sûr qu'avec une prémisse pareille il n'est pas difficile de montrer que toute contribution non acceptée était forcément mauvaise et n'allait pas dans la bonne voie.
      En d'autres termes, le système fonctionne parce qu'il fonctionne et il est hors de question qu'il ne fonctionne pas, donc il fonctionne.
      Dommage que la Pravda ne recrute plus :)
      • [^] # Re: Kolivas vs Ingo

        Posté par (page perso) . Évalué à 3.

        C'est sûr qu'avec une prémisse pareille il n'est pas difficile de montrer que toute contribution non acceptée était forcément mauvaise et n'allait pas dans la bonne voie.

        En même temps, si on acceptait n'importe qu'elle contribution dans le noyau, ce serait un joyeux bordel.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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