在 Linux 上，同一进程的线程之间的上下文切换成本

Question

Linux 上同一进程的线程之间的上下文切换成本是否有任何好的经验数据(主要是 x86 和 x86_64 感兴趣)？我说的是一个线程在自愿或非自愿进入休眠状态之前在用户空间中执行的最后一条指令与同一进程的不同线程在同一 cpu/核心上唤醒后执行的第一条指令之间的周期数或纳秒数.

我编写了一个快速测试程序，它在分配给同一 cpu/核心的 2 个线程中不断执行 rdtsc，将结果存储在一个 volatile 变量中，并与它的姊妹线程对应的 volatile 变量进行比较。它第一次检测到姐妹线程的值发生变化时，打印出差异，然后返回循环。我在 Atom D510 cpu 上以这种方式获得了大约 8900/9600 周期的最小/中值计数。这个程序是否合理，数字是否可信？

我的目标是估计，在现代系统上，每连接一个线程的服务器模型是否可以与选择类型的多路复用相媲美，甚至胜过它。这在理论上似乎是合理的，因为从对 fd X 执行 IO 到 fd Y 的转换只涉及在一个线程中休眠并在另一个线程中唤醒，而不是多个系统调用，但这取决于上下文切换的开销。

Answer 1

(免责声明:这不是对问题的直接回答，只是希望对您有所帮助的一些建议)。

首先，您得到的数字听起来肯定在大概范围内。但是请注意，在实现相同 ISA 的不同 CPU 型号之间，中断/陷阱延迟可能会很多。如果您的线程使用了浮点或 vector 运算，情况也不同，因为如果它们没有使用，内核会避免保存/恢复浮点或 vector 单元状态。

您应该能够通过使用内核跟踪基础结构获得更准确的数字 - perf sched特别是旨在测量和分析调度程序延迟。

如果您的目标是为每个连接的服务器建模，那么您可能不应该测量非自愿的上下文切换延迟 - 通常在这样的服务器中，大多数上下文切换都是自愿的，因为线程阻塞在 read() 等待来自网络的更多数据。因此，更好的测试平台可能涉及测量从 read() 中的一个线程阻塞到另一个线程从同一线程中被唤醒的延迟。

请注意，在重负载下编写良好的多路复用服务器中，从 fd X 到 fd Y 的转换通常会涉及相同的单个系统调用(作为服务器迭代从单个 epoll()) 返回的事件文件描述符列表。一个线程还应该比多个线程具有更少的缓存占用空间，只需一个堆栈即可。我怀疑解决这个问题的唯一方法(对于“解决”的某些定义)可能是进行基准枪战......