Linux – How to Interpret kworker Thread Names

linuxlinux-kernel

On Linux 3.11.0-13-generic running on top of a dual socket Xeon X5650 hexa core board, htop shows different kworker threads. Sorted by names (I tweaked the result I am showing here a little bit to have the threads on core 2 before the ones on core 10), here is the result:

kworker/0:0H
kworker/0:1
kworker/0:2
kworker/1:0
kworker/1:0H
kworker/1:1
kworker/2:0
kworker/2:0H
kworker/2:1
.....
kworker/11:0
kworker/11:0H
kworker/11:1
kworker/u48:0
kworker/u49:4
kworker/u49:5
kworker/u50:1
kworker/u50:2
.......

The threads whose names start with a number are pinned to the core with the same number. So the first number is the core running the thread and I am wondering what the symbol after : (0 or 0H or 1) is for these threads?

I am also wondering what is the meaning of the uXX:Y symbols?

I have only a vague knowledge of what kworker threads do: they handle asynchronous events caused by system calls performing I/O. Are they documented somewhere?

Best Answer

According to kernel.org, the syntax is kworker/%u:%d%s (cpu, id, priority). The u designates a special CPU, the unbound cpu, meaning that the kthread is currently unbound.

The workqueue workers which have negative nice value have 'H' postfixed to their names. (source)

Related Solutions

Linux – High CPU usage with CFS

According to SLES 11 SP2 release-notes this might be a change introduced to the way CFS is being implemented.

Since SLES 11 SP2 is the current SLES-version this behaviour is still valid (as it seems for all 3.x-kernels).

This change was intended - but might have "bad" side-effects. Perhaps one of the workarounds described helps for you...

Linux keep forking “kworker”

kworker processes are kernel worker processes, and having many of them is likely to be harmless.

Kernel worker threads could be doing any number of things, as some random examples:

Doing page cache writebacks
Handling certain kinds of hardware events
Many, many other things

To know what any kworker is doing, you can look at /proc/<kworker_pid>/stack. For example:

$ cat /proc/$(pgrep -of kworker)/stack
[<ffffffff85c0c705>] acpi_ns_evaluate+0x1bc/0x23a
[<ffffffff85bffe09>] acpi_ev_asynch_execute_gpe_method+0x98/0xff
[<ffffffff85be4e30>] acpi_os_execute_deferred+0x10/0x20
[<ffffffff8588dc21>] process_one_work+0x181/0x370
[<ffffffff8588de5d>] worker_thread+0x4d/0x3a0
[<ffffffff85893f1c>] kthread+0xfc/0x130
[<ffffffff8588de10>] process_one_work+0x370/0x370
[<ffffffff85893e20>] kthread_create_on_node+0x70/0x70
[<ffffffff858791ba>] do_group_exit+0x3a/0xa0
[<ffffffff85e6a2b5>] ret_from_fork+0x25/0x30
[<ffffffffffffffff>] 0xffffffffffffffff

This kworker is acting on an ACPI event. You can tell this because it's inside its "processing" function, process_one_work, which eventually leads to functions related to processing ACPI events (like acpi_os_execute_deferred).

You'll probably find many have this stack, or something similar:

[<ffffffff9409a37d>] worker_thread+0xbd/0x400
[<ffffffff940a0355>] kthread+0x125/0x140
[<ffffffff946780c5>] ret_from_fork+0x25/0x30
[<ffffffffffffffff>] 0xffffffffffffffff

These kernel workers are simply sitting waiting for work to do.

Depending on your system configuration, it could well be normal to have many kworkers. Unless they are actively causing problems, I wouldn't worry about them.

Best Answer

Related Solutions

Linux – High CPU usage with CFS

Linux keep forking “kworker”

Related Question