Journal Kernel 2.6 / Gestion du multi-thread

Posté par (page perso) .
Tags : aucun
0
11
déc.
2003
Cher journal,
je sais que la gestion des thread a changé sous le kernel 2.6 L'un des effets de ce changement est que (chez moi en tout cas) les processus multi-thread n'apparaissent plus plusieurs fois quand je fais une commande du style : ps, top, pstree, ...
Par contre, un truc un peu pénible est que si l'un des thread d'un de mes processus consomme bcp de CPU et que ce thread n'est pas le principal , mes indicateurs systèmes habituels (top par exemple) ne m'indiquent pas le processus responsable de cette forte consommation ...

Bon, je ne sais pas si j'ai clairement expliqué mon problème, avis aux amateurs !!
  • # Re: Kernel 2.6 / Gestion du multi-thread

    Posté par (page perso) . Évalué à 2.

    C'est très clair!!!
    ca parait bizarre tout de même.

    As tu essayé avec des paramètres du genre 'attach' ou autre pour voir si cela avait une influence?
    Je ne sais pas si c'est hors sujet, je ne connais que la lib pthread ...
  • # Re: Kernel 2.6 / Gestion du multi-thread

    Posté par (page perso) . Évalué à 6.

    C'est tout à fait normal !
    C'est justement ce qui était repproché aux "linux threads".
    Avant, les threads et les process passaient par une implémentation identique qui était la fonction clone() appellée avec différents paramètres (pour savoir ce qui sera partagé/recopié entre le process père et le fils).
    Donc créer un thread revenait à créer un process un peu particulier.

    Or désormais (et tel que POSIX le défini) les threads et les process ont chacun une implémentation propre et différente. Et tous les threads tournent dans un seul process (donc "ps" n'en affiche qu'un) ; c'est bcp mieux car conforme POSIX, et de plus l'implémentation des threads est bcp plus optimisée (car spécialisée) et donc bcp plus performante.

    Vala
    • [^] # Re: Kernel 2.6 / Gestion du multi-thread

      Posté par (page perso) . Évalué à 2.

      Oui sauf que y a un problème (chez moi en tout cas) au niveau de la conso cpu qu'utilise ce process.
      Si tu veux un exemple : je demande a mozilla de charger une page que je sais être pourrie (ie qui va consommer bcp de cpu). D'apres mon top (debian sid) je consomme 99% du cpu (user), mais il m'affiche que mozilla n'en consomme que 0,3 %. Quand je switch sur un kernel 2.4, j'ai l'explication, le thread consommant du cpu n'etait pas le principal.
      Conclusion, chez moi le temps cpu affiché pour les processus multi-thread n'est pas la somme des temps cpu de chaque thread, mais seulement celui du main-thread.
      • [^] # Re: Kernel 2.6 / Gestion du multi-thread

        Posté par . Évalué à 4.

        idee : peut etre mettre a jour procps ?

        J'ai vu dans le changelog des adaptations a NTPL qui a change au passage /proc (les threads non principaux sont en .pid dans /proc).
      • [^] # Re: Kernel 2.6 / Gestion du multi-thread

        Posté par (page perso) . Évalué à 1.

        bin ca c'est p'tet un bug à mentionner à kernel.org ...
      • [^] # Re: Kernel 2.6 / Gestion du multi-thread

        Posté par . Évalué à 3.

        C'est (presque) normal: top affiche le main-thread du processus. Celui-ci ne fait rien donc il n'a pas a afficher les temps CPU des autres thread.

        De mon point de vue, c'est top qui n'est pas a jour sur la nouvelle facon de gere les thread sur les kernels 2.6. C'est a top de cumuler les temps CPU des threads.

        En interne, le noyau a toujours une notion de processus. La difference entre le 2.4 le 2.6 est dans le report des activites des processus en userspace. [et de la creation des threads aussi mais c'est pas le propos]. Avec le 2.4, tous les threads etaient presente avec le processus associe dans le noyau. Avec le 2.6, le noyau garde l'information qu'un nouveau "processus" est un thread d'un autre processus et ne le reporte pas en processus independant via /proc. seul le thread principal (le "1er", le papa) est reporte.

        Perso, je trouve pas ca tres propre. D'autres Unix cumulent les ressources des threads pour les presenter en un processus ce qui est plus rationnel (d'ou ce journal d'ailleurs). Linux a delegue la tache de cumul aux outils en userspace. Mais il est possible que je me trompe et que cela soit aussi les outils des autres unix qui font le cumul.

        top rapporta surement les temps CPU des processus dans une prochaine version et non du fil principal [une option pour les afficher serait bienvenue toutefois].

        ps: J'ai regarde ps et il reporte correctement les threads si on lui demande (option -L, -T ou -m a rajouter suivant la nature de la hierachie voulue).

        (desole pour les accents ils veulent pas venir :( )
  • # A propos du Kernel 2.6

    Posté par (page perso) . Évalué à 0.

    Pendant qu'on parle du kernel 2.6, est-ce que quelqu'un pourrais m'indiquer si ya des dates de prévues ou tout au moins une roadmap datée pour la sortie du kernel 2.6 ?

    Un jour libre ?

    • [^] # Re: A propos du Kernel 2.6

      Posté par . Évalué à 3.

      les roadmaps, c'est bon pour le maketting. Sinon, avec l'éxpèrience du 2.4 on peut esperer que le 2.6 sort aux alentours de quand il sera prêt !!!

Suivre le flux des commentaires

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