我在嵌入式 Linux 环境中工作，调试与 Zigbee 设备的配对/绑定(bind)相关的对时间高度敏感的问题。
我们的架构是这样的，数据通过 SPI 接口(interface)从 Zigbee 前端模块读取，然后从内核空间传递到用户空间进行处理。处理后的数据和响应随后传回内核空间并再次通过 SPI 接口(interface)输出。
Zigbee 802.15.4 时间要求指定我们需要在 19.5 毫秒内做出响应，而我们经常会遇到恰好在此窗口之外做出响应的情况，这会导致网络出现故障和数据包丢失。
Linux 内核未在启用抢占的情况下运行，也可能无法启用抢占。
我的怀疑是，由于内核不是可抢占的，所以有另一个任务/进程正在使用 ioctl() 接口(interface)，这会延迟 Zigbee 应用程序足够长的时间以超过 19.5 毫秒的窗口。
我试过以下工具
- oprofile - 在这里没有太大帮助，因为它会分析整个系统，并且应用程序在这段时间内实际上并不是很忙，因为它移动的数据量非常小
- strace - 开销太大，虽然我没有太多使用它的经验，但也许可以改进输出。开销对性能的影响如此之大，以至于应用程序根本无法运行
是否有任何其他轻量级方法来分析这样的系统？
当 ioctl 调用在另一个任务/线程上挂起时，是否有任何捕获？ (假设这是问题的根本原因)
最佳答案
好问题。 这是一个想法。不要将其视为分析。 想想在表演中捕获它。
我会研究创建一个看门狗定时器，以便在 16.5 毫秒间隔后关闭。 每当您成功时，请重置计时器。 这样，它只会在出现故障时熄灭。 那时，我会尝试获取进程的堆栈样本，或者可能是另一个可能阻止它的进程。
这是对 this technique 的改编. 这需要一些工作，但如果有任何工具可以准确地告诉您发生了什么，除了在线仿真器，我会感到惊讶。
关于linux - 对时间高度敏感的应用程序的分析方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25263954/