缓解mtk-openwrt-feeds主线5.4内核有线驱动CPU占用虚高的问题

Vietam

这个问题还挺恶心的，前后排查了快一个月才解决。。。



具体表现是，闲置状态下，CPU占用，最新的mtk-openwrt-feeds驱动占用总是保持在0.15-0.20之间，而且kworker频繁调用，用pidstat和perf都看不出来原因，只知道phy_state_machine被频繁调用


回滚到Release MP2.3，也就是commit id b62586b3cc50a02ed6572c8667c5be6effedcaaf，问题解决。
没办法，只能对代码进行静态分析了，发现从Release MP2.3到 HEAD 引入delayed_work的地方有：
1. mtk_hw_reset_monitor_work，commit id 1791e3d251db067c90d45742d1fef1046809aaec
2. mtk_sgmii_pcs_link_poll，commit id d49feb90f8ad4a519bc6a68252e9330ab40f582e


回滚第二个没用，问题依旧。于是仔细看第一个：
这个commit干了两个事情，
1. 重构SER，即System Error Recovery机制的数据结构，使用结构体存储上次检测的状态。
2. 增强ADMA_RX，GDM_RX，QDMA_TX的检测规则。


问题主要出在mtk_monitor_wdma_rx上，直接上代码：



这个地方居然用了一个msleep(50)。。。使用msleep会导致worker线程变成D或者S，还会阻塞队列上的其它任务，总之这个写法太糟糕了。。。
直接删掉这个逻辑，用旧版的cur，pre比较一次的逻辑就可以了，因为后面逻辑重构了，还有mtk_check_wifi_busy等状态检测和hang_count_netsys兜底，所以理论上回滚影响不大。


修改好代码以后，问题不再出现。

iamyangyi

顶下 喜欢这种探到底研究

abc2008208

技术一流，一般人看不懂，也没空细研，所以现在这么多垃圾app。应用不断升级，不是优化，是加垃圾。

wulishui

按道理这里不应该，它只执行3个循环，应该别处还有一个循环来执行它

Vietam

wulishui 发表于 2025-11-20 10:36
按道理这里不应该，它只执行3个循环，应该别处还有一个循环来执行它

它是放置在一个delayed_queue里面执行的，这是一部分的任务，然后主线程执行完这些任务递归再放置到delayed_queue里面实现了循环。。。

zjuahhy

牛逼牛逼牛逼

自学中的老年人

牛！ 很久很久很久以前玩C，汇编， 看到面熟的代码，恍然大悟，原来我认识这些！