linux - 更多线程意味着更多上下文切换？ Linux 内核也是如此吗？

Question

似乎有一个广泛传播的想法，即更多的线程意味着更多的上下文切换，但碰巧我不太接受这个想法——至少我觉得为什么会这样。

按照我的理解，我们的 CPU 在任何给定时刻都分配了一堆要运行的线程——它们的运行队列。在现代 Linux 内核中，这些运行队列实际上包含在红黑树中，因此对于每个运行任务都会按 O(lg n) 的顺序对该树执行操作。从这个角度来看，似乎如果我们有一个运行大量线程的系统，平均而言，这个 O(lg n) 的 n 也会增加——但这并没有真正增加上下文切换次数，只是增加了每次上下文切换的成本。

从所有其他角度来看，我不认为拥有更多或更少的线程会增加上下文切换。它可能会增加使用的内存(至少一个用户空间和一个内核空间堆栈，可能还加上线程或至少 CPU 本地内存池)，但不会增加上下文切换的数量。

让我们想象一下，我有一个程序，其并行工作负载令人尴尬，需要运行数小时，并且有大量内存可供使用。比如说，拥有 8 个完全受 CPU 限制的线程(在 8 核机器中)或 64 个线程之间有什么区别？我能看到差异的唯一原因是，随着运行队列中线程数量的增加，Linux 调度程序算法是否会分配更小的切片(当然，在一定程度上)？

我在这里缺少什么？谢谢!

Answer 1

是的，你说得对。无论每个 cpu 有 N 个就绪线程还是 (N+1) 个，都会有相同数量的上下文切换。如果每个 CPU 1 个线程，您的并行应用程序将运行得最快。

runq 的长度对上下文切换开销没有显着影响；更多的CPU缓存、页表缓存等被重新分配。典型的工作负载既不是令人尴尬的并行也不是只读的；尤其是在像 condvars 争用这样的领域，线程数量可能会露出丑陋的一面。如果你用 google 搜索一下 golang 调度程序，就会发现 GopherCon 2018 上有一篇关于它的精彩演讲。