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.
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe
python3-748  d.h2 714.802127: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 kworker/u2:2-67  d.h2 714.817350: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 kworker/u2:2-67  d.h3 714.832576: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 python3-745  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  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  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
however, that folder ascpi doesn't even exist on my beaglebone.
echo l > /proc/sysrq-trigger to create a backtrace, output at the end of
[ 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?
/sys/devices/system/cpu/cpu0/cpufreqdoesn'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)