哪一个对 IPC 性能的影响更大？上下文切换或进程数？

Posted 2023-02-16

【中文标题】哪一个对 IPC 性能的影响更大？上下文切换或进程数？

【英文标题】：Which one affects IPC performance more? context switch or number of processes?

【发布时间】：2015-03-04 13:47:02

【问题描述】：

在我的印象中，当谈到提高 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 性能/延迟无关？

【参考方案1】：

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

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

http://www.makelinux.net/man/8/H/hackbench

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

【讨论】：

我已经尝试过运行 hackbench 1000 次。在最坏的情况下需要 0.012 秒。命令行：'./hackbench 1 process 1 # Usage: hackbench [-pipe] [process|thread] [loops]' * 1000 times -> Worst-case output: 'Running with 1*40 (== 40) 任务。时间：0.012'（hackbench 源码来自people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c）

除非深入研究代码，否则我不知道 hackbench 用于测试的确切逻辑。但我猜目标是默认的 CFS 调度程序而不是循环，这仍然应该是一个很好的参考，因为该问题应该存在于各种实现抢先式多任务处理的调度程序中 (en.wikipedia.org/wiki/…)。