c++ - 嵌入式 Linux 应用程序中的期刊 "lags"

Question

我的团队正在为一种产品开发嵌入式 Linux 解决方案，其中中心应用程序从硬件接收和处理数据，并将其发送到数据库和接口(interface)应用程序。为此，我们使用五个线程:

1. 主线程:创建其他线程并做一些副处理(从界面应用读取数据等)
2. UPP线程:从硬件接收数据并放入缓冲区
3. DSP 线程:从先前的缓冲区中提取数据，并要求 DSP 处理器使用该数据进行计算。返回的数据存储在第二个缓冲区中
4. DB Thread:一段时间后，选择合理数量的计算数据并将它们存储在文件系统中。
5. 接口(interface)线程:选择当前数据并发送到接口(interface)应用

此应用程序不会错过任何来自 UPP 线程的数据包，UPP 线程每 200 毫秒获取一次新数据。 DSP 线程通常花费的时间少于这 200 毫秒(目前大约需要 30 毫秒，但将来会花费更多时间)。 DB 线程通常每 30 秒调用一次，接口(interface)线程以 5 Hz 的频率调用。

我们面临的问题是，线程有时会花费更多时间来完成它们的工作，尤其是 DB 和 DSP 线程。 IOW，虽然系统在每次运行 UPP 时都运行 DSP，但有时 UPP 运行多达 15 次而没有调用 DSP，从而导致接收到的数据丢失。线程中的这些零星“滞后”在所有线程中都会发生，但 DB 和接口(interface)中的滞后不会有问题，只有当它们出现在 UPP 或 DSP 线程中时才会出现问题。

我们尽一切可能尝试在我们的代码中找到问题所在，但没有成功——大多数时候系统运行没有任何滞后。不过，我们注意到了一些模式:

• 当界面与可见的最“繁重”的小部件之一一起运行时，更容易出现延迟。
• 然而，所需处理的增加似乎并不是原因:用一些“垃圾处理”对系统施加压力并且打开界面并没有增加延迟的发生。
• 它可能与界面和特定小部件没有直接关系；它的所有处理在时间上都是相似的(因此任何错误都可能以非随机结束，但事实并非如此)

我们开始认为它与 Linux 有关。通常，在 PC 的日常使用中，鼠标或应用程序确实会出现一些延迟，而 Linux 可能正在对我们这样做。我们还考虑过使用 RAM 内存，在主 Omap L138 处理器和 DSP 处理器之间共享，但一些测试为该假设提供了否定证据。

您有什么建议吗？ Linux 真的是问题的根源吗？我们如何知道以及如何修复？

任何帮助将不胜感激。

附注:与this相同

Answer 1

这可能有点太基础了，但这是我过去处理与时序和设计相关的错误时考虑过的事情的 list 。

指定可接受的延迟是多少

在时间敏感型应用程序的情况下，过早的优化可能会非常昂贵，确保您了解您的滞后要求是什么(有硬性数字)，衡量您观察到的内容，并不断改进直到达到您的目标。

选择合适的硬件

如果您有 n 个线程，请确保您需要合理的时序，并且您有大约 n 个内核。这使得证明您的进程正在使用 CPU 变得轻而易举。即使您不能在生产中执行此操作，在测试期间执行此操作也有助于排除某些类型的错误。

确保您的应用程序不会使用交换空间 - 确保您有足够的 RAM 来满足所有可能的用例和运行时。使用类似 valgrind 的工具以确保您没有泄漏内存。

选择合适的嵌入式 Linux

您的应用程序对时序的要求越高，您就越有可能需要一个提供时序保证的操作系统。在真正的硬实时操作系统上运行与在精简的桌面 linux 上运行会产生截然不同的结果。知道并理解您选择的嵌入式 Linux 的含义。

为您的应用选择合适的优先级

如果您看到零星的延迟，请确保您的系统上没有运行任何可能导致问题的其他程序。我在桌面 Linux 变体上看到了一些可能导致问题的奇怪东西，包括音频驱动程序。

至少在测试期间将您的优先级提高到比其他后台进程高得多(低值)。您可以使用 nice做这个。

了解内核调用发生的位置

如评论中所述，使用像 strace 这样的工具识别正在进行的内核调用是一个非常好的主意。同样，了解一下functions / operations是什么类型将触发系统调用可能非常有帮助(例如，在可能的情况下，重用缓冲区而不是触发频繁的分配和释放)。

这也有助于理解和最小化您的应用程序正在执行的锁定。这包括显而易见的事情，例如以一致的顺序获取锁，最大限度地减少使用锁所花费的时间，以及采用有意义的最轻量级同步原语(您可以使用原子而不是互斥锁吗？)。

选择合适的调度器和线程优先级

如果您的任务多于核心，请考虑您正在使用的调度程序。

通用调度程序(在大多数情况下)不适合性能关键型应用程序。您的 Linux 发行版将提供一些机制来更改 scheduler (尽管这可能需要提升权限)。

Round Robin 调度 (SCHED_RR) 是一个好的开始，因为它使 CPU 利用率数学计算变得非常容易(至少可以给出一个大概的估计)。确保具有最严格时序要求的线程具有最高优先级。请注意，更改优先级可能会导致一些细微的错误 ( priority inversion )

将性能关键线程锁定到特定内核

您可以使用操作系统(或平台特定)调用来设置线程关联(需要留在特定核心上)sched_affinity .在某些情况下，这有助于确保一致的缓存性能