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 !!
Journal Kernel 2.6 / Gestion du multi-thread
11
déc.
2003
# Re: Kernel 2.6 / Gestion du multi-thread
Posté par mathieu mathieu (site web personnel) . Évalué à 2.
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 Yannick Beynet (site web personnel) . Évalué à 3.
Peut être est-ce du principalement au fait que la structure de /proc a pas mal changé ...
Si quelqu'un peut confirmer ...
[^] # Re: Kernel 2.6 / Gestion du multi-thread
Posté par ckyl . Évalué à 5.
"Resource usage reported to the parent (CPU time, wall time, page faults,
etc.) are reported for the entire process and not just the initial thread."
J'ai pas de machine qui tourne actuellement en NTPL et je ne m'avancerais pas plus :-)
# Re: Kernel 2.6 / Gestion du multi-thread
Posté par Guinns . Évalué à 6.
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 Yannick Beynet (site web personnel) . Évalué à 2.
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 ckyl . Évalué à 4.
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 Guinns . Évalué à 1.
[^] # Re: Kernel 2.6 / Gestion du multi-thread
Posté par Schwarzy . Évalué à 3.
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 Émilien Kia (site web personnel) . Évalué à 0.
Un jour libre ?
[^] # Re: A propos du Kernel 2.6
Posté par BdherVil . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.