0
I have a kworker thread with high cpu usage, which is causing my touchscreen to be very lag-y and unresponsive. Running a beaglebone with Debian.
uname -r
4.1.15-ti-rt-r43
pid user pr ni virt res shr s %cpu %mem time+ command
90 root 20 0 0 0 0 R 34.7 0.0 14:16.48 kworker/u2:2
I'm unable to install/use perf because I'm running a 4.1.15 kernel and perf is only available in 3.16 so I can't trace the thread through that
I tried multiple solutions I found online, but none of them work.
1) https://stackoverflow.com/questions/10846747/origin-of-a-kworker-thread
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe
Output:
python3-748 [000] d.h2 714.802127: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295
kworker/u2:2-67 [000] d.h2 714.817350: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295
kworker/u2:2-67 [000] d.h3 714.832576: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295
python3-745 [000] d.s3 714.834340: workqueue_queue_work: work struct=ddd22e08 function=mcp251x_tx_work_handler [mcp251x] workqueue=dcff0200 req_cpu=2 cpu=429496$
irq/145-can1-737 [000] d..2 714.835555: workqueue_queue_work: work struct=ddd22e18 function=mcp251x_irq_work_handler [mcp251x] workqueue=dcff0200 req_cpu=2 cpu=42949$
kworker/u2:2-67 [000] d.h2 714.847801: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295
$ cat /proc/90/stack
[<ffffffff>] 0xffffffff
2) Disabling /sys/firmware/ascpi/gpe##
however, that folder ascpi doesn't even exist on my beaglebone.
3)https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu
echo l > /proc/sysrq-trigger
to create a backtrace, output at the end of dmesg
Output:
[ 3581.845525] sysrq: SysRq : Changing Loglevel
[ 3581.850338] sysrq: Loglevel set to 1
the problem is that I don't understand why this issue exists, or where it's arising from - and then further, how to solve it.
I'm running a GUI and also running CAN (python-can/socketCAN). CAN messaging is controlled through the GUI.
The behavior I found was: When GUI starts up - no heavy kworker thread. When CAN is started up for the first time - kworker thread eats up 15-40% of CPU.
I have a switch that enables me to stop sending the CAN messages (CAN on/off). Now when I turn off CAN through the GUI, kworker thread goes up to using 60% of the CPU.
I suppose something is starting up when the CAN interface is first enabled and then continuing throughout. How do I pinpoint and fix this?
T
Does it also happen when no GUI is running? Have you tried unloading unnecessary kernel modules? What devices are connected via USB or whatever? – Daniel B – 2017-02-08T22:46:50.310
I tested it out - I'm running a GUI and also running CAN (python-can/socketCAN). CAN messaging is controlled through the GUI. The behavior I found was:
When GUI starts up - no heavy kworker thread. When CAN is started up for the first time - kworker thread eats up 15-40% of CPU. I have a switch that enables me to stop sending the CAN messages (CAN on/off). Now when I turn off CAN through the GUI, kworker thread goes up to using 60% of the CPU.
I suppose something is starting up when the CAN interface is first enabled and then continuing throughout. How do I pinpoint and fix this? – avelampudi – 2017-02-10T14:59:43.720
turbo mode in bios? – DeerSpotter – 2017-02-10T15:04:41.370
/sys/devices/system/cpu/cpu0/cpufreq
doesn't have even a boost file for my system - unless there's another place it would be enabled/disabled. how would turbo mode fix this? (or be the cause of the problem) – avelampudi – 2017-02-10T15:51:39.823