Journal : Linux: Une Décennie De Coeurs Gaspillés Posté Par Pmoret (Page Perso) Le 08/04/16 À 09:30

Journal : Linux: une décennie de coeurs gaspillés Posté par pmoret (page perso) le 08/04/16 à 09:30. Licence CC by-sa Tags : linux, scheduler 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 le 08/04/16 à 10:13. Évalué à -8 (+11/-15).

+1 à main levée, comme je n'ai plus de droit de vote ; )

Re: Energy waste is proportional. Posté par Dr. Frank N. Furter le 08/04/16 à 10:21. Évalué à 8 (+6/-0).

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 le 08/04/16 à 10:29. Évalué à -6 (+4/-6).

Pour pouvoir écrire un journal, dans le wiki ou sur la tribune, il faut avoir un karma supérieur strictement à 0 (sources journal, wiki, tribune).

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 Dr. Frank N. Furter le 08/04/16 à 10:48. Évalué à 9 (+7/-0).

[…]Le karma augmente donc lorsque l'on reçoit des notes « pertinent » (quel que soit le type de contenu ou le commentaire noté) ou que l'on publie des dépêches.

J'aimerais bien connaitre ma valeur de karma.

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 le 08/04/16 à 10:20. Évalué à 10 (+7/-0).

D'aucuns pensaient que l'ordonnancement (scheduling) était un problème résolu ou presque. Linus Torvals disait en 2001:

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 W). 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 ! :)

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

However, they must be able to steal from the more loaded cores on other nodes. Posté par mh-cbon le 08/04/16 à 10:40. Évalué à -9 (+1/-6).

Why is this not the case? Remember that to limit algorithmic complexity, the load balancing algorithm uses a hierarchical design. When a core attempts to steal work from another node, or, in other words, from another scheduling group, it does not examine the load of every core in that group, it only looks at the group’s average load (line 11 of Algorithm 1). If the average load of the victim scheduling group is greater than that of its own, it will attempt to steal from that group; otherwise it will not. This is the exact reason why in our situation the underloaded cores fail to steal from the overloaded cores on other nodes. They observe that the average load of the victim node’s scheduling group is not any greater than their own. The core trying to steal work runs on the same node as the high-load R thread; that thread skews up the average load for that node and conceals the fact that some cores are actually idle. At the same time, cores on the victim node, with roughly the same average load, have lots of waiting threads.

Re: However, they must be able to steal from the more loaded cores on other nodes. Posté par ʭ ☯ (page perso) le 08/04/16 à 10:51. Évalué à -2 (+0/-4).

Même traduit automatiquement ça ne devient pas compréhensible en français ;-)

Pourquoi est-ce pas le cas? Rappelez-vous que pour limiter la complexité algorithmique, la charge algorithme d'équilibrage utilise une conception hiérarchique. Quand un noyau les tentatives de voler le travail d'un autre noeud, ou, en d'autres termes, d'un autre groupe de planification, il ne porte pas sur la charge de chaque noyau de ce groupe, il ne regarde que le groupe de charge moyenne (ligne 11 de l'algorithme 1). Si la charge moyenne du groupe de planification de la victime est supérieure à celle de son propre, il va tenter de voler de ce groupe; sinon ne sera pas. Ceci est la raison exacte pour laquelle dans notre situation, la noyaux sous-charge ne parviennent pas à voler les noyaux surchargés sur d'autres nœuds. Ils observent que la charge moyenne de la victime noeuds groupe de planification est pas plus grande que leur posséder. Le noyau essayant de voler le travail fonctionne sur le même noeud le R-fil de charge élevée; ce fil biaise la moyenne charger pour ce noeud et cache le fait que certains noyaux sont effectivement ralenti. Dans le même temps, les noyaux sur le noeud victime, avec à peu près la même charge moyenne, ont beaucoup d'attente threads.

⚓ À g'Auch TOUTE! http://agauch.online.fr

Re: However, they must be able to steal from the more loaded cores on other nodes. Posté par mh-cbon le 08/04/16 à 11:13. Évalué à -7 (+1/-4).

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

Projects each element of an observable sequence into a new sequence of observable sequences by incorporating the element's index and then transforms an observable sequence of observable sequences into an observable sequence producing values only from the most recent observable sequence.

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.

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.

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.

All of these algorithms (le papier en cite plusieurs pour diverses optimisations) showed positive benefits, either in terms of performance or power, for some real applications. However, few of them were adopted in mainstream operating systems, mainly because it is not clear how to integrate all these ideas in scheduler safely.

Pour réussir ce véritable défi, le papier préconise de commencer par se doter d'outils de visualisation.

Another lesson we learned as a result of this work is the crucial importance of visualization tools. Understanding the root causes of the bugs we described would not have been possible without visualization of the execution events relevant to the problem.

et le yakafonkon qui va bien pour aller plus loin

What we need is to rethink the architecture of the scheduler, since it can no longer remain a small, compact and largely isolated part of the kernel. We now understand that rapid evolution of hardware that we are witnessing today will motivate more and more scheduler optimizations. The scheduler must be able to easily integrate them, and to have a way of reasoning about how to combine them. We envision a scheduler that is a collection of modules: the core module and optimization modules.

lire aussi,

There were algorithms that scheduled threads so as to minimize contention for shared caches, memory controllers and multithreaded CPU pipelines [8, 9, 24, 29, 34, 42, 46]. There were algorithms that reduced communication distance among threads sharing data [41] and de- termined the optimal number of cores to allocate to multithreaded workloads [17]. There were algorithms that ad- dressed the scheduling of threads on asymmetric multicore CPUs [22, 35] and algorithms that integrated scheduling with the management of power and temperature [19]. Fi- nally, there were algorithms that managed the memory on NUMA systems, which was closely tied to how threads are being scheduled [7, 14, 18, 38], and algorithms that scheduled threads to minimize communication latency on systems with an asymmetric interconnect

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 le 08/04/16 à 11:31. Évalué à 4 (+1/-0).

tenter le en traduisant observable par sujet, vous allez voir c'est pas fun ; )

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 ! ;)

Ceci dit, c'était surtout pour réagir à ceci, mais la citation était mal choisie.

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).

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Re: However, they must be able to steal from the more loaded cores on other nodes. Posté par mh-cbon le 08/04/16 à 11:38. Évalué à -7 (+2/-5).

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 ʭ ☯ (page perso) le 08/04/16 à 13:37. Évalué à 3 (+1/-0).

ce qu'il ce se fait de mieux…

Pour le plaisir ;-)

⚓ À g'Auch TOUTE! http://agauch.online.fr

Et Paf! Posté par ʭ ☯ (page perso) le 08/04/16 à 10:31. Évalué à 2 (+0/-0). Dernière modification le 08/04/16 à 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://agauch.online.fr

Re: Et Paf! Posté par barmic le 08/04/16 à 11:04. Évalué à 5 (+2/-0).

C'est un bi-cœur, et il n'a aucun problème avec du stress -c 20. Alors quoi?

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,

cgcreate -a barmic:barmic -t barmic:barmic -g "cpu:/clementin" #cgset -r cpu.shares=256 "clementin" si tu veux changer son temps de partage du CPU

puis :

cgexec -g "cpu:/clementin" clementine

Par contre j'ai pas compris :

si je tue la mémoire disponible (SWAP en remplissage à fond)

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Re: Et Paf! Posté par ʭ ☯ (page perso) le 08/04/16 à 13:44. Évalué à 3 (+1/-0).

Par contre j'ai pas compris : si je tue la mémoire disponible (SWAP en remplissage à fond)

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://agauch.online.fr

Re: Et Paf! Posté par Nicolas Boulay le 08/04/16 à 11:26. Évalué à 3 (+1/-0).

"- si je convertis des fichiers audio avec soundKonverter, même pour un seul fichier à la fois."

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 le 08/04/16 à 14:13. Évalué à 2 (+0/-0).

Alors quoi?

Alors merci Pulseaudio…

2016, la majorité des programmes tournent toujours sur un coeur Posté par Benjamin Henrion (page perso) le 08/04/16 à 11:31. Évalué à 2 (+2/-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 le 08/04/16 à 11:37. Évalué à 5 (+2/-0).

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.

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Re: 2016, la majorité des programmes tournent toujours sur un coeur Posté par mh-cbon le 08/04/16 à 12:05. Évalué à -5 (+2/-3).

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 ʭ ☯ (page perso) le 08/04/16 à 13:42. Évalué à 3 (+1/-0).

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://agauch.online.fr

Re: 2016, la majorité des programmes tournent toujours sur un coeur Posté par Yth le 08/04/16 à 15:00. Évalué à 2 (+0/-0).

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 (page perso) le 08/04/16 à 15:09. Évalué à 4 (+3/-0).

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 :) !

Tour d'horizon Posté par DavidMarec (page perso) le 08/04/16 à 14:38. Évalué à 2 (+1/-0).

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 W.

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 (page perso) le 08/04/16 à 14:53. Évalué à 5 (+3/-0).

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.

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 le 08/04/16 à 15:04. Évalué à 4 (+1/-0).

La zoophilie est répréhensible. Les modérateurs devraient faire quelque chose contre ce genre de commentaires !

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

Re: Tour d'horizon Posté par barmic le 08/04/16 à 15:08. Évalué à 3 (+0/-0).

D'ailleurs sait-on comment les autres non-libres le gère ? ( Windows, Mac, autre)

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.

Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

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