linux进程通讯速度最快,低优先级进程延迟实时进程中的串行通信(Linux)

我有一个实时的过程,偶尔通过RS232发送到高速摄像机.我还有其他几个实时进程占用大量CPU时间,使用CUDA在几块GPU板上进行图像处理.通常,串行通信速度非常快,每次消息和响应大约需要50 ms.但是,当后台进程忙于进行图像处理时,串行通信会慢下来,通常需要多秒(有时超过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()系统调用很慢.