linux 系统 CPU 负载高导致丢失 camera 中断从而丢帧的查找过程

问题背景

编写 camera 应用应该都知道,如果应用层没有及时的获取 buf,或者长期占用了内核的 buf 而没有返回给内核队列将会导致丢帧。这个丢帧是应用操作导致内核驱动队列 buf 不够用而覆盖之前的图像内容导致的丢帧,这种丢帧是内核驱动框架是知道的,本来应该重新设置 DMA 的目标地址的,但是因为队列中没有空闲的 buf 从而覆盖之前旧的 buf,也就是这样的丢帧,内核驱动是可以计数的,可以将该信息反馈到应用空间。

以上的情景在 camera 的相关内核中断是可以计数统计的,但本文探讨的是直接丢失 camera 中断的丢帧,也就是这个时候,中断计数也是没有办法确认是否存在丢帧的情况,而我们的项目需求是不可以不明不白的丢帧,允许应用没有及时处理图像从而导致图像内容被覆盖,但是不可以系统什么都不知道却丢失了图像数据。下面继续看看整个过程是怎样的。

发现问题

预览 camera 拍摄到的图像内容,仅通过肉眼是比较难发现是否丢帧的,那么我们是怎么发现有这个丢帧的操作的呢?

因为拍摄内容的特殊性,我们可以保证每帧图像拍摄到的内容都是不一样的,而且有规律可循的,我们在保证这样的一个前提下,发现有时候图像内容不是连贯的,但是系统没有任何的反馈(如果是覆盖丢帧,中断处理时将会有相应的信息),当存在系统没有信息提示,但是图像内容不连贯了,这个时候就怀疑我们接收端是否存在什么逻辑错误。

在这个问题中,我们的系统是和 MCU 配合使用的,我们将 sensor 配置为了 STROBE 输出,也就是在 sensor 进行曝光的时候,STROBE 将会输出为高电平,而其他情况将是低电平,MCU 检测该信号并进行相应的计数。同时,我们在 camera 中断中,将对 SOC 的一个 pin 进行翻转操作,帧头中断将 pin 置高,帧结束中断将 pin 置低,这样子,我们 SOC 也有一个帧信号输出。这样我们就可以使用示波器,一路接 sensor 的 STROBE 帧信号,一路接 SOC 的中断 pin 信号,然后运行应用程序,示波器查看两路信号是否是一一对应的,如果在某些情况下出现 SOC pin 翻转少了一次,那么就可以确认时接收端出现问题了。

实验结果发现,当图像内容不连贯时,SOC pin 翻转少了一次,同时我们还通过了 mipi 的一些相关寄存器发现,mipi 控制器是有接收到这帧的,而且 mipi 状态相关寄存器没有报错,也就是这帧图像数据是完整的,但是整个数据通路下来就是丢失了 camera 的中断,导致最终丢帧现象。

分析问题

从现象来看,SOC 是接收到该帧内容的,但是在最后 camera 中断中并没有表现出来,而且出现这样情况的时候,CPU 负载还是比较高的,而当 CPU 负载低的时候,是没有检测出问题的。同时如果相应的降低 sensor 输出的帧率,出现问题的概率又将大大减少。基于以上的情况,我们做出了以下的可能性判断:

  • camera 驱动框架存在问题,当高帧率高负载时处理不恰当导致丢失中断;
  • 在 CPU 负载高的时候,可能存在部分应用使用的驱动中存在长时间的关闭中断的状态,这样导致不能响应 camera 这边的中断;
  • CPU 负载高,导致一些线程,内核驱动等调度不及时,而新一帧图像的中断又到来了,从而覆盖了之前的中断导致现象为丢失中断;
定位问题

基于上面的一些分析判断,我们进行了以下的一些测试实验:

  1. 关于是否是其他的驱动关闭总中断,从而导致没有响应其他中断的。我们的实验操作如下:
    关闭、不使用系统中其他的外设,减少系统其他外设的中断,确认在应用运行的这个过程,仅有少数的驱动中断执行并确保不会长时间的关闭系统中断。
    实验测试发现,哪怕不使用其他的外设,减少系统的其他中断,还是存在 camera 中断丢失的情况,所以我们排除被关闭总中断从而丢失 camera 中断的可能。
  2. 设置系统应用线程的亲核性。
    测量应用运行过程中,各 CPU 的占用率,查看是否存在 CPU0 占用率较高的情况。因为 ARM 一般的都是通过 CPU0 响应系统 irq 中断的,如果 CPU0 占用率高,可能存在不能及时处理从而导致丢失中断的情况。将系统中比较耗 CPU 的线程通过 sched_setaffinity() 函数设置亲核性,将其迁移到除 CPU0 以外的核运行,保证 CPU0 可以及时的响应中断。
    实验测试发现,设置部分线程的亲核性之后,系统没有出现丢失 camera 中断的情况。因此我们推断是因为 CPU0 占用率高,导致不能及时响应中断从而导致丢失 camera 中断的情况出现。
  3. 将 camera 相关中断响应迁移到其他核。
    通过 echo 2 > /proc/irq/CAMERA_IRQ/smp_affinity 将 camera 的相关中断响应迁移到 CPU1,然后进行应用测试。这样可以排除是因为其他驱动中断关闭 CPU0 的中断从而导致的丢帧,如果在这样的情况下还是存在丢失中断的问题,那么需要检查 camera 驱动,确认是否存在逻辑漏洞,导致丢中断。
    实验测试发现,该实验是没有出现丢中断的情况。
解决问题

关于中断处理问题,后来发现在 linux 系统,应用跑在 CPU0 上,会有缺页中断异常,但它是没有关闭中断的,缺页异常优先级要高于 irq 异常,会有一定影响,但是影响不大。同时根据上面的一些测试结果,我们最终采取的方案是将比较耗 CPU 的线程都迁移到除 CPU0 的其他核上运行,如果后续测试发现还有丢失中断的情况,将会考虑设置线程亲核性 + 迁移中断响应的方式进行处理。
关于设置线程亲核性的问题,可以通过 cat /proc/PID/status 查看 Cpus_allowed_list: 1-3 信息来确认设置是否生效,上面信息代表着该线程在 CPU1~3 运行。
而查看中断是被哪个核响应的,可以 cat /proc/interrupts 获取相应的信息。

最后,如果本文对你有用,欢迎关注、点赞、收藏、分享,感谢支持!

你可能感兴趣的:(camera,linux)