linux - 低优先级进程延迟的实时进程中的串行通信 (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 的建议下，我捕获了一个 strace。显然这是一个缓慢的 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

根据您的串行设备/驱动程序，串行通信很可能依赖于内核工作线程 (kworker) 将传入的串行数据从中断服务例程缓冲区转移到线路规程缓冲区。您可以增加内核工作线程的优先级，但是，工作线程处理共享工作队列。因此，增加工作线程的优先级将增加串行处理的优先级以及一大堆其他可能不需要优先级提升的东西。

您可以修改串行驱动程序以使用专用的高优先级工作队列而不是共享队列。另一种选择是使用 tasklet，但是，这两种方法都需要修改驱动程序级别。

我怀疑最直接的解决方案是通过 setserial 命令从命令行将 com 端口设置为低延迟模式:

setserial /dev/ttySxx low_latency

或以编程方式:

struct serial_struct serinfo;
fd = open ("/dev/ttySxx");
ioctl (fd, TIOCGSERIAL, &serinfo);
serinfo.flags |= ASYNC_LOW_LATENCY;
ioctl (fd, TIOCSSERIAL, &serinfo);
close (fd);

这将导致串行端口中断处理程序立即将传入数据传输到线路规程，而不是通过将其添加到工作队列来延迟传输。在这种模式下，当您从应用程序调用 read() 时，您将避免 read() 调用休眠的可能性，如果工作队列中有要刷新的工作，否则它会休眠。这种 sleep 可能是您间歇性延迟的原因。