电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 超线程加快了 Linux 的速度单处理器上的多处理器性能-4 [打印本页]

作者: look_w 时间: 2018-4-16 21:21 标题: 超线程加快了 Linux 的速度单处理器上的多处理器性能-4

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 表示的。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)