L'origine d'un kworker-fil

Sur mon système nouvellement installé à l'aide du noyau 3.2, je vois un kworker-fil qui est constamment consommatrices de CPU. J'aimerais savoir quelle partie de noyau/module a créé cette workqueue.

Comment suivre un kworker-thread nommé par exemple "kworker/0:3 à son origine dans le noyau de l'espace?

J'ai essayé de regarder dans /sys/kernel/debug/traçage/événements/workqueue, mais n'était pas en mesure de le comprendre.

  • Vous pouvez demander à ce sur askubuntu
  • Le kworker processus de poignées ACPI appels de réveil depuis le BIOS. Les anciens noyaux ( < 2.6.35 IIRC ) ne semblent pas les avoir (au moins pas mon portable avec 2.6.32 ).
  • peut-être, mais ma question n'a rien à voir avec Ubuntu.
  • Alors peut-être que utilisateur. De toute façon, stack overflow est pour les questions de programmation. Ce n'est pas une question de programmation.
InformationsquelleAutor Patrick B. | 2012-06-01
  1. 18

    (Me semble que c'est plutôt hors sujet ici, mais voici la réponse j'ai posté sur unix.stackexchange.com.)

    J'ai trouvé ce fil de discussion sur la lkml qui répond à votre question un peu. (Il semble même Linus lui-même était perplexe quant à la façon de découvrir l'origine de ces threads.)

    Fondamentalement, il existe deux façons de le faire:

    $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)

    Pour cela, vous aurez besoin ftrace être compilé dans le noyau.

    Ce sera de sortie ce que les fils sont tous de faire, et est utile pour le suivi de multiples petits boulots.

    cat /proc/THE_OFFENDING_KWORKER/stack

    Ce sera la sortie de la pile d'un thread unique, fait beaucoup de travail. Il peut vous permettre de trouver ce qui a causé ce thread spécifique de porc de la CPU (par exemple). THE_OFFENDING_KWORKER est le pid du kworker dans la liste des processus.

    InformationsquelleAutor anarcat
  2. 7

    Alors, après quelques temps j'ai trouvé la solution. En fait Anthon est de droite, c'est l'ACPI sous-système qui envoie des interruptions. Sur mon système j'ai désactivé la suite les interruptions et les kworker-fil est calmé.

    echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08

    Cependant, jusqu'à présent n'ont pas identifié ce que le faux Irq venant de gpe08 et gpe1B.

    • comment êtes-vous arrivé à l'un de ces interruptions?
    • IIRC, de la force brute. Quelque part, j'ai trouvé que la source de ces kworkers sont dans l'acpi sous-système et puis j'ai désactivé un gpe après l'autre et que les deux ont un effet.
    • vous pouvez exécuter la commande grep . -r /sys/firmware/acpi/interruptions/ pour obtenir une liste des interruptions avec le nombre de fois que chacun a été déclenchée. Ceux avec de grandes valeurs sont probablement les problématiques.
    InformationsquelleAutor Patrick B.
  3. 3

    kworker /watchdog, causant une importante charge régulièrement lorsqu'il n'est pas sur le câble d'alimentation - solution de contournement

    Avait kworker (cause kernel_thread_helper+0x6/0x10 ?) 1 fil de dopage à 100% de cpu pendant 1 seconde toutes les 5 secondes seulement si l'ordinateur portable alimenté par le câble. Pas de problèmes sur l'alimentation de la batterie. N'a pas d'importance si la batterie complètement chargée.

    Plus ou moins sorti de la bleue, donc je suppose que la récente mise à jour de Ubuntu a été la cause (3.2.0-55-generic-pae maintenant).

    Était à la recherche pour une demi-journée, à essayer de comprendre wft la cause racine est et endet essayer de désactiver tous les acpi interruptions, qui n'a pas d'importance.

    Ajoutant GRUB_CMDLINE_LINUX_DEFAULT=”acpi=off” à /etc/defaults/grub a contribué à la fin.

    Que j'ai découvert droit maintenant, je l'ai ajouté avec ces spéciaux unicode citations, ce qui pourrait expliquer l'incompatibilité avec le "quiet splash" (par défaut guillemets) qui me laisse perplexe. J'ai regarder dans plus de grub questions (menu de démarrage ne s'affiche pas mais je fais, entrée par défaut config pas utilisé ...) donc, je vais laisser que les tests pour plus tard.

    PS: une semaine plus tard, le problème est de retour (sans redémarrer, seulement suspendre entre les deux). Il pourrait y avoir une corrélation à l'aide d'une souris usb. Alimentation/power aidé (redémarrage n'a pas). Jeté toutes les options de grub loin. Je m'attends à ce que le problème de montrer à nouveau peu de temps.

    PPS: il a Pris un peu de temps (une demi-année), mais il est de retour après un résumé de la ram. Pas de mises à jour récentes, juste de brancher/débrancher l'alimentation, comme je le fais souvent. Pas de périphériques USB branché/débranché. Avait un totem en cours d'exécution (mais rien à jouer) durant la veille. Alimentation/alimentation avec câble d'alimentation branché ne pas l'aide, de l'alimentation/de puissance avec câble d'alimentation débranché fait.

    InformationsquelleAutor axm
  4. -4

    kworker est un thread du noyau qui traite workqueues.Ce thread est créé dans le fichier linux/kernel/workqueue.c fichier.

    • Il est évident à partir de la question qu'il sait déjà kworker est liée à workqueues, et veut savoir quelle partie du noyau est responsable de sa consommation de CPU. Pointant vers workqueue.c est inutile.
    InformationsquelleAutor mohanreddykv