高度时间敏感应用的分析方法答案

【问题标题】：Profiling methods for highly time sensitive applications高度时间敏感应用的分析方法
【发布时间】：2014-08-12 12:11:28
【问题描述】：

我在嵌入式 Linux 环境中工作，调试与 Zigbee 设备配对/绑定相关的高度时间敏感问题。

我们的架构是通过 SPI 接口从 Zigbee 前端模块读取数据，然后从内核空间传递到用户空间进行处理。处理后的数据和响应随后被传回内核空间，并再次通过 SPI 接口输出。

Zigbee 802.15.4 时序要求规定我们需要在 19.5 毫秒内做出响应，而且我们经常会在此窗口之外做出响应，这会导致网络出现故障和丢包。

Linux 内核未在启用抢占的情况下运行，也可能无法启用抢占。
我的怀疑是，由于内核不可抢占，还有另一个任务/进程正在使用 ioctl() 接口，这会使 Zigbee 应用程序延迟足够长的时间，以至于超过 19.5 毫秒的窗口。

我尝试了以下工具

oprofile - 这里没有太大帮助，因为它会分析整个系统，而应用程序在此期间实际上并不是很忙，因为它移动了如此少量的数据
strace - 开销太大，虽然我没有太多使用它的经验，所以也许可以改进输出。开销对性能的影响如此之大，以至于应用程序根本无法运行

还有其他轻量级的方法来分析这样的系统吗？

当一个 ioctl 调用挂在另一个任务/线程上时，无论如何要捕获吗？（假设这是问题的根本原因）

【问题讨论】：

标签： linux linux-kernel profiling embedded-linux zigbee

【解决方案1】：

好问题。这是一个想法。不要将其视为剖析。想想在行动中抓住它。

我会研究创建一个看门狗计时器，以在 16.5 毫秒间隔后关闭。每当你成功时，重置计时器。这样，它只会在出现故障时熄灭。那时，我会尝试获取进程的堆栈样本，或者可能是另一个可能阻塞它的进程。

这是对this technique 的改编。这需要一些工作，但如果有任何工具可以准确地告诉你发生了什么，我会感到惊讶，而不是在线仿真器。

【讨论】：

最后，我们通过改变架构设法解决了这个问题，而不是“在行动中抓住它”。发送消息、睡眠、唤醒、进程数据、场景类型太多。但是，这种方法似乎是最好的。我确实按照建议开始实施它。但棘手的部分是我们有 2 个独立的进程相互发送消息，我们需要捕获进程 B 需要很长时间才能响应进程 A
@undercoverMunky：可以肯定的是，如果您不能同时停止进程 A 和 B，那么这些情况会更加困难，以查看谁在等待什么。过去，我为此类问题制作了带有时间戳的消息日志。不容易，但它奏效了。

【解决方案2】：

LTTng 是您正在寻找的工具。与 Oprofile 一样，它对整个系统进行了概要分析，但您将能够以时间线的方式准确查看每个进程和内核线程的情况。您将能够围绕兴趣点查看线程和调度程序的交互，即当您错过 Zigbee 截止日期时。一旦检测到丢失的数据包，您可能必须变得聪明并使用某种触发（或更可能是停止）LTTng 跟踪的方法，或者您可能很幸运，只需使用命令行工具启动并立即捕获它停止追踪。

您可能需要做一些工作才能到达那里，例如，您必须投入一些时间和精力来 1) 使您的内核能够运行 LTTng（如果它还没有），以及 2) 学习如何用它。它是一个强大的工具，可用于各种分析和分析任务。大多数商业嵌入式 Linux 供应商都有完整的端到端 LTTng 产品和配置，如果您有该选项的话。如果没有，您应该能够在线找到大量有用的帮助和示例。 LTTng 已经存在很长时间了！狩猎愉快！

【讨论】：