centos7中的上下文切换延迟

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

这段代码在CentOS6中执行得很好，只有少数情况下，在父进程发送信号之前，子进程的睡眠时间不足以设置其信号处理程序。然而，当此代码在CentOS7中以相同的系统规范运行时，子级始终未能及时安装其信号处理程序。我不得不将睡眠时间增加到10毫秒（长1000倍），以获得与CentOS6相同的性能

---

我想知道在相同规格的硬件上，CentOS 7相对于CentOS 6的上下文切换速度如此之慢的原因是什么？

不同编译的内核表现不同。你不能依赖时间间隔来完成这些事情。既然您在父级中安装了信号处理程序，为什么不颠倒逻辑：当子级准备就绪时，它可以向父级发送信号，然后父级可以开始控制子级-没有人忙于睡眠，所有事情都是事件驱动的

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

在任何情况下，这都不一定是一个上下文切换问题。上下文切换适用于共享同一CPU[核心]的线程/进程，但如今单核心CPU已不多见，至少在您希望找到CentOS的机器类别上是如此。事实上，问题可能是最初是否将子级调度在与父级相同的核心上，如果是，则首先从

fork（）

返回哪个

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

---

当然，所有这些都是推测性的。主要问题是你的方法存在严重缺陷。父母不应该试图猜测孩子什么时候准备好。相反，它应该等待孩子宣布它准备好了。子对象可以通过管道或向父对象发送信号来进行同步，或者更好的方法是，它们可以通过共享信号量或互斥来进行同步（这毕竟是这些对象的用途）。

您能告诉我们stock Linux实际允许的最长sontext切换时间在哪里吗？如果你需要这样，你必须使用RTOS；可能是带有RT扩展的Linux，但无论如何。