多核系统上的Linux线程调度差异？答案

【问题标题】：Linux thread scheduling differences on multi-core systems?多核系统上的Linux线程调度差异？
【发布时间】：2011-09-01 02:07:45
【问题描述】：

我们有几个对延迟敏感的“流水线”式程序，当在一个 Linux 内核上运行时与另一个内核相比，它们的性能下降是可测量的。特别是，我们发现 2.6.9 CentOS 4.x (RHEL4) 内核的性能更好，而 CentOS 5.x (RHEL5) 的 2.6.18 内核性能更差。

“管道”程序是指具有多个线程的程序。多个线程处理共享数据。每个线程之间都有一个队列。所以线程 A 获取数据，推入 Qab，线程 B 从 Qab 拉取数据，进行一些处理，然后推入 Qbc，线程 C 从 Qbc 拉取数据，等等。初始数据来自网络（由第 3 方生成）。

我们基本上测量从收到数据到最后一个线程执行其任务的时间。在我们的应用程序中，当从 CentOS 4 迁移到 CentOS 5 时，我们发现任何时间都增加了 20 到 50 微秒。

我使用了几种方法来分析我们的应用程序，并确定 CentOS 5 上增加的延迟来自队列操作（特别是弹出）。

但是，我可以通过使用任务集将程序绑定到可用内核的子集来提高 CentOS 5（与 CentOS 4 相同）的性能。

所以在我看来，在 CentOS 4 和 5 之间，有一些变化（可能是内核的变化）导致线程的调度方式不同（这种差异对我们的应用程序来说不是最理想的）。

虽然我可以使用任务集（或通过 sched_setaffinity() 在代码中）“解决”这个问题，但我的偏好是不必这样做。我希望有某种内核可调参数（或者可能是可调参数集合），它们的默认值在版本之间发生了变化。

有人有这方面的经验吗？也许还有更多需要调查的领域？

更新：在这种特殊情况下，该问题已通过服务器供应商 (Dell) 的 BIOS 更新得到解决。我在这个上拉了很长一段时间的头发。直到我回到基础，并检查了我的供应商的 BIOS 更新。可疑的是，其中一个更新说“在最大性能模式下提高性能”。一旦我升级了 BIOS，CentOS 5 就更快了——一般来说，特别是在我的队列测试和实际生产运行中。

【问题讨论】：

标签： linux multithreading scheduling latency rhel

【解决方案1】：

嗯.. 如果生产者-消费者队列中的 pop() 操作所花费的时间对您的应用程序的整体性能产生重大影响，我建议您的线程/工作流的结构不是最佳的，某处。除非队列上存在大量争用，否则如果任何现代操作系统上的任何 PC 队列推送/弹出都需要超过 µS 左右，我会感到惊讶，即使队列在经典的“计算机科学 117”中使用内核锁- 如何用三个信号量的方式制作有界PC队列。

您能否将工作最少的线程的功能吸收到工作最多的线程中，从而减少流经系统的每个整体工作项的推送/弹出次数？

【讨论】：

出队操作只会在较慢的情况下产生性能影响，即较新的 RHEL5 内核。根据我的实验，我对此的最佳猜测解释是，不同的线程被安排在核心上，从而失去缓存优势。我忘了说，我的机器有双四核 CPU 包。直观地说，如果跨两个 CPU 包调度的两个线程之间存在共享队列，那么性能将非常糟糕。但是，这只是一个猜测，因此是这个问题。 :)
我明白了。现在你提到它，我确实记得曾经故意填充一个线程间通信对象以确保两个实例不能位于同一缓存行上。我想如果涉及两个独立的包，事情会变得更加严峻:(
是的 - 我不知道你的线程间类/结构/什么中有多少数据，但你可以在启动时创建它们的池，确保它们的大小/秒4k 和页面边界？这应该会减少缓存刷新，因为没有两个内核必须在同一页数据上运行。
你也可以只使用posix_memalign，传入缓存行大小作为对齐方式
哦，对了——不知道“memalign”——主要是 Windows 开发人员，所以我必须“手动”做——添加额外的字节缓冲区并评估一次以确保编译器不会优化它们:)

【解决方案2】：

多年来，Linux 调度程序一直是变化和争论激烈的领域。您可能想尝试一个最近的内核并试一试。是的，您可能必须自己编译它——这对您有好处。您可能还（当您拥有较新的内核时）想考虑将不同的进程放在不同的容器中，并将其他所有内容放在一个额外的容器中，看看是否有帮助。

至于其他随机尝试，您可以提高各种进程的优先级，添加实时语义（注意，具有实时权限的错误程序可能会使系统的其余部分饿死）。

【讨论】：

如果没有将线程绑定到内核（即 taskset/sched_setaffinity()），在主线 2.6.39 内核（来自 elrepo）中延迟会显着变差。似乎无论进行什么更改，这对我们的程序类型都是不利的。我的问题的真正实质是，这些变化是什么？而且，除了成为内核专家之外，有没有办法从概念层面理解调度程序的变化？
@Matt：AFAIK 你最好的选择是通过内核新手更改列表kernelnewbies.org/Linux26Changes 讨论性能和调度程序调整，并准备好测试大量内核。