Entonces, después de un tiempo encontré la solución. De hecho, Anthon tiene razón, es el subsistema ACPI el que envía interrupciones. En mi system deshabilité las siguientes interrupciones y el hilo de trabajo se calmó.
echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08
Sin embargo, hasta ahora no he identificado cuáles son las IRQ falsas que provienen de gpe08 y gpe1B .
(Me parece que esto está bastante fuera de tema aquí, pero aquí está la respuesta que publiqué en unix.stackexchange.com).
Encontré este hilo en lkml que responde un poco a tu pregunta. (Parece que incluso el propio Linus estaba desconcertado sobre cómo averiguar el origen de esos hilos).
Básicamente, hay dos formas de hacer esto:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
Para esto necesitará que se compile ftrace en su kernel.
Esto mostrará lo que están haciendo todos los subprocesos y es útil para rastrear múltiples trabajos pequeños.
cat /proc/THE_OFFENDING_KWORKER/stack
Esto generará la pila de un solo hilo haciendo mucho trabajo. Puede permitirle averiguar qué causó que este subproceso específico acaparara la CPU (por ejemplo). THE_OFFENDING_KWORKER es el pid del kworker en la lista de procesos.