У меня есть нить kworker с высокой загрузкой процессора, из-за чего мой сенсорный экран работает очень медленно и не отвечает. Запуск beaglebone с 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

Я не могу установить / использовать 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

проблема в том, что я не понимаю, почему существует эта проблема или откуда она возникает, а затем, как ее решить.

Я использую графический интерфейс, а также CAN (python-can/socketCAN). Обмен сообщениями CAN контролируется через графический интерфейс.

Поведение, которое я обнаружил, было таким: когда запускается графический интерфейс - нет тяжелого потока kworker. При первом запуске CAN - поток kworker отнимает 15-40% процессорного времени.

У меня есть переключатель, который позволяет мне прекратить отправку сообщений CAN (CAN вкл / выкл). Теперь, когда я отключаю CAN через графический интерфейс, поток kworker увеличивается до 60% использования процессора.

Я предполагаю, что что-то запускается, когда интерфейс CAN сначала включен, а затем продолжается во всем. Как я могу определить и исправить это?

T

|источник

0