Kworker thread has high CPU usage

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