我的团队正在为一个产品开发一个嵌入式Linux解决方案,其中一个中心应用程序接收并处理来自硬件的数据,并将其发送到数据库和接口应用程序。在这样做的过程中,我们使用了五个线程:
这个应用程序不能错过由UPP线程带来的任何数据包,它每200毫秒获得新的数据。DSP线程通常比这200毫秒更少(目前它需要30毫秒,但在未来它将需要更多的时间)。DB线程通常每30s调用一次,接口线程以5Hz频率调用一次。
我们面临的问题是,线程有时需要更多的时间来完成它们的工作,特别是DB和DSP线程。IOW,当系统每运行一次UPP运行DSP时,有时UPP最多运行15次,而不需要调用DSP就会丢失接收到的数据。线程中的这些零星的“滞后”发生在所有线程中,但是DB和Interface中的延迟并不是问题,只有当它们锁定在UPP或DSP线程中时才是问题。
我们检查代码中所能找到的所有问题所在,但都没有成功--大多数情况下,系统运行时没有任何延迟。不过,我们注意到了一些模式:
我们开始认为这与Linux有关。通常,在PC的日常使用中,会出现一些与鼠标或应用程序相去甚远的情况,Linux可能会对我们这样做。我们还考虑使用内存内存,共享的主要L138处理器和DSP处理器,但一些测试提供了负面证据的假设。
你有什么意见建议?Linux真的是问题的根源吗?我们怎么知道,怎么解决呢?
任何帮助都将不胜感激。
P.s.:与这相同
发布于 2014-12-29 12:55:01
这可能有点太基础了,但这是我过去在处理与时序和设计相关的but时考虑过的问题清单。
指定什么是可接受的滞后()
在时间敏感的应用程序中,过早的优化可能会非常昂贵,确保您了解您的滞后需求是什么(有硬数字),测量您正在观察的内容,并不断改进直到您达到目标。
选择合适的硬件
确保如果你有n个线程,你想要合理的时间,你有大约n个核心。这使得很容易证明您的进程正在使用CPU。即使您不能在生产中做到这一点,在测试期间这样做可以帮助排除某些类型的错误。
确保您的应用程序不会使用交换空间--确保您有足够的RAM用于所有可能的用例和运行时。使用像缬磨这样的工具来确保您没有泄漏内存。
选择适当的嵌入式Linux。
应用程序的时间越重要,就越有可能需要提供定时保证的操作系统。在一个真正的硬实时操作系统上运行将给出非常不同的结果运行在一些东西,只是一个剥离桌面linux。了解并理解您所选择的嵌入式linux的含义。
为您的应用程序选择适当的优先级级别
如果您看到零星的延迟,请确保您的系统上没有任何其他可能导致问题的运行。我在桌面Linux变体上看到了一些可能导致问题的奇怪情况,包括音频驱动程序。
至少在测试期间,与其他后台进程相比,您的优先级要高得多(低值)。您可以使用好的来完成此操作。
理解内核调用发生在哪里,
正如注释中所述,使用像绞合这样的工具来识别正在进行的内核调用是一个非常好的主意。类似地,了解哪些类型的职能/业务将触发系统调用非常有用(例如,在可能的情况下,重用缓冲区而不是触发频繁的分配和释放)。
这也会导致理解和最小化您的应用程序所做的锁定。这包括明显的事情,比如以一致的顺序获取锁,尽量减少使用锁的时间,以及采用最轻的权重同步原语(您可以使用atomics而不是mutexes吗?)
选择适当的调度程序和线程优先级()
在任务多于核心的地方,请考虑使用哪个调度程序。
通用调度器(在大多数情况下)不适合性能关键的应用程序。您的linux发行版将提供一些机制来更改调度器 (尽管这可能需要提高权限)。
圆形罗宾调度(SCHED_RR)是一个很好的开端,因为它使得CPU的使用数学非常容易计算出来(至少给出了一个大概的估计)。确保具有最严格的计时要求的线程具有最高优先级。请注意,更改优先级可能会导致一些微妙的错误(优先级反演)
将性能关键线程锁定到特定核心
您可以使用操作系统(或特定于平台的)调用来设置线程关联(需要保持在特定的核心上) 亲和力。在某些情况下,这有助于确保一致的缓存性能。
https://stackoverflow.com/questions/27687438
复制相似问题