Hi,
as mentioned in the topic: Since about two kernel versions (4.18.7) I am experiencing a kworker thread hogging a CPU 100%.
It doesn't happen always. Yesterday I had it basically directly at boottime. I rebooted, and things were fine. Today I came back to the machine (it had been running overnight) to find the 100% CPU thread again: 397 root 20 0 0 0 0 R 79.40 0.000 869:48.44 kworker/1:4+pm 19 root 20 0 0 0 0 S 20.67 0.000 218:35.03 ksoftirqd/1 So an interrupt thing.
I did
woodstock:~ # echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event woodstock:~ # cat /sys/kernel/debug/tracing/trace_pipe > out.txt ^C and checked the output for kworker/1: kworker/1:4-397 [001] d..2 67496.026584: workqueue_queue_work: work struct=00000000ea5af257 function=pm_runtime_work workqueue=00000000725eb582 req_cpu=512 cpu=1 kworker/1:4-397 [001] d..1 67496.026647: workqueue_queue_work: work struct=0000000013c93192 function=hub_event [usbcore] workqueue=00000000056912a2 req_cpu=512 cpu=1
Has someone else seen similar behavior? Is this indeed a kernel issue, or something else? Should it go to boo?
Am Donnerstag, 27. September 2018, 12:26:33 CEST schrieb Peter Suetterlin:
as mentioned in the topic: Since about two kernel versions (4.18.7) I am experiencing a kworker thread hogging a CPU 100%.
It doesn't happen always. Yesterday I had it basically directly at boottime. I rebooted, and things were fine. Today I came back to the machine (it had been running overnight) to find the 100% CPU thread again: 397 root 20 0 0 0 0 R 79.40 0.000 869:48.44 kworker/1:4+pm 19 root 20 0 0 0 0 S 20.67 0.000 218:35.03 ksoftirqd/1 So an interrupt thing.
I did
woodstock:~ # echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event woodstock:~ # cat /sys/kernel/debug/tracing/trace_pipe > out.txt ^C and checked the output for kworker/1: kworker/1:4-397 [001] d..2 67496.026584: workqueue_queue_work: work struct=00000000ea5af257 function=pm_runtime_work workqueue=00000000725eb582 req_cpu=512 cpu=1 kworker/1:4-397 [001] d..1 67496.026647: workqueue_queue_work: work struct=0000000013c93192 function=hub_event [usbcore] workqueue=00000000056912a2 req_cpu=512 cpu=1
Has someone else seen similar behavior? Is this indeed a kernel issue, or something else? Should it go to boo?
Not sure if this is related, but I have a similar problem on a Desktop-PC, where both CPU are partly blocked for around 90s . See: https://lists.opensuse.org/opensuse-support/2018-06/msg00112.html
Best, Axel
-
Axel Braun -
Peter Suetterlin