centos7中的上下文切换延迟

Question

在我的C应用程序中，主进程分叉一个子进程，然后睡10微秒，给子进程准备时间。睡眠期间之后，父进程向子进程发送信号，以便开始侦听指定的端口。

这段代码在CentOS6中执行得很好，只有少数情况下，子进程的睡眠时间不足以在传递来自父进程的信号之前设置它的信号处理程序。但是，当此代码在具有相同系统规范的CentOS7中运行时，子程序始终未能及时安装其信号处理程序。我必须将睡眠时间增加到10毫秒(长1000倍)，才能获得与CentOS6相同的性能。

我想知道为什么CentOS 7中的上下文切换相对于相同规格的硬件上的CentOS 6如此缓慢？

Answer 1

进程/线程调度由操作系统内核自行决定。CentOS 7使用与CentOS 6不同的内核。

无论如何，这根本不一定是一个上下文切换问题。上下文切换适用于共享同一个CPU核心的线程/进程，但现在很少使用单核CPU，至少在您希望找到CentOS的计算机类上是如此。实际上，问题可能是子程序最初是否与父程序调度在同一个核心上，如果是的话，那么首先从fork()返回。

例如，假设在CentOS 6上，子和父级通常会被调度(最初)在同一个核心上，而子核首先得到该核心。在这种情况下，只要子节点在第一次生成CPU之前设置了它的信号处理程序，父程序就根本不需要延迟。另一方面，如果在CentOS 7上，子进程通常会被安排在不同的核心上，并且两个进程都会立即进行，那么在突然之间实际上并不重要的延迟确实很重要。顺便说一句，从大多数衡量标准来看，这将是一种绩效改善。

当然，所有这些都是推测性的。主要的问题是你的方法有很大的缺陷。家长不应该试图猜测孩子什么时候准备好。相反，它应该等待孩子宣布它的准备。子对象可以通过管道或向父节点发送信号，或者更好的方式是通过共享信号量或互斥对象(毕竟这些对象是用于什么的)进行同步。

Answer 2

编译不同的内核的行为也不同。这样的事情不能依赖时间间隔。既然您在父程序中安装了信号处理程序，那么为什么不只是反转逻辑:当子进程准备就绪时，它可以向父进程发送信号，然后父进程可以开始控制子进程--没有人在忙着睡觉，所有事情都是由事件驱动的。