器件型号: AM3356
您好、专家
当 CPU 调节器设置为“按需“时、某些 IRQ 线程有时会占用 CPU 400 至 500 毫秒的时间。
请参阅下面的 ftrace 日志。
相关的 IRQ 线程为`irq/42-mmc0-60`和`irq/57-wl18xx-260`。
通过 CAN0 传输大约 4 MB 的文件时会出现此问题。
CAN 帧传输间隔约为 0.5ms。
如果通信器件在 200ms 或更长时间内无法接收帧、则会中止连接。
因此、有必要防止这种情况发生。
内核版本 4.19.94 未出现此现象。
当 CPU 调节器设置为“performance“(性能)或“userspace“(用户空间)以锁定时钟速度时、也不会发生这种情况。
即使在 300MHz 中使用“userspace“设置固定时钟速度、也不会出现该问题。
作为临时解决方法、我们计划在传输过程中将 CPU 调节器设置为“性能“。
我们认为永久的解决方案需要修复内核中有问题的部分。
请您就这种现象的原因和相应的对策向我们提供意见。
-条件
- SDK:9.3
-内核版本: 4.1.119 00b127e50fa09f9bd35c66ac3011861392d9a750
-内核配置:“. config-governor“在附加的 config_devicetree.tar.gz
-设备树:config_devicetree.tar.gz 附件中的“am335x-jrn430k.dts“
- ftrace 日志
----- 案例 1 ftrace 的开始--------------------------------------------
mw_CAN0-3070 [000] d.2. 676.839206:Sched_switch:Prev_comm=MW_CAN0 prev_pid=3070 prev_prio=118 prev_state=S => next_comm=kworker/0:5 next_pid=52 next_prio=120
kworker/0:5-52[000] d.2. 676.839255:Sched_switch:Prev_comm=kworker/0:5 prev_pid=52 prev_prio=120 prev_state=D => next_comm=RCU_prepempt next_pid=13 next_prio=120
Rcu_preempt-13 [000] d.2. 676.839287:Sched_switch:Prev_comm=RCU_prepempt prev_pid=13 prev_prio=120 prev_state=i ===>next_comm=kworker/0:0 next_pid=4019 next_prio=120
kworker/0:0-4019 [000] d.2. 676.840676:Sched_switch:Prev_comm=kworker/0:0 prev_pid=4019 prev_prio=120 prev_state=R+=> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d.2. 676.842618:Sched_switch:Prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S => next_comm=irq/42-mmc0 next_pid=60 next_prio=49
--> irq/42-mmc0-60[000] d.2. 677.239713:Sched_switch:Prev_comm=IRQ/42-mmc0 prev_pid=60 prev_prio=49 prev_state=R+=> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d.2. 677.240032:Sched_switch:Prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S => next_comm=irq/42-mmc0 next_pid=60 next_prio=49
irq/42-mmc0-60 [000] d.2. 677.240380:Sched_switch:Prev_comm=IRQ_42-mmc0 prev_pid=60 prev_prio=49 prev_state=S => next_comm=APL_WS next_pid=599 next_prio=120
APL_WS-599 [000] d.2. 677.242447:Sched_switch:Prev_comm=APL_WS prev_pid=599 prev_prio=120 prev_state=S => next_comm=kworker/0:4 next_pid=51 next_prio=120
----- 案例 1 :跟踪端--------------------------------------------
----- 案例 2 ftrace 开始------------------------------------
APL_MC-533 [000] d.2. 1295.469869:Sched_switch:Prev_comm=APL_MC prev_pid=533 prev_prio=120 prev_state=R+=> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d.2. 1295.472254:Sched_switch:Prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S ==> next_comm=IRQ/57-wl18xx next_pid=260 next_prio=49
--> irq/57-wl18xx-260[000] d.2. 1295.986965:Sched_switch:Prev_comm=IRQ/57-wl18xx prev_pid=260 prev_prio=49 prev_state=D => next_comm=APL_mc next_pid=532 next_prio=120
APL_MC-532 [config_devicetree.tar.gz 000] d.2. 1295.989754:Sched_switch:Prev_comm=APL_MC prev_pid=532 prev_prio=120 prev_state=R+=> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
----- 第 2 种情形是跟踪端点 ----------------------------------------