Donc, après un certain temps, j'ai trouvé la solution. En fait Anthon a raison, c'est le sous-système ACPI qui envoie les interruptions. Sur mon J'ai désactivé les interruptions suivantes et le thread kworker s'est calmé.
echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08
Cependant, jusqu'à présent, nous n'avons pas identifié les fausses IRQ provenant de gpe08 et gpe1B .
(Il me semble que c'est plutôt hors sujet ici, mais voici la réponse que j'ai publiée sur unix.stackexchange.com.)
J'ai trouvé ce fil sur lkml qui répond un peu à votre question. (Il semble que même Linus lui-même était perplexe quant à la façon de découvrir l'origine de ces fils.)
Fondamentalement, il existe deux façons de procéder :
$ 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 que ftrace soit compilé dans votre noyau.
Cela affichera ce que font tous les threads et est utile pour tracer plusieurs petits travaux.
cat /proc/THE_OFFENDING_KWORKER/stack
Cela produira la pile d'un seul thread faisant beaucoup de travail. Cela peut vous permettre de découvrir ce qui a causé ce thread spécifique à monopoliser le CPU (par exemple). THE_OFFENDING_KWORKER est le pid du kworker dans la liste des processus.