Bonjour Nal … et tous les Linuxiens de Linux Fr et d'ailleurs,
je me demandais qui utilisait un Kernel BFS/BFQ ?
Depuis 10 ans, que j'utilise Linux, tous les jours, je n'avais que très peu entendu parler de ce kernel (à priori une fois ici et c'est tout).
Du coup, quand je suis tombé sur un paquet pour Ubuntu, je me suis demandé si ça valait le coup de l'installer, si c'était utilisé ou bien si c'était assez "touchy" à utiliser ?
Bref, je demande conseils auprès des experts de Linux FR ! ;-)
PS: je viens de voir en rédigeant ce journal qu'il y a un tag BFS … mais je ne sais pas rechercher les contenus avec un certain tag ! :-(
# tags
Posté par Frank-N-Furter . Évalué à 2.
https://linuxfr.org/tags/bfs/public
https://linuxfr.org/wiki/tags
Depending on the time of day, the French go either way.
# Faible bénéfice...
Posté par scullder . Évalué à 3.
J'ai utilisé pendant longtemps sous gentoo et archlinux. C'est inclu dans le patchset de Con Kolivas: http://ck-hack.blogspot.com/
C'est intéressant, le système est peut-être un peu plus réactif en utilisation desktop, mais j'ai arrêté car le bénéfice est assez faible par rapport au temps perdu sur des bugs ésotériques sur une distribution rolling release avec la dernière version du patchset sur la dernière version du kernel, la base d'utilisateurs est assez faible et on est fatalement parmi les premiers à tester…
Il me semble avoir lu sur linuxfr des résumés du débat sur l'inclusion de BFS dans linux, avec des gros comparatifs par rapport à CFS…
[^] # Re: Faible bénéfice...
Posté par Frédéric COIFFIER . Évalué à 3.
Sur Gentoo, je l'ai également activé mais cela me générait des crash kernel sporadiquement.
Par contre, j'aimais beaucoup la réactivité du desktop au démarrage où les applications déjà lancées étaient utilisables alors que les autres étaient en cours de chargement. De même, je sentais moins de ralentissement avec une forte charge disque.
# Résumé dans le prochain épisode
Posté par Prae . Évalué à 10.
Cela vous emm… embêterait de faire un résumé de ce qu'est Kernel BFS/BFQ pour ceux qui n'en ont jamais entendu parlé quand ils lisent vos journaux ? C'est pas comme si à plusieurs reprises, on dit non au journal bookmark. En vous remerciant.
[^] # Re: Résumé dans le prochain épisode
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Il y a qq années, il y eu un gros clash entre 2 codeurs de scheduleurs. Le CFS a été retenu pour son bon comportement sur les machines extrêmes (256 cpu). L'autre dev disait que c'était un détriment des machines "normales".
Il a donc créer un patch avec un scheduler de taches beaucoup plus simple, Linus a refuser d'avoir 2 schedulers. Il a demandé des cas d'exemples pour corriger ce qui existait déjà.
"La première sécurité est la liberté"
[^] # Re: Résumé dans le prochain épisode
Posté par ʭ ☯ . Évalué à 2.
C'est rigolo, je viens de voir que le BFQ vient d'être activé dans le noyau de la future Mageia 6. Esc-ce la même chose? Vous avez les 4 premiers patchs dans le lien ci-dessus…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Résumé dans le prochain épisode
Posté par ʭ ☯ . Évalué à 2.
Je mets la description pour les experts :
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Résumé dans le prochain épisode
Posté par ymorin . Évalué à 10.
Non, ce n'est pas la même chose :
Le premier va ordonner les requêtes vers/depuis les supports de stockage, le second vas ordonnancer l'exécution des tâches sur le/s processeur/s. BFQ est dans le noyau officiel (upstream), mais BFS est un patch maintenu par Con Kolivas, donc rien d'officiel et même rejeté (pour diverses raisons) par Linus il y a plusieurs années.
Ce sont deux "choses" totalement différentes.
Hop,
Moi.
[^] # Re: Résumé dans le prochain épisode
Posté par claudex . Évalué à 5.
Et il fait noter que BFQ n'est pas le seul scheduler d'IO alternatif à CFQ, il y a noop et deadline aussi.
« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 24 septembre 2016 à 15:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résumé dans le prochain épisode
Posté par Kerro . Évalué à 6.
D'autres personnes estiment que si tu ne prends pas la « peine » d'expliquer en une phrase à quoi correspond ce dont tu parles, alors ce n'est pas la peine de venir.
Un peu comme dans une conversation « normale », tu en penserais quoi d'un interlocuteur dont tu ne piges pas la conversation car tu es largué dès le premier acronyme ?
Si ça t'amuse d'ouvrir 3 onglets pour comprendre chaque journal, c'est que tu as de priorités assez particulières. Elles ne sont ni bonnes ni mauvaises : elles sont très inhabituelles. Les autres personnes ne sont pas comme ça.
Et puis c'est bêtement de l'efficacité sociale (que certains nomment « respect », qui est une partie de cette efficacité).
Attendre une réponse sans prendre la peine de poser la question convenablement, c'est un peu moyen comme efficacité.
[^] # Re: Résumé dans le prochain épisode
Posté par claudex . Évalué à 8.
En même temps, on peut imaginer que les gens ici ont une certaine connaissance des sujets qui tournent autour de Linux. Personne ne prend la peine de définir ce qu'est un kernel par exemple. Quand j'ai lu le titre, j'ai tout de suite compris, or je ne change pas de scheduler par défaut.
En même temps, si tu ne sais pas ce qu'est BFS, il y a peu de chance que tu ais patché ton kernel avec.
« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 25 septembre 2016 à 13:18.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résumé dans le prochain épisode
Posté par Kerro . Évalué à 9.
C'est justement le point important : c'est un journal, donc c'est fait « pour tout le monde ». Y compris les curieux qui aiment s'instruire, glaner des infos, se distraire, etc.
Si c'était dans un forum technique, ok, aucune objection.
Sur ce site je n'ai pas le souvenir d'avoir vu une remarque du genre dans un forum.
Par contre dans les journaux c'est tout le temps. Et cela me semble logique + pertinent.
Lorsqu'une question comme celle-ci est dans un journal, ce n'est pas réellement une question technique, mais plutôt un appel à commentaires, à avis, et à débat. Ça permet aux personnes « non concernées » de tomber sur l'info et d'éventuellement devenir concernées.
[^] # Re: Résumé dans le prochain épisode
Posté par benja . Évalué à 3.
Et donc, votre avis sur la question (du journal, pas celle de savoir ce qui est bien séant) ? Concerné ou pas ?
Personnellement, j'ai un petit faible pour CK parce qu'il incarne l'esprit du hackeur amateur, désintéressé voire philantrope. Et puis à l'époque il s'était poliment fait remercié par Linus, certes ça n'était pas le premier ni le dernier du genre, mais cet évènement montre bien que le développement du noyau reste avant tout une histoire politique (la solution "techniquement neutre" aurait été d'accepter plusieurs schedulers). Par contre je ne l'ai jamais utilisé, mais théoriquement, oui il est sensé être plus efficace car il a fait le compromis de sacrifier la sacro-sainte équité[1] du CFS[2] pour privilégier l'interactivité et l'utilisation d'un algorithme plus simple. En plus, IIRC[3], il parait que le gars est un médecin à la base ;-)
[1]: tiens tiens, on pourrait faire un lien avec le sujet de ce thread… :D
[2]: "Completly Fair Scheduler", ordonnanceur complètement équitable (pour ceux qui se sentent concernés mais qui ne savent pas pourquoi).
[3]: "If I Recall Correctly", en français "si je me souviens bien" (ça c'est pour être pertinenté :p)
[^] # Re: Résumé dans le prochain épisode
Posté par benja . Évalué à 2.
Post Scriptum :
J'aurais plus pensé que c'est la discussion, et non le journal, qui susciterait la naissance d'un intérêt par les «non-concernés».
Aussi paradoxalement, si la question d'un journal était "que pensez-vous du fait de poser une question spéficique à destination d'un public de connaisseur, sans expliquer les termes utilisés afin que des non-connaisseurs puissent devenir concernés", engendrerait-il des contributions pertinentes ?
[^] # Re: Résumé dans le prochain épisode
Posté par Prae . Évalué à 2.
Tu présupposes que la demande est pour moi. Perso, je m'en fous, je connais les termes, l'historique des schedulers et tout ce qui va avec. Je pense d'abord à ceux qui ne savent pas et qui vont se prendre la tête à ouvrir 36 onglets pour comprendre le sujet. C'est pas la première fois qu'on demande de définir un contexte lors d'une nouvelle dans un journal.
PS: A l'époque, LinuxFR proposait au moins un descriptif même rapide de ce que la nouvelle évoquait, elle donnait un contexte, même minimal: https://web.archive.org/web/20010119174800/http://linuxfr.org/
# Oui depuis 5 ansd
Posté par Nibel . Évalué à 9. Dernière modification le 22 septembre 2016 à 13:50.
Oui, j'utilise le noyau CK depuis maintenant 5 ans avec le BFQ activé :
Le gain est surtout retrouvé au niveau de la compression/décompression et lors des charges disque importantes. J'ai également constaté un boot plus rapide d'environ 25 pour cent sur ma machine, ce qui est énorme en terme de pourcentage mais ridicule en chiffre réel, je suis passé de 2,5s à 1,7s :
Jamais eu de véritables problèmes. Il faut parfois attendre quelques jours de plus pour avoir le noyau à jour par rapport au noyau classique et faire attention pendant les MAJ si l'on utilise le driver Nvidia proprio
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# choix futile ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
En fait, le choix du scheduler dans le noyau est assez futile, alors que c'est dans Firefox qu'il faudrait mettre un fsckeduler qui marche un peu mieux… Parce qu'un onglet qui fige le truc pendant 5 secondes, c'est grave relou !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.