Tak jsem po nějaké době našel řešení. Ve skutečnosti má Anthon pravdu, je to subsystém ACPI, který posílá přerušení. Na můj systém Zakázal jsem následující přerušení a kworker-thread se uklidnil.
echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08
Doposud jsme však nezjistili, jaká falešná IRQ pocházejí z gpe08 a gpe1B .
(Zdá se mi, že je to zde poněkud mimo téma, ale zde je odpověď, kterou jsem zveřejnil na unix.stackexchange.com.)
Našel jsem toto vlákno na lkml, které trochu odpovídá na vaši otázku. (Zdá se, že i sám Linus byl zmatený, jak zjistit původ těchto vláken.)
V zásadě existují dva způsoby, jak to udělat:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
K tomu budete potřebovat, aby byl ftrace zkompilován ve vašem jádře.
Toto vypíše, co všechna vlákna dělají, a je to užitečné pro sledování několika malých úloh.
cat /proc/THE_OFFENDING_KWORKER/stack
Tím se vypíše zásobník jednoho vlákna, který odvede spoustu práce. Může vám to umožnit zjistit, co způsobilo, že toto konkrétní vlákno zapíchlo CPU (například). THE_OFFENDING_KWORKER je pid kworker v seznamu procesů.