我有一个 kworker 线程,其 CPU 使用率很高,这导致我的触摸屏非常滞后且无响应。使用 Debian 运行 beaglebone。
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
我无法安装/使用 perf,因为我运行的是 4.1.15 内核,而 perf 仅在 3.16 中可用,所以我无法通过它跟踪线程
我尝试了在线找到的多种解决方案,但都没有用。
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
输出:
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)禁用 /sys/firmware/ascpi/gpe##
但是,该文件夹 ascpi 甚至不存在于我的 beaglebone 上。
3)https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu
echo l > /proc/sysrq-trigger
创建回溯,在末尾输出dmesg
输出:
[ 3581.845525] sysrq: SysRq : Changing Loglevel
[ 3581.850338] sysrq: Loglevel set to 1
问题是我不明白为什么存在这个问题,或者它从何而来,以及如何解决它。
我正在运行 GUI 和 CAN(python-can/socketCAN)。CAN 消息传递通过 GUI 控制。
我发现的行为是:当 GUI 启动时 - 没有繁重的 kworker 线程。当 CAN 首次启动时 - kworker 线程占用了 15-40% 的 CPU。
我有一个开关可以让我停止发送 CAN 消息(CAN 开/关)。现在,当我通过 GUI 关闭 CAN 时,kworker 线程会占用 60% 的 CPU。
我猜想在首次启用 CAN 接口时会发生某些事情,并且会一直持续下去。我该如何查明并修复此问题?
电视