D'aucuns pensaient que l'ordonnancement (scheduling) était un problème résolu ou presque. Linus Torvals disait en 2001:
And you have to realize that there are not very many
things that have aged as well as the scheduler. Which is
just another proof that scheduling is easy.Vous devez réaliser que peu de choses ont aussi bien vieilli que l'ordonnanceur.
Ce qui constitue une preuve de plus que l'ordonnancement est facile.
L'implémentation pratique d'un algorithme pour les systèmes multi-coeurs est cependant loin d'être triviale. La publication qui donne lieu à ce journal The Linux Scheduler: a Decade of Wasted Cores
l'illustre sur plusieurs points. La parution de ce journal un vendredi est bien entendu une pure coïncidence.
En résumé, la problématique est que le coût de transfert d'un process vers un autre coeur est potentiellement élevé, et dépend entre autre de la structure des mémoires cache. L'agrégation des données de charge entre les coeurs/processeurs doit aussi être réfléchie, il y a un équilibre à trouver entre trop partager entre les coeurs et ralentir le système et risquer de prendre des décisions d'ordonnancement basées sur des informations partielles. Il y a donc recours à des heuristiques et optimisations qui ne fonctionnent pas dans tous les cas: dans la publication il est montré que certains coeurs sont inactifs pour de longues période alors que des processus prêts à tourner attendent ailleurs. L'article se lit bien et est agrémenté de citations de notre cher Linus qui n'a pas toujours raison…
# Energy waste is proportional.
Posté par mh-cbon . Évalué à 0.
+1 à main levée, comme je n'ai plus de droit de vote ; )
[^] # Re: Energy waste is proportional.
Posté par Frank-N-Furter . Évalué à 10.
https://linuxfr.org/aide#aide-karma
Depending on the time of day, the French go either way.
[^] # Re: Energy waste is proportional.
Posté par mh-cbon . Évalué à -5.
autant dire que c'est mort pour moi pour le moment :D
Et bon bah, je ne te mettrais pas +1 pour contribuer à ton karma vu que je ne peux plus voter :=/
J'aimerais bien connaitre ma valeur de karma.
Pour en revenir sur le papier, on s'amuse beaucoup à lire les citations ;)
Par contre la partie explicative de l’ordonnancement en multi-coeur nécessitera plus d'une re-lecture, donc au moins 3 lectures en ce qui me concerne.
[^] # Re: Energy waste is proportional.
Posté par Frank-N-Furter . Évalué à 10.
https://linuxfr.org/users/mh-cbon
3eme boite sur la gauche.
Depending on the time of day, the French go either way.
# Ouai...
Posté par barmic . Évalué à 10.
Puis en 2007, le noyau a totalement changé de scheduler pour passer à CFS (les cgroups, LXC, Docker, systemd, ça parle à des gens ? ;) ) et c'était tellement limpide qu'il y toujours eu un concurrent de CFS : BFS (pour Brain Fuck Scheduler). D'après son maintenant, quand tu a moins de 16 cores son truc est mieux (j'en profite pour découvrir que c'est encore maintenu ce qui est cool :).
J'ai pas lu l'article mais par rapport à ce que tu dis. Grosso modo le problème des schedulers, c'est qu'ils doivent prendre en un temps très réduit une décision sans pour autant avoir toutes les informations dont ils ont besoin à disposition. Le noyau a toujours (ou depuis très longtemps) eu de quoi interagir avec l'ordonnanceur depuis le userspace (avec cpuset par exemple), mais CFS via les cgroups a apporté beaucoup plus de finesse dans cela.
Pour rappel 3 ans après sont introduction, on a eu une nouvelle option dans le noyau qui montrait bien l'intérêt de CFS : http://www.computerworld.com/article/2469655/desktop-apps/the-linux-desktop-may-soon-be-a-lot-faster.html
Bref en 2001, il restait encore beaucoup à faire ! :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # However, they must be able to steal from the more loaded cores on other nodes.
Posté par mh-cbon . Évalué à -9.
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par ʭ ☯ . Évalué à -2.
Même traduit automatiquement ça ne devient pas compréhensible en français ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par mh-cbon . Évalué à -6.
oui, et puis je ne m'y tenterais pas. Le portage de certaines dénominations de la langue anglaise vers la langue française sont vraiment insupportable.
Mon plus bel exemple étant celui ci
tenter le en traduisant observable par sujet, vous allez voir c'est pas fun ; )
Ceci dit, c'était surtout pour réagir à ceci, mais la citation était mal choisie.
Je saute aux conclusions (j'avoue je n'ai pas lu tous les bugs), le problème n'est pas le manque d'outils existant ou d'algo, mais leurs intégrations dans un système fiable et cohérent.
Pour réussir ce véritable défi, le papier préconise de commencer par se doter d'outils de visualisation.
et le yakafonkon qui va bien pour aller plus loin
lire aussi,
si je ne m'abuses évidemment ! Plus évidemment encore, c'est avec joie je me prendrais d'autres -1 si je dit une bêtise. Vu que je suis déjà à -32 je n'ai plus peur de rien :p
La question qui me reste en suspend étant celle ci, au départ, quels étaient les signes qui montraient une faiblesse de l'algo à cet endroit là ?
Car si j'en suis le papier, il y a d'abord eu suspicion, puis création d'un outils de visualisation, puis correction, production de preuves et enfin théorisation.
Ptet je l'ai loupé.
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par barmic . Évalué à 6.
Tricheur ! Ouh ! C'est la doc de Rx ! Observable est un nom propre dans ce contexte. C'est comme si tu voulais traduire Windows par fenêtre pour parler de l'OS ou Apple par pomme pour parler de la société aux ordinateurs blancs.
M'étonne pas que tu sois à -32 avec des triches pareil ! ;)
Je n'ai pas dis que c'était suffisant ou même parfait, j'ai dis que ça existait.
Mais c'est un problème assez compliqué et il y a des débats houleux sur ces sujets en témoigne le gros débat qu'il y a eu sur la façon de gérer les cgroups (avec Google qui a des besoins particuliers pour Android et systemd qui veut devenir seul maître abord).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par mh-cbon . Évalué à -10.
au risque de polluer la db, +1 sur toute la ligne !
Suite à cette citation de la doc Rx j'ai arrêté de tenter de traduire des docs techniques. L'impérialisme américain me fait vomir, mais pour tout ce qui concerne l'informatique c'est quand même ce qu'il ce fait de mieux…
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par ʭ ☯ . Évalué à 3.
Pour le plaisir ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: However, they must be able to steal from the more loaded cores on other nodes.
Posté par mh-cbon . Évalué à -7.
mouarf ! I did my best ! : )
# Et Paf!
Posté par ʭ ☯ . Évalué à 2. Dernière modification le 08 avril 2016 à 10:31.
Il fallait que ce journal tombe aujourd'hui, où j'obtiens un truc bizarre avec l'ordonnanceur:
- musique de fond avec Clementine (sous KDE4 et à travers Pulseaudio), ça ne coupe jamais SAUF
- si je tue la mémoire disponible (SWAP en remplissage à fond)
- si je convertis des fichiers audio avec soundKonverter, même pour un seul fichier à la fois.
C'est un bi-cœur, et il n'a aucun problème avec du stress -c 20. Alors quoi?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et Paf!
Posté par barmic . Évalué à 6.
Je ne sais pas mais tu peux déjà essayer de lancer Clementine et soundKonverter dans 2 cgroups différents.
Perso pour faire ça simplement,
puis :
Par contre j'ai pas compris :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et Paf!
Posté par ʭ ☯ . Évalué à 3.
C'est juste que Firefox avec xdebug peut partir en vrille, mangeant toute la RAM disponible. Ça sature les io, mais là je comprends pourquoi. C'est avec soundKonverter que je ne comprends pas, car si je convertis en ligne de commande avec un pipe ça ne le fait pas. Peut-être une saturation du dbus?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et Paf!
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Contrairement à ce que l'on croit, le système disque peut introduire des latences sur les autres processus. Cela occupe de la bande passante mémoire, le contrôleur IO n'est pas forcément très rapide, etc…
Je pense que c'est la même chose avec des cartes réseaux mais très rapide (10G ?)
"La première sécurité est la liberté"
[^] # Re: Et Paf!
Posté par MTux . Évalué à 2.
Alors merci Pulseaudio…
[^] # Re: Et Paf!
Posté par dinomasque . Évalué à 9.
C'est pas avec BeOS que ce genre de malheur arriverait.
BeOS le faisait il y a 20 ans !
[^] # Re: Et Paf!
Posté par Xaapyks . Évalué à 5.
Pour le coup je pense que c'est plutôt le scheduler d'I/O là qui a du mal.
Et ça je le remarque aussi très souvent sur les disques mécaniques lents.
[^] # Re: Et Paf!
Posté par xcomcmdr . Évalué à 0.
C'est pas un pléonasme ? ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# 2016, la majorité des programmes tournent toujours sur un coeur
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
2016, la majorité des programmes tournent toujours sur un coeur.
Par exemple, bunziper un gros fichier rends le premier a 100%.
Il faut installer un lbzip2 pour avoir une version qui utilise plusieurs coeurs.
Et c'est d'autant plus triste qu'un changement du scheduler dans le kernel ne changera strictement rien à cette situation.
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par barmic . Évalué à 5.
Une autre fonction importante du scheduler consiste à choisir le niveau d'endormissement des CPU. C'est aussi encore un grand sujet et ça évolue tout le temps avec les améliorations des CPU et ça impact directement les softs qui sont monothreadés.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par mh-cbon . Évalué à -5.
En passant, une question qui vient à l'esprit, est ce que ce n'est pas aussi un problème de format totalement inadapté à cette situation relativement nouvelle ?
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par ʭ ☯ . Évalué à 3.
Bien sûr. D'ailleurs xz pour pouvoir travailler en pipe de tar est aussi mono-cœur.
Par contre p7zip tourne sur plusieurs cœurs, essaye 7z b.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par Yth (Mastodon) . Évalué à 4.
a.tar 278Mo, il s'agit d'un dépôt git
time 7z a a.tar.7z a.tar
real 0m50.126s
user 2m13.483s
sys 0m2.632s
time xz -T 0 a.tar
real 0m56.706s
user 2m44.330s
sys 0m1.092s
ls -al a.tar.*
175703485 a.tar.7z
175622872 a.tar.xz
Bon, 7z est un peu plus rapide, mais xz est multi-threadable aussi.
Ça coince peut-être en pipe de tar, où il redevient mono-thread, mais bon, en mettant le -T 0 dans ton XZOPTS, l'utilisation de xz sans tar va être multi-coeur, et ses performances presque identiques à celles de 7z…
Après on peut discuter de ça :
time xz -T 1 a.tar
real 2m16.947s
user 2m16.357s
sys 0m0.494s
Où le temps processeur réel est significativement plus faible, donc a priori la consommation électrique, sachant qu'un processeur moderne sur un système moderne peut laisser les coeurs inactifs en idle, donc économiser du jus, de la chaleur, donc des ventilos, donc encore du jus.
Si tu as du temps disponible, le multi-threading n'est pas forcément très écologique…
Yth.
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par Dinosaure (site web personnel) . Évalué à 10.
Il faut surtout savoir si une programmation multi-coeur peut potentiellement être intéressante pour la problématique. Utiliser plusieurs cœurs c'est entre autre mettre des lock pour garder l'intégrité de certaines données partagées et ces derniers ont un coût.
Dans le cas de la compression sans perte par exemple, il s'agit de calculer la fréquence des caractères et, dans le cas d'une compression LZ77 (ou dérivé), il s'agit de maintenir un dictionnaire de pattern pour obtenir les distances. L'accès à ces éléments (en écriture principalement) se fait presque à chaque caractère, il s'agirait donc de mettre un lock à chaque fois qu'on lit un caractère. Dans ce contexte, on peut facilement inférer qu'utiliser plusieurs cœurs pour un seul document n'est pas la bonne stratégie - l'idée ensuite qu'on puisse considérer qu'un processus puisse s'occuper de N caractère (et donc locker tout les N caractères) n'est pas envisageable puisque cela invaliderait les distances pour la compression LZ77. On peut toujours trouver des solutions mais qui ne ferait que ralentir l'algorithme en général avec des partages de contexte fastidieux.
Là où l'on peut par contre utiliser le multi-coeur, c'est dès qu'il s'agit de compresser plusieurs documents indépendamment (et de merger ensuite les fréquences obtenues pour générer un arbre de huffman commun) - les distances seront alors limitées au document mais si on se place dans un ratio vitesse/taille, cela reste négligeable.
Se placer dans une problématique multi-coeur de facto n'est pas toujours la bonne solution, il s'agit surtout de cibler le niveau d'atomicité de notre algorithme. Je sais pas si c'est vraiment le bon terme mais dans l'exemple, on peut considérer que chaque document peut être compressé séparément alors qu'on peut difficilement atomiser l'algorithme compressant un document en plusieurs petits algorithmes indépendants. On considère donc l'algorithme comme atomique mais pas ce qu'il compose.
Il est donc normal de voir encore des logiciels mono-coeur car ils seront plus efficaces que si ont se forcé à ce qu'ils utilisent plusieurs cœurs. La problématique reste difficile est elle est au centre de certaines langages hauts niveaux qui souhaiterait abstraire la programmation parallèle. C'est à mettre en opposition au global lock présent dans le garbage collector (comme en Python, JavaScript ou encore OCaml).
Malheureusement, avoir un garbage collector multi-coeur peut amener un coût non négligeable qui pourrait ralentir des programmes mono-coeur (pour assurer la validité des pointeurs entre garbage collector partagé et garbage collector spécifique au cœur utilisé) d'où la réticence de certains développeurs à vouloir absolument intégrer le multi-coeur dans certains langages (comme OCaml). Bien entendu, des efforts sont fait dans le bon sens pour éviter l'overhead imposé.
Tout ça pour dire qu'on aura toujours des programmes mono-coeur :) !
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par steph1978 . Évalué à 4.
En effet, j'aurai dit "granularité"
# Tour d'horizon
Posté par David Marec (site web personnel) . Évalué à 6.
C'est vraiment là une question pertinente; elle est à l'origine du clash entre M.Dillon et le reste de la core-team de FreeBSD qui a conduit à la création de Dragon-fly BSD et de son Light Weight Kernel Threads.
L'ordonnanceur actuel de FreeBSD, ULE, a été introduit dans la branche 5 puis activé dans la 7 pour améliorer le système.
J'avais lu quelques réflexion là dessus dans les bouquins de A.S. Tanenbaum.
Existe-t-il un tour d'horizon sur les solutions trouvées par les différents systèmes ?
Une sorte de liste comparée avec avantages et inconvénients.
D'ailleurs sait-on comment les autres non-libres le gère ? ( Windows, Mac, autre)
[^] # Re: Tour d'horizon
Posté par Sufflope (site web personnel) . Évalué à 10.
D'ailleurs, suite à cette introduction, M.Dillon aurait déclaré « maintenant c'est dans DragonflyBSD qu'il manque ULE ».
[^] # Re: Tour d'horizon
Posté par barmic . Évalué à 3.
La zoophilie est répréhensible. Les modérateurs devraient faire quelque chose contre ce genre de commentaires !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tour d'horizon
Posté par barmic . Évalué à 4.
Vu comment c'est la misère pour tester ça sur un système données, le tester sur des systèmes différents doit être une enfer. Sans compter la complexité des profiles d'utilisation (par exemple avoir un lecteur audio et/ou un navigateur qui tourne en permanence peut être le genre de choses à prendre en compte par le scheduler). On devrait pouvoir avec Linux et les *BSD construire des systèmes minimalistes qui sont à peu prêt reproductibles.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Tour d'horizon
Posté par David Marec (site web personnel) . Évalué à 2.
Sans le tester, est-ce que dans un premier temps, ce serait a minima documenté quelque part ?
# Le scheduler, il est a l'ouest !
Posté par cedric . Évalué à 6.
Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.
Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, …). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.
La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace… Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal… Gros hack, franchement pas terrible.
Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge… Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees…
[^] # Re: Le scheduler, il est a l'ouest !
Posté par xcomcmdr . Évalué à 0.
Raison #3254 pour laquelle je suis retournée sous Windows : le scheduler I/O qui bloque le PC / bouffe tout le CPU, même pour copier un gros fichier sur une clé USB.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le scheduler, il est a l'ouest !
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Tiens marrant, scheduler + énergie est justement le thème d'un récent article LWN:
https://lwn.net/Articles/682391/
"A few years ago, Linux scheduler maintainer Ingo Molnar expressed a strong desire that future improvements in CPU power management should integrate well with the scheduler and not try to work independently."
Lien gratuit si vous n'êtes pas encore abonnés à l'excellent LWN : https://lwn.net/SubscriberLink/682391/1b395639142d1fa3/
# [HS] Titre très romantique
Posté par lolop (site web personnel) . Évalué à 6.
« Linux: une décennie de cœurs gaspillés », ça pourrait donner aussi pour un prochain journal « Linux: des cœurs à prendre ».
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Absence de suite de tests ?
Posté par Antoine . Évalué à 2.
Ce qui frappe ici, c'est qu'il ne semble pas y avoir de procédure de test automatisé de l'ordonnanceur (avec de l'instrumentation pour simuler une configuration matérielle et une certaine succession d'appels de tâches) et que toute expérimentation doive passer par l'exécution réelle, sur un matériel réel, de tâches réelles en temps réel.
Cela empêche aussi de tester sérieusement les régressions, à part en se reposant sur la communauté, ce qui est tout de même très hasardeux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.