salut,
est ce que quelqu'un peut m'expliquer que signifie ça
Le scheduler Linux considère que les threads d'un même programme comme étant des processus à
part entière et il ne prend aucune disposition particulière lors de l'affectation à des coresparticuliers.
Tu es au courant qu'il y a une distinction entre processus (ne partageant pas le même espace d'adressage) et les threads (qui partagent le même espace d'adressage, ils font donc partis du même processus). L'ordonnanceur doit répartir les tâches entre les différents coeurs, le plus simple pour des bidules qui partagent le même espace d'adressage serait de les garder sur le même coeur la grosse difficulté du multi-coeur et justement le partage et la cohérence de la mémoire accédée par plusieurs coeurs. Mais ce serait du gâchi processeur. J'imagine donc que cette phrase exprime que linux n'a pas choisi la méthode la plus simple, est réparti les threads au même titre que les processus sur les différents coeurs disponibles, en se fadant la gestion de la cohérence des zones mémoires partagées.
ah merci bcp, mais je m'excuse je n'ai pas compris la derniere phrase on se fadant!! et pour les bidules ecq vous parlez des thread??
. . . en se fadant . . .Envoyé par sysunic
- en se tapant le boulot de . . .
- en se faisant chier à le faire . . .
- en s'occupant de . . .
- en faisant suer le burnous . . .
- . . .
En même temps, linux laisse un peu perplexe car chaque thread est exécuté au sein d'un processus qui lui est propre.Tu es au courant qu'il y a une distinction entre processus (ne partageant pas le même espace d'adressage) et les threads (qui partagent le même espace d'adressage, ils font donc partis du même processus)
Bonjour,
si vraiment le fait d'utiliser plusieurs coeurs pour le même processeur vous angoisse, vous pouvez toujours bloquer le job sur un coeur particulier, ou sur 2 ou ....
ex:
taskset 1 cmd-de-la-mort-qui-tue --roule-mimille
mais un man taskset vous montrera ce qu'on peut faire (on peut choisir les coeurs un par un).
il y a aussi d'autres astuces mais trop sioux pour que j'ai envie de jouer avec (jusqu'à présent).
chercher thread affinity.
sinon, les thread gérés comme des process, mais partageant la mémoire, c'est relativement sensé, vu que les causes de commutation de tâche sont les mêmes.
le truc ch...t est qu'on ne peut pas mettre un sémaphore dans un select, mais maintenant, il y a les eventfd...
mais là, je m'égare...
Jusqu'ici tout va bien...
Je ne me rappelle plus de la magouille utilisée par linux, mais il me semblait que c'était plutôt l'inverse: un processus est créé en tant que thread, mais n'est promus qu'au moment d'un accès en écriture à la mémoire, un thread étant plus léger a créer qu'un processus. Mais de manière pratique, la grosse distinction entre thread et procesus c'est la visibilité (ou pas) de l'espace mémoire, et cette différence est respectée sous Linux.En même temps, linux laisse un peu perplexe car chaque thread est exécuté au sein d'un processus qui lui est propre.
Hors cas très particulier, c'est en général inefficace, le scheduler sachant mieux que nous le dispatch le plus efficace thread / coeurs, sachant que le compromis sera probablement différent sur une machine différente...Bonjour,
si vraiment le fait d'utiliser plusieurs coeurs pour le même processeur vous angoisse, vous pouvez toujours bloquer le job sur un coeur particulier, ou sur 2 ou ....
Je ne vois que le cas où on veuille réserver un coeur pour quelques choses "temps-réel" et améliorer son "temps de réponse" puisque son cache sera "probablement" déjà chargé avec le code "temps-réel"...
De mémoire, la création de thread entraine celle de processus. Je l'avais vérifié à l'aide d'une simple commande "ps". je retoruvais autant de processus que de threads lancés + 1 pour celui qui contrôlait l'ensemble.Je ne me rappelle plus de la magouille utilisée par linux, mais il me semblait que c'était plutôt l'inverse: un processus est créé en tant que thread
Tout à fait: d'un point de vue fonctionnel, l'implémentation selon linux ne change rien.Mais de manière pratique, la grosse distinction entre thread et procesus c'est la visibilité (ou pas) de l'espace mémoire, et cette différence est respectée sous Linux.
petit oups:
là où j'ai écrit "pour le même processeur", quel que part dans mon cerveau, c'était "pour le même processus", mais vous avez corrigez dans l'interprétation...
bloquer les threads sur un même processeur permet d'empêcher d'en avoir plusieurs actifs vraiment en même temps, ça permet de faire tourner un programme écrit avec des "mutex maison" (au lieu d'utiliser les mutex du système) sans tout faire planter car il faut des read-modify-write atomiques au niveau accès mémoire et non plus seulement au niveau exécution du processeur.
un autre usage est de garder des threads sur le même coin de cache pour éviter des flush de cache coûteux en temps.
un dernier usage pas du tout classique est de garder des processus sur un cpu plus proche d'une ressource de calcul ou ayant un jeu d'instruction spécifique plus performant (truc de tordu sur une archi multiproc non homogène...).
ensuite, pour l'implémentation des thread linux, on peut lire le man 2 clone (qui est une sorte de fork avec beaucoup plus d'options) pour y voir un peu plus clair (ou se noyer...).
on peut voir les thread avec un ps -efL (mais ça vous tapisse l'écran, par exemple, actuellement mon firefox tourne sur 52 threads...)
on peut alors tuer un thread sans tuer directement le process principal.
sur d'autres systèmes, il existe dans les api une notion de fiber (un genre de thread privé qu'on lâche volontairement seulement), on les retrouve dans divers interpreteurs avec les coroutines et autres concepts de parallélisme volontaire.
sous linux, on peut le coder avec des setjmp/longjmp ou utiliser une lib toute faite par exemple libBoost.Coroutine.
le fait de switcher volontairement permet d'éviter des aller/retour dans le système, ce qui fait gagner du temps, mais il faut bien comprendre le concept et réfléchir avant de foncer bille en tête...
Jusqu'ici tout va bien...
Pour m'être amusé une fois à gérer l'affinité des threads à la main et de comparer l'efficacité avec le scheduler, j'ai l'impression qu'il gère ça très bien (donc à priori mieux qu'un humain)un autre usage est de garder des threads sur le même coin de cache pour éviter des flush de cache coûteux en temps.
Je n'ai jamais croisé d'archi comme ça, tu as un exemple ? Des coeurs DSP noyés dans un processeur oui, mais alors ils ne peuvent pas faire tourner n'importe quel code, ils sont vus plutôt comme des "périphériques".un dernier usage pas du tout classique est de garder des processus sur un cpu plus proche d'une ressource de calcul ou ayant un jeu d'instruction spécifique plus performant (truc de tordu sur une archi multiproc non homogène...).
Je vais peut-être dire une connerie (je ne connais pas le concept de coroutine), mais le setjump/longjump c'est la partie changement de contexte, si tu le fais à la main, tu insères toi même les points de préemption de tes pseudo-thread. Ce qui évite les passages espace utilisateur <-> espace noyau pour le scheduling au prix de la gestion manuel du scheduling ?sous linux, on peut le coder avec des setjmp/longjmp [...] le fait de switcher volontairement permet d'éviter des aller/retour dans le système
Je n'oserais même pas tenter...
En fait, le taskset, je m'en susi servi uniquement pour faire tourner un vieux binaire récalcitrant sur un multiproc...
En effet, j'avais bien mis "truc de tordu...".Je n'ai jamais croisé d'archi comme ça, tu as un exemple ? Des coeurs DSP noyés dans un processeur oui, mais alors ils ne peuvent pas faire tourner n'importe quel code, ils sont vus plutôt comme des "périphériques".
les setjmp/longjmp sont au départ prévu pour sauvegarder un point "stable" du programme sur lequel on peut revenir suite à un ctrl-c par exemple si on estime qu'un calcul est trop long ou divergeant.Je vais peut-être dire une connerie (je ne connais pas le concept de coroutine), mais le setjump/longjump c'est la partie changement de contexte, si tu le fais à la main, tu insères toi même les points de préemption de tes pseudo-thread. Ce qui évite les passages espace utilisateur <-> espace noyau pour le scheduling au prix de la gestion manuel du scheduling ?
pour sauter d'une pile à l'autre, il faut en plus en créer à la main y basculer, etc... Il faut être familier avec le processeur et le compilateur.
(en fait, la dernière fois que j'ai fais ça, il n'y avait pas de thread dans le UNIX que j'utilisais, c'est dire si ça date...)
Jusqu'ici tout va bien...
C'était conceptuellement fastoche, un thread de réception UDP remplissant un buffer, ce dernier étant écrit sur le DD par un autre thread, le tout multiplier par le nb de canaux à réceptionner (max 8), je m'étais démerdé pour que rx UDP et écriture DD soit associer au même coeur, et une paire de thread par coeur... Il y avait plus de perte de datagrammes que si je laissais le scheduler gérer...Je n'oserais même pas tenter...
La dernière implémentation du setjmp/longjmp que j'ai croisée sauvegardai bien le contexte (donc les registres dont le pointeur de pile), et vice versa... Je m'en suis servi pour porter FreeRTOS pour le nouveau compilateur GCC pour MSP430, mais je confirme c'est du très bas niveau, il m'a fallu quasi un mois de bibliographie pour savoir d'où partir...les setjmp/longjmp sont au départ prévu pour sauvegarder un point "stable" du programme sur lequel on peut revenir suite à un ctrl-c par exemple si on estime qu'un calcul est trop long ou divergeant.
pour sauter d'une pile à l'autre, il faut en plus en créer à la main y basculer, etc... Il faut être familier avec le processeur et le compilateur.
D'essayer, oui... d'y arriver, c'est ça que je ne prétends pas savoir faire...
En fait, tu as sans doute provoqué plus de cache miss sur le code en mettant les 2 thread sur le même core.
coté data, de toute façon, ça devait entrer et sortir, tu aurais peut-être dû mettre la boucle des socket read sur un coeur et celle des dd write sur un autre...
"sans doute" et "peut-être" étant les mots les plus importants.
Jusqu'ici tout va bien...
L'idée était d'avoir la donnée sur le même coeur pour éviter les cache-miss sur les données. Le goulet d'étranglement étant côté interruption réseau (il a fallu passer MTU > 1500 pour avoir 1 datagramme = 1 interruption). Ceci dit j'ai essayé un peu toutes les configurations, sans arriver à faire mieux que le scheduler...coté data, de toute façon, ça devait entrer et sortir, tu aurais peut-être dû mettre la boucle des socket read sur un coeur et celle des dd write sur un autre...
On empile des couches de complexités logicielles sur des couches de complexités matérielles, je trouve bien difficile de nos jours de prévoir des perf, où même quelle stratégie pour de bonne perf..."sans doute" et "peut-être" étant les mots les plus importants.
au fait, si c'est un transfert pur et dur entre 2 fd, il y a splice qui évitent de passer les datas en userland (mais il faut un pipe au milieu)...
https://lwn.net/Articles/178199/
http://ogris.de/howtos/splice.html
et puis il y a sendfile pour aller du fichier au socket...
http://blog.superpat.com/2010/06/01/...le-and-splice/
bref, on peut encore (essayer de) gratter un peu de perf...
Jusqu'ici tout va bien...
Merci du tuyau (pipe)... Malheureusement il fallait faire pas mal de chose entre la réception et l'enregistrement... m'aurait embêté de faire un pilote pour ça...au fait, si c'est un transfert pur et dur entre 2 fd, il y a splice qui évitent de passer les datas en userland (mais il faut un pipe au milieu)...
mais comment perçoit le scheduler CFS d'unix les différents hardware threads et cores du processeur??
je comprend pas comment perçoit le sheduler CFS d'unix les differents hardware threads et cores du processeur??
Dans quelle partie du code du kernel (version du kernel, nom du fichier et lignes) ? ? ?
sinon, le kernel n'est pas ignorant des ressources dispos...
pour les processeurs, tu peux même le vérifier en une ligne de commande:
cat/proc/cpuinfo
en cherchant un peu, tu connais le nombre des cores et de "thread-sauce-intel"...
et comme ils ne sont pas manchot, chez les pingouins, ils exploitent ces infos...
Jusqu'ici tout va bien...
comme tu as ouvert un autre fil sur ce sujet, c'est là-bas qu'il faut continuer ...
(attention aux doublons, ça fiche le bazar et ça n'est pas bien vu...)
Jusqu'ici tout va bien...
non je veux dire comment il considère les hardware threads et cores comme étant des processeurs a part entière!!!
non je veuux dire comment il considère les hardware threads et cores comme étant des processeurs a part entière!!!
et moi, je veux dire que faire des doublons c'est MAL VU ! ! !
Jusqu'ici tout va bien...
mais sans autre précisions claires sur ta demande, on ne peut rien dire...
Jusqu'ici tout va bien...
Bonsoir à tous
Je confirme.
Les deux discussions sont fusionnées.
Dernière modification par gienas ; 03/06/2016 à 17h38.
