Le scheduler Linux Unix ...
Répondre à la discussion
Affichage des résultats 1 à 26 sur 26

Le scheduler Linux Unix ...



  1. #1
    invitef8fdcbb2

    Le scheduler Linux Unix ...


    ------

    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.

    -----

  2. #2
    inviteb9f49292

    Re : Le scheduler Linux

    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.

  3. #3
    invitef8fdcbb2

    Re : Le scheduler Linux

    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??

  4. #4
    antek

    Re : Le scheduler Linux

    Citation Envoyé par sysunic Voir le message
    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 . . .
    - en se tapant le boulot de . . .
    - en se faisant chier à le faire . . .
    - en s'occupant de . . .
    - en faisant suer le burnous . . .
    - . . .

  5. A voir en vidéo sur Futura
  6. #5
    Jack
    Modérateur

    Re : Le scheduler Linux

    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)
    En même temps, linux laisse un peu perplexe car chaque thread est exécuté au sein d'un processus qui lui est propre.

  7. #6
    polo974

    Re : Le scheduler Linux

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

  8. #7
    inviteb9f49292

    Re : Le scheduler 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.
    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.

  9. #8
    inviteb9f49292

    Re : Le scheduler Linux

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

  10. #9
    Jack
    Modérateur

    Re : Le scheduler Linux

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

    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.
    Tout à fait: d'un point de vue fonctionnel, l'implémentation selon linux ne change rien.

  11. #10
    polo974

    Re : Le scheduler 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...

  12. #11
    inviteb9f49292

    Re : Le scheduler Linux

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

    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 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 ?

  13. #12
    polo974

    Re : Le scheduler Linux

    Citation Envoyé par lou_ibmix_xi Voir le message
    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)
    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...
    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".
    En effet, j'avais bien mis "truc de tordu...".
    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 ?
    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.
    (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...

  14. #13
    inviteb9f49292

    Re : Le scheduler Linux

    Je n'oserais même pas tenter...
    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...

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

  15. #14
    polo974

    Re : Le scheduler Linux

    Citation Envoyé par lou_ibmix_xi Voir le message
    C'était conceptuellement fastoche,...
    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...

  16. #15
    inviteb9f49292

    Re : Le scheduler Linux

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

    "sans doute" et "peut-être" étant les mots les plus importants.
    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...

  17. #16
    polo974

    Re : Le scheduler Linux

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

  18. #17
    inviteb9f49292

    Re : Le scheduler Linux

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

  19. #18
    invitef8fdcbb2

    Re : Le scheduler Linux

    mais comment perçoit le scheduler CFS d'unix les différents hardware threads et cores du processeur??

  20. #19
    invitef8fdcbb2

    scheduler unix

    je comprend pas comment perçoit le sheduler CFS d'unix les differents hardware threads et cores du processeur??

  21. #20
    polo974

    Re : scheduler unix

    Citation Envoyé par sysunic Voir le message
    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...

  22. #21
    polo974

    Re : Le scheduler Linux

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

  23. #22
    invitef8fdcbb2

    Re : Le scheduler Linux

    non je veux dire comment il considère les hardware threads et cores comme étant des processeurs a part entière!!!

  24. #23
    invitef8fdcbb2

    Re : scheduler unix

    non je veuux dire comment il considère les hardware threads et cores comme étant des processeurs a part entière!!!

  25. #24
    polo974

    Re : Le scheduler Linux

    et moi, je veux dire que faire des doublons c'est MAL VU ! ! !
    Jusqu'ici tout va bien...

  26. #25
    polo974

    Re : scheduler unix

    mais sans autre précisions claires sur ta demande, on ne peut rien dire...
    Jusqu'ici tout va bien...

  27. #26
    gienas
    Modérateur

    Re : Le scheduler Linux

    Bonsoir à tous

    Citation Envoyé par polo974 Voir le message
    ... faire des doublons c'est MAL VU ! ! !

    Je confirme.

    Les deux discussions sont fusionnées.
    Dernière modification par gienas ; 03/06/2016 à 16h38.

Discussions similaires

  1. unix ou linux sa mémoire
    Par invite4de3cfb3 dans le forum Logiciel - Software - Open Source
    Réponses: 2
    Dernier message: 18/02/2009, 12h26
  2. unix et linux
    Par invitefacf0d25 dans le forum Logiciel - Software - Open Source
    Réponses: 8
    Dernier message: 07/03/2007, 16h15
  3. Linux, Gnu/unix
    Par invitec35bc9ea dans le forum Logiciel - Software - Open Source
    Réponses: 2
    Dernier message: 05/02/2007, 23h35
  4. Linux / Unix ???
    Par invitea301fcd6 dans le forum Logiciel - Software - Open Source
    Réponses: 15
    Dernier message: 23/05/2006, 15h42
  5. Linux vs Unix
    Par invite3ef81541 dans le forum Logiciel - Software - Open Source
    Réponses: 6
    Dernier message: 19/02/2004, 15h41
Dans la rubrique Tech de Futura, découvrez nos comparatifs produits sur l'informatique et les technologies : imprimantes laser couleur, casques audio, chaises gamer...