Origin of a kworker-thread

Question

On my newly installed system using kernel 3.2 I see a kworker-thread which is constantly consuming CPU. I'd like to find out which part of kernel/module has created this workqueue.

How to track a kworker-thread named for example ''kworker/0:3 to its origin in kernel-space?

I tried to look into /sys/kernel/debug/tracing/events/workqueue, but wasn't able to figure it out.

Answer 1

(Seems to me this is rather off topic here, but here's the answer I posted on unix.stackexchange.com.)

I found this thread on lkml that answers your question a little. (It seems even Linus himself was puzzled as to how to find out the origin of those threads.)

Basically, there are two ways of doing this:

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

For this you will need ftrace to be compiled in your kernel.

This will output what threads are all doing, and is useful for tracing multiple small jobs.

cat /proc/THE_OFFENDING_KWORKER/stack

This will output the stack of a single thread doing a lot of work. It may allow you to find out what caused this specific thread to hog the CPU (for example). THE_OFFENDING_KWORKER is the pid of the kworker in the process list.

Answer 2

So, after some time I found the solution. In fact Anthon is right, it is the ACPI-subsystem which sends interrupts. On my system I disabled the following interrupts and the kworker-thread is calmed down.

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

However until now haven't identified what the bogus IRQs coming from gpe08 and gpe1B.

Answer 3

kworker / watchdog causing high load regularly when not on cable power - workaround

Had kworker (cause kernel_thread_helper+0x6/0x10 ?) thread 1 spiking to 100% of a cpu for 1 second every 5 seconds only if laptop powered by cable. No problems on battery power. Did not matter if battery fully charged.

It more or less came out of the blue, so I guess the recent Ubuntu update was the cause (3.2.0-55-generic-pae now).

Was looking for half a day, trying to figure out wft the root cause is and endet up trying to disable all acpi interrupts, which did not matter.

Adding GRUB_CMDLINE_LINUX_DEFAULT=”acpi=off” to /etc/defaults/grub helped in the end.

As I discovered right now I added it with these exact special unicode quotes, which might explain the incompatibility with "quiet splash" (with default quotes) which puzzled me. I have to look into some more grub issues (boot menu not being displayed however I try, default entry config not used ...) so I will leave that testing for later.

PS: a week later, the problem is back (without restart, only suspend in between). There might be a correlation to using an usb mouse. Power down/power up helped (restart did not). Threw all grub options away. I am expecting the problem to show up again sometime.

PPS: Took some time (half a year), but it is back again after a resume from ram. No recent updates, just plugging/unplugging power, as I often do. No USB devices plugged/unplugged. Had a totem running (but nothing playing) during suspend. Power down/power up with power cable plugged did not help, power down/power up with power cable unplugged did.