在我的印象中，当谈到提高IPC性能或降低延迟时，上下文切换似乎是最重要的因素。但我一直在想，为什么我从未听说可运行进程的数量也是一个因素？
如果我理解正确的话，大多数现代CPU的上下文切换都可以由硬件执行，这将大大减少浪费在这方面的时间。另一方面，CPU时间由系统中所有可运行的进程共享。系统中可运行的进程越多，进程获得CPU控制的机会就越少。（尽管一般来说，大多数进程在大部分时间都应该处于睡眠状态，但这只是对系统的不合理假设，我认为这不可能适用于所有可能的情况。）
例如，假设一个系统被配置为具有循环调度程序、1ms的时间片和7个具有相同优先级的可运行进程，如下所示：
P1 P2 P3 P4 P5 P6 P7
根据循环调度的定义，上下文切换顺序应该是：
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已经发送的消息的答复，则浪费另外2ms，因为P6和P7必须提前完成它们的回合。以及往返延迟时间(https://en.wikipedia.org/wiki/Round-trip_delay_time)应为：3ms+2ms=5ms！
如果可运行进程的数量增加如下：
P1 P2 P3 ... P99 P100
从P13发送到P57的消息的IPC延迟为：（57-13-1）ms=43ms
所以最后。。。上述问题真的存在吗？在测试或测量IPC性能时，是否会考虑可运行进程的数量？或者，为什么系统中可运行进程的数量与IPC性能/延迟无关？
试用hackbbench。看到结果很有趣。尽管它对调度器进行了基准测试，但您可以更改代码以对IPC进行基准测试。
Hackbench既是Linux内核调度器的一个基准测试，也是一个压力测试。它的主要工作是创建指定数量的可调度实体对（线程或传统进程），这些实体通过套接字或管道进行通信，并确定每对来回发送数据所需的时间。
http://www.makelinux.net/man/8/H/hackbench
如果你想要不同于管道和套接字的IPC，你可以修改Hackbench的源代码。