超线程加快了 Linux 的速度 单处理器上的多处理器性能-4

look_w

tbenchtbench 是类似于 dbench 的另一个文件服务器工作负载。但是，tbench 只产生 TCP 和进程负载。tbench 进行套接字调用，和 SMBD 在 netbench 负载下进行的调用相同，但是 tbench 不进行文件系统调用。tbench 背后的思想是将 SMBD 从 netbench 测试中消除掉，尽管可以使 SMBD 代码快速运行。tbench 的吞吐量结果告诉我们，如果我们消除所有文件系统 I/O 和 SMB 信息包处理，netbench 可以运行得有多快。tbench 被构建成 dbench 包的一部分。
表 6 描述了超线程对 tbench 工作负载的影响。和前面一样，每个数据点代表五次运行的几何平均数。超线程的确会提高 tbench 的吞吐量，提高幅度从 22% 到 31%。基于这五个测试方案的几何平均数，整体提高幅度为 27%。
表 6. 超线程对 tbench 吞吐量的影响客户机的数量2419s-noht2419s-ht加速2060.9879.8631%3059.9477.8230%6055.8570.1926%9048.4558.8822%12037.8547.9227%几何平均数51.8465.7727%注：这些数据是用 MB/sec 表示的吞吐量：越大越好。图 3. 超线程对 tbench 工作负载的影响Linux 内核 2.5.x 中的超线程支持Linux 内核 2.4.x 自 2.4.17 发行版起就支持 HT。内核 2.4.17 了解逻辑处理器，并将超线程处理器当作两个物理处理器。但是，仍然认为现有的内核 2.4.x 中所使用的调度程序还不成熟，因为它不能区别是两个逻辑处理器在争用资源，还是两个单独的物理处理器在争用资源。
Ingo Molnar 已经指出了当前调度程序出现错误的一些情况（请参阅 以获取链接）。请研究一下带有两个物理 CPU 的系统，每个 CPU 提供两个虚拟处理器。如果两个任务正在运行，当前调度程序会让它们同时在单个物理处理器上运行，即使将其中一个进程迁移到另一个物理 CPU 会得到好得多的性能。该调度程序还不明白：将进程从一个虚拟处理器迁移到另一个虚拟处理器（同一物理 CPU 上的逻辑 CPU）要比将进程在物理处理器之间进行迁移来得更省力（由于高速缓存装入）。      
解决方案是更改运行队列的工作方式。2.5 调度程序在每个处理器中维持一个运行队列，并设法避免在队列之间移动任务。这种更改是让每个物理处理器拥有一个运行队列，它能将任务提供给所有的虚拟处理器。这样就比较清晰地说明，是什么产生了空闲 CPU（所有的虚拟处理器必须为空闲），产生的代码就会“神奇地实现”在超线程系统进行调度的需要。
除了 2.5 调度程序中运行队列的更改之外，还要进行其它必要的更改，以使 Linux 内核能够利用 HT 达到最佳性能。Molnar 讨论过的那些更改（请再次参阅        参考资料以获取有关此内容的更多信息）如下所示。      

• 支持 HT 的被动的负载均衡：         
  用 IRQ 驱动的均衡操作必须针对各个物理 CPU，而不是各个逻辑 CPU。否则，可能会发生：一个物理 CPU 运行两个任务，而另一个物理 CPU 不运行任务；现有的调度程序不会将这种情形认为是“失衡的”。在调度程序看来，似乎是第一个物理处理器上的两个 CPU 运行 1-1 任务，而第二个物理处理器上的两个 CPU 运行 0-0 任务。现有的调度程序没有意识到这两个逻辑 CPU 属于同一个物理 CPU。
• “主动的”负载均衡：         
  当一个逻辑 CPU 变成空闲，从而造成一个物理 CPU 失衡时，会出现这种情况。只有在现有的 1:1 调度程序中才不会出现这个机制。由空闲 CPU 引起的失衡可以通过常见的负载均衡器来解决。在使用 HT 的情况下，这种情形很特殊，因为源物理 CPU 可能只有两个任务在运行，而两个都可以运行。现有的负载均衡器不能处理这种情形，因为正在运行的任务难以迁移。而这个迁移是必需的 － 否则一个物理 CPU 费力地运行两个任务，而另一个物理 CPU 却保持空闲。
• 支持 HT 的任务挑选：         
  当调度程序挑选了一个新任务时，它在尝试从其它 CPU 接收任务之前，应该优先挑选所有共享同一物理 CPU 的任务。现有的调度程序只挑选那些被调度到特定逻辑 CPU 的任务。
• 支持 HT 的亲缘性：         
  这些任务应当设法“盯牢”物理 CPU，而不是逻辑 CPU。
• 支持 HT 的唤醒：         
  现有的调度程序只知道“当前”CPU，不知道其任何“伙伴”CPU。在 HT 上，如果一个逻辑 CPU 正在执行任务，其上的一个线程被唤醒了，而且其“伙伴”CPU 是空闲的，那么该“伙伴”CPU 必须被唤醒以立即执行刚唤醒的任务。

在撰写本文时，Molnar 已经提供了现有的内核 2.5.32 补丁程序，它通过引入共享运行队列（多个 CPU 可以共享同一个运行队列）的概念来实现上述所有更改。共享的、针对每个物理 CPU 的运行队列实现了上面所列的所有 HT 调度操作的需要。显然，这使调度和负载均衡变得复杂了，而且这对 SMP 和单处理器调度程序的影响仍然是未知的。
Linux 内核 2.5.32 中的更改旨在对带有两个以上 CPU 的 Xeon 系统产生影响，尤其是在负载均衡和线程亲缘性这些区域方面。由于硬件资源限制，我们只能测量其在我们单 CPU 测试环境中的影响。使用 2.4.19 中所使用的相同测试进程，我们在 2.5.32 上运行了三个工作负载：chat、dbench 和 tbench。对于 chat 而言，在有 40 个聊天室的情况下，HT 可以将速度提高 60%。整体提高幅度大约为 45%。对于 dbench 而言，27% 是最高的提高幅度，整体提高幅度大约为 12%。对于 tbench 而言，整体提高幅度大约为 35%。
表 7. 超线程对 Linux 内核 2.5.32 的影响chat 工作负载聊天室的数量2532s-noht2532s-ht加速20137,792207,78851%30138,832195,76541%40144,454231,50947%50137,745191,83439%几何平均数139,678202,03445%dbench 工作负载客户机的数量2532s-noht2532s-ht加速20142.02180.8727%30129.63141.199%6084.7686.021%9067.8970.374%12057.4470.5923%几何平均数90.54101.7612%tbench 工作负载客户机的数量2532s-noht2532s-ht加速2060.2882.2336%3060.1281.7236%6059.7381.236%9059.7180.7935%12059.7379.4533%几何平均数59.9181.0735%注：chat 数据是用 client/sec 表示的发送消息数；dbench 和 tbench 数据是用 MB/sec 表示的。