在我的印象中，当谈到提高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性能/延迟方面无关紧要？
答案 0 :(得分：0)
试用hackbench。有趣的是看到结果。虽然它可以对调度程序进行基准测试，但您可以更改代码以对IPC进行基准测试。
Hackbench既是Linux内核调度程序的基准测试，也是压力测试。它的主要工作是创建指定数量的可调度实体对（线程或传统进程），这些实体通过套接字或管道进行通信，并计算每对来回传输数据所需的时间。
http://www.makelinux.net/man/8/H/hackbench
如果您想要与管道和套接字不同的IPC，您可以修改Hackbench源代码。