Cher Nal,
Tu te souviens certainement de BFS, aka «Brain Fuck Scheduler» ? Non ? Il s'agit d'un ordonnanceur alternatif pour le noyau. Alternatif car il est développé par un amateur, Con Kolivas, anesthésiste de profession. Mr Kolivas a mis entre parenthèse tout développement sur cet ordonnanceur suite au refus d'une partie de l'équipe noyau d'intégrer son travail en amont, directement dans le kernel, aux côtés du vénérable no-op, de deadline et de CFQ essentiellement par le fait que n'étant pas professionnel de l'informatique, Mr Kolivas n'offrait pas les garanties nécessaires au suivi du rythme nécessaire au développement noyau (dans les exemples repérables, regardons comment le pilote pour hyperV par Microsoft a été traité, ainsi que quelques pilotes pour Android, malgré le fait que l'on ne peut pas douter du professionnalisme de l'origine de ces pilotes: «pas à jour ? dégage !» a souvent été le mot d'ordre.)
Cet ordonnanceur a pour but d'améliorer la réactivité générale d'un système de type «bureau» mais se trouve également intéressant dans de nombreux autres usages d'un système. Voir ce commentaire de Laurent Cligny pour une réflexion à ce sujet… Voir également ce journal de Patrick_G. Con Kolivas vient de publier une nouvelle version, estampillée stable, synchronisée sur le noyau 3.3, et fait son annonce sur la liste de diffusion du développement noyau sous la forme d'un mail regroupant les changements versions par versions, pour arriver à cette proposition stable.
Il accompagne son mail d'une jolie Nimage, résumant un résultat de benchmark (kerbench) dont on pourra trouver l'ensemble des détails sur le site web dédié au projet…
À noter que BFS est utilisé par Cyanogen, l'équipe proposant souvent un kernel-bfs pour nos téléphones. Ainsi que quelques distributions gnu/linux, comme ZenWalk. Enfin, la communauté Arch propose un dépôt dédié, avec plusieurs saveurs de noyau incluant cet ordonnanceur et prévu chacun pour une cible précise (intel/amd, en vrac : Sempron, Core2, Atom, …). Voilà, et moi je reboute de 3.3.0bfs #1 SMP PREEMPT Tue Mar 27 18:24:00 sur un CFQ parceque mes cheveux repoussent, et trop vite, je me suis fait dragué sur FaceB par 15 garçons et 15 filles en 15 minutes, mon poil est devenu si soyeux qu'il glisse, et mon endorse s'est résorbée par magie. BFS, ça fait peur.
- Explication initiale, à propos
- BFS pour le kernel 3.3, le patch
- Juste au dessus, quelques informations supplémentaires, sur le bench par exemple, mais aussi des conseils basiques pour la compilation selon ses besoins.
# la jolie Nimage qui manque
Posté par vincent LECOQ (site web personnel) . Évalué à 10.
http://postimage.org/image/wavusknl1/
Mais j'y pige que date, même en m’entraînant inlassablement a lire de façon fluide de dotsies
# Même pas mal
Posté par téthis . Évalué à 6. Dernière modification le 27 mars 2012 à 23:21.
3.2.13-1-ck #1 SMP PREEMPT Fri Mar 23 21:21:51 EDT 2012sur une distro qu'il faut pas que je nomme au risque de tomber dans la population de ceux qui disent qu'ils utilisent Archlinux.Des mois que j'utilise le repo-ck, ce vieux BFS et même pas de clavier qui blo
q
u
e
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Même pas mal
Posté par BAud (site web personnel) . Évalué à 4.
tu ne serais pas un archer adepte de la prétérition ?
hmmm, ça va finir en synonyme :)
[^] # Re: Même pas mal
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Sans vouloir parler de prétérition, et encore moins faire de la méta-prétérition, il faut bien reconnaître que c'est une figure de style tout à fait remarquable !
[^] # Re: Même pas mal
Posté par téthis . Évalué à 2.
Je ne répondrai sur ce sujet qu'en présence de mon avocat.
Hop, une baisse tendancielle d'une hausse supplémentaire à enregistrer, celle des archers exprimant volontiers qu'ils utilisent Archlinux.
PS : la langue française, le pire ennemi des drosophiles.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Même pas mal
Posté par solsTiCe (site web personnel) . Évalué à 1.
ah tiens je connaissais pas ce repo
je m'en vais essayer ce noyau à moindre frais (pas de compil toussa)
car moi aussi j'utilise … archinux
allez faut le dire quand même ;-)
y'a trop de fanboy debian ici pour ne pas devoir rééquilibrer un peu la balance.
# cool, mais bof
Posté par JGO . Évalué à 1.
Je pense que l'intérêt est surtout sa revanche personnelle. CK avait dû être vexé parce que juste avant qu'il se fasse jeter pour ne pas être informaticien, les derniers benchs montraient que son scheduler n'était pas significativement plus rapide que celui par défaut.
Aujourd'hui, CK est de retour, et sur environ une minute de calcul, son scheduler fait gagner une demi seconde (64,2-63,7 = 0,5 s). C'est bien pour lui et vive la diversité, mais dois-je vraiment patcher mon noyau pour un gain aussi faible ?
[^] # Re: cool, mais bof
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 4.
Ça fait quasi du 0,7% ! Pour un alt-tab ok, c'est négligeable, mais c'est tout de même intéressant
[^] # Re: cool, mais bof
Posté par Maclag . Évalué à 3.
Il me semble que Ingo Molnar s'est en fait très largement inspiré, sans s'en cacher, du scheduler de CK, et qu'il a apporté un tout petit plus dedans. Comme Ingo Molnar est lui un "professionnel de l'informatique", c'est son scheduler qui a été retenu comme nouveau scheduler par défaut après délibération parce que techniquement, on ne pouvait pas trop les séparer.
Je serais donc surpris que CK revienne avec des gains en perfs pharaoniques.
Mais la concurrence saine dans le Libre a toujours du bon!
[^] # Re: cool, mais bof
Posté par patrick_g (site web personnel) . Évalué à 9.
C'est surtout qu'Ingo a su gagner la confiance de ses pairs parce qu'il bosse bien, il ne trolle pas, il est réactif quand quelqu'un signale un problème, il étaye ses affirmations par des tests, etc. Linus a plusieurs fois affirmé qu'il prenait ses décisions d'inclusion de code en fonction de la capacité de l'auteur à travailler avec les autres.
On ne peut pas dire que CK soit exempt de tout reproche en ce qui concerne sa capacité à travailler avec les autres.
Peut-être est-ce lié au fait qu'Ingo est un "professionnel de l'informatique" pouvant y consacrer tout son temps (par opposition à Con Kolivas qui est anesthésiste et qui n'est pas maître de son temps). Je ne sais pas. En tout cas ça explique en grande partie le choix du scheduler d'Ingo par rapport à celui de CK.
[^] # Re: cool, mais bof
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Cela se ressent aussi je trouve dans son mail d'annonce pour cette version. Pour prendre un comparatif, certes osé, on dirait du Brad Spengler, il travaille seul dans son coin puis lâche du code (méthode similaire, la différence étant que Con Kolivas n'a pas certains "impératifs" que Spengler a/peut avoir(?)). Dans les deux cas, on peut observer une réaction un peu similaire : pas d'inclusion en l'état (pour raisons multiples), mais c'est observé de près et des morceaux sont inclus ou des idées sont reprises, que cela soit pour BFS ou pour GRsec.
J'aurai envie de dire "c'est très sain et remarquable", mais bon, enfoncer des portes ouvertes de si bon matin :)
[^] # Re: cool, mais bof
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Peut-être mais c'est un peu dommage parce qu'on ne retiendra pas les sources d'inspiration mais uniquement le nom du "professionnel de l'informatique" qui a signé le dérivé.
Et il ne faut pas rêver, quand on fait du libre, on travaille quand même un tant soit peu pour la gloire.
Et là, on retient que Kolivas est limite caractériel, qu'on doute qu'il puisse assurer le suivi mais que comme ses idées ne sont pas forcément inintéressantes, on reprend à une nouvelle sauce et on assure le suivi.
Pourquoi ne pas inclure sa version et laisser la communauté assurer le suivi et l'évolution ?
[^] # Re: cool, mais bof
Posté par claudex . Évalué à 4.
Parce que la concurrence a montré qu'elle savait déjà assurer le suivi, pourquoi risquer un éventuel problème si personne n'assure le suivi alors que la concurrence ne fait pas pire et a déjà un suivi d'assurer.
« 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
[^] # Re: cool, mais bof
Posté par JGO . Évalué à 3.
Tout ne va pas dans la branche principale du noyau, mais c'est aussi le rôle des distributions de proposer des patchs qui n'y sont pas. Plusieurs distributions intègrent les patches de Kolivas (Arch et Zenwalk ont été cités plus haut, gentoo les propose aussi).
[^] # Re: cool, mais bof
Posté par gaaaaaAab . Évalué à 9.
Pour le grand public, personne ne retiendra le nom d'un développeur du noyau de toute façon. Pour quiconque s'intéresse un peu au noyau et à son évolution, Kolivas est systématiquement cité comme source d'inspiration pour le CFS.
exemple, Completely_Fair_Scheduler:
[^] # Re: cool, mais bof
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
on ne pouvait pas trop les séparer.
Il y a quand même des différences. Celui par défaut est infiniment plus gros et donc son comportement est plus imprévisible. Il a été montré des cas pathologiques qui ont été corrigé depuis, mais vu la taille du code c'est difficile de prétendre qu'aucun autre cas de ce genre existe encore, au contraire du code plus simple de BFS.
On dirait que cfs ne s'améliore que si on trouve des cas où BFS est meilleur.
"La première sécurité est la liberté"
# BFS vs CFS
Posté par patrick_g (site web personnel) . Évalué à 10.
Ces schedulers sont consacrés aux I/O alors qu'avec BFS il s'agit d’ordonnancement des processus. Le vrai concurrent c'est CFS.
[^] # Re: BFS vs CFS
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Oui, oui. pourquoi ai je marqué cfq en lieu et place de cfs ? lol. osef Merci de la correction :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.