实时进程中的串行通信被低优先级进程延迟 (Linux)

Question

我有一个实时进程，偶尔会通过 RS232 向高速摄像机发送通信。我还有其他几个实时进程占用了大量 CPU 时间，使用 CUDA 在几个 GPU 板上进行图像处理。通常串行通信非常快，每次消息和响应大约需要 50 毫秒。但是，当后台进程忙于进行图像处理时，串行通信速度会减慢，通常需要数秒（有时超过 10 秒）。

综上所述，在串行通信期间，如果进程 B、C 等非常忙，进程 A 会延迟，即使进程 A 具有最高优先级：

• 进程A（实时，最高优先级）：偶尔串行通信
• 进程 B、C、D 等（实时，低优先级）：CPU 和 GPU 处理繁重

当我将后台进程改为SCHED_OTHER（非实时）进程时，串口通信速度很快；然而，这对我来说不是一个解决方案，因为后台进程需要是实时进程（如果不是，GPU 处理跟不上高速相机）。

显然，串行通信依赖于系统中的一些非实时进程，它被我的实时后台进程抢占了。我想如果我知道哪个进程用于串行通信，我可以提高它的优先级并解决问题。有谁知道串行通信是否依赖于系统上运行的任何特定进程？

我正在使用标准内核（不是 PREEMPT_RT）运行 RHEL 6.5。它具有双 6 核 CPU。

在 Erki A 的建议下，我捕捉到了一条线索。显然这是一个很慢的 select() 系统调用（“set roi2”是对相机的命令，最后的“Ok！”是来自相机的响应）：

write(9, "set roi2"..., 26)             = 26 <0.001106>
ioctl(9, TCSBRK, 0x1)                   = 0 <0.000263>
select(10, [9], NULL, NULL, {2, 0})     = 1 (in [9], left {0, 0}) <2.252840>
read(9, "Ok!\r\n", 4096)                = 5 <0.000092>

缓慢的 select() 使相机本身似乎响应缓慢。但是，我知道这不是真的，因为更改后台进程优先级会影响速度。在这种情况下 select() 是否依赖于某个其他正在运行的进程？

如果我跳过 select() 而只执行 read()，则 read() 系统调用是缓慢的。

Answer 1

您可以使用它strace来查看它锁定的位置。如果超过10秒，应该很容易看到。