记一次在linux 平台上的优化调试

Author:DriverMonkey

Mail:[email protected]

Phone:13410905075

QQ:196568501


测试平台:AM335X


优化前状态:采样速度  105次/S


优化目标速度为 130次/S 以上(注:根据ADC的采样率理论上可以达到 330次/S)


优化步骤:

              1)代码框架可分为四大模块(UI, 业务逻辑管理,设备管理,远程管理)共10个线程

                   模块间有项目依赖关系,不能一下全部停掉,先去掉一些辅助功能线程(如:按键扫描线程,远程命令处理线程等)。

                   接下来只剩下UI,业务逻辑处理,设备管理,远程管理,四个主线程。编译运行代码查看采样速度有无变化。运行结果

                   是无任何明显变化(任然在105次/s 左右波动)

               2)现在怀疑UI,设备管理,远程管理这三个模块运行效率太低导致采样速度提不上去导致。

                    分别屏蔽这三个线程,分别采集线程同时运行查看采样速度有无明显变化。

               运行结果是无任何明显变化(任然在105次/s 左右波动)

              3)现在只剩下采集线程(其他线程全部停止)发现采集速度同样上不去

                    接下来逐一屏蔽业务处理模块的子模块,再分别编译运行,查看运行结果,采样速度任然没有任何明显变化

              4)到这一步只剩下应用层代码通过SPI总线读ADC 这部分代码了

                   写一份fake 读ADC 的代码替换掉原来的代码,发现能满足现在的优化需求(fake 读ADC 代码的采样率 280次/S)

                   通过当前调试现象至少可以肯定ADC 采样率的瓶颈不在应用层。接下来调试思路,从应用层代码转向驱动层,和硬件原理图的设计

              5)运行只有业务逻辑层代码的程序去读ADC值,并查看系统状态。

                    通过TOP查看发现系统进程状态发现一个kworker 进程有异常,发现这个进程CPU占用率为20%~30%。

                    继续查找资料,发现kworker 进程实际上在内核中是一个处理队列的内核线程。

                    看到这个kworker进程给我的第一感觉可能是SPI读写驱动申请的。继续调试发现调用读取ADC SPI 接口有的时候需要花费 5ms 甚至                             10ms的时间才能返回。实际上我们次发送和接收才4个字节。那就不可能是SPI驱动引起的,那就可能是别的驱动引起的,而当前运行

                      APP只调用SPI一个驱动。

                    现在从系统状态入手。通过查看系统状态发现,一个驱动中断异常(每秒钟103次中断)中断,明显中断过于频繁。实际上这个驱动我们

                    系统名没有使用,找到对应代码重新编译内核。重新运行APP 采集速度直接到 258次/S


优化结果:                    

               采样速度达到 258次/S  完全满足优化目标

     





记一次在linux 平台上的优化调试,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。