Linux kernel 哪一项对IPC性能影响更大？上下文切换还是进程数？

在我的印象中，当谈到提高IPC性能或降低延迟时，上下文切换似乎是最重要的因素。但我总是想知道为什么我从来没有听说过可运行进程的数量也是一个因素

如果我理解正确的话，对于大多数现代CPU来说，上下文切换可以由硬件执行，这将大大减少浪费在这方面的时间。另一方面，CPU时间由系统中所有可运行的进程共享。系统中处理的可运行性越高，进程获得CPU控制的机会就越少。虽然在一般情况下，大多数进程应该在大部分时间处于睡眠状态，但这只是对系统的一个不合理的假设，我认为它不能适用于所有可能的情况

例如，假设系统配置为具有循环调度程序、1ms时间片和7个具有相同优先级的可运行进程，如下所示：

    P1 P2 P3 P4 P5 P6 P7

    P1 P2 P3 ... P99 P100

根据循环调度的定义，上下文切换顺序应为：

    P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> P7 -> P1 -> P2 -> ... -> P6 -> P7 -> P1 -> P2 -> ... -> P7 -> P1 -> ... and so on

由于上面的上下文切换顺序，如果P1试图通过某些IPC机制向P5发送消息，则该消息将在3ms后由P5处理。这是因为P5需要等待P2、P3和P4消耗自己的时间片，因此P5最终被安排运行并处理P1发送的消息。因此，在这种情况下，IPC延迟至少为3ms，这比上下文切换所需的时间大得多，上下文切换通常为µs数量级！如果P5想要回复P1已经发送的消息，那么会浪费另外2毫秒，因为P6和P7必须提前完成轮次。往返延迟时间应为：3ms+2ms=5ms

如果按如下方式引发可运行进程数：

    P1 P2 P3 P4 P5 P6 P7

    P1 P2 P3 ... P99 P100

从P13到P57发送消息的IPC延迟为：57-13-1ms=43ms

---

总之。。。上述问题真的存在吗？在测试或测量IPC性能时，是否会考虑可运行进程的数量？或者为什么系统中可运行进程的数量与IPC性能/延迟无关？

试用hackbench。看到结果很有趣。虽然它对调度程序进行基准测试，但您可以更改代码以对IPC进行基准测试

Hackbench是Linux内核调度器的基准测试和压力测试。它的主要工作是创建指定数量的可调度实体对（线程或通过套接字或管道进行通信的传统进程），以及每对来回发送数据所需的时间

---

如果您需要不同于管道和套接字的IPC，可以修改Hackbench源代码。

我已经尝试过并运行了1000次Hackbench。在最坏的情况下会持续0.012秒。命令行：'./hackbench 1进程1用法：hackbench[-pipe][process | thread][loops]'*1000次->最坏情况输出：'运行1*40==40个任务。时间：0.012’hackbench源代码来自我不知道hackbench用于测试的确切逻辑，除非深入研究代码。但是我猜目标是默认的CFS调度程序，而不是循环调度程序，这应该仍然是一个很好的参考，因为这个问题应该存在于所有实现抢占式多任务的调度程序中。