AIM9 基准测试程序是单用户工作负载，旨在测量硬件和操作系统的性能。结果如表 2 所示。该基准测试程序中的大多数测试在使用超线程和不用超线程情况下执行性能都相同，只是同步文件操作和整数过滤（Integer Sieve）有所不同。同步随机磁盘写操作（Sync Random Disk Writes）、同步顺序磁盘写操作（Sync Sequential Disk Writes）和同步磁盘复制（Sync Disk Copies）这三个操作在使用超线程的情况下都慢了将近 35%。相反，在整数过滤的情况下使用超线程比不使用超线程速度提高了 60%。
[align=center]
表 2. 超线程对 AIM9 工作负载的影响[/align]
超线程对" Linux 多线程应用程序工作负载的影响
为测量超线程对 Linux 多线程应用程序的影响，我们使用模仿聊天室的 chat 基准测试程序。该基准测试程序包括了客户机和服务器。该基准测试程序的客户机端将报告每秒钟所发送的消息数；聊天室和消息的数量将控制工作负载。该工作负载创建许多线程和 TCP／IP 连接，并发送和接收许多消息。它使用了以下缺省参数：
聊天室个数 = 10
消息数 = 100
消息大小 = 100 字节
用户数 = 20
缺省情况下，每个聊天室有 20 位用户。10 个聊天室一共有 20x10 = 200 位用户。客户机将为聊天室里的每位用户创建至服务器的连接。由于我们有 200 位用户，所以我们将有 200 个到服务器的连接。现在，为聊天室中的每个用户（或连接）都创建了一个“发送”线程和一个“接收”线程。因此，“10 个聊天室”方案将创建 10x20x2 = 400 个客户机线程和 400 个服务器线程，一共是 800 个线程。但事实上不止这些。
每个客户机“发送”线程将把指定数量的消息发送给服务器。对于 10 个聊天室和 100 条消息而言，客户机将发送 10x20x100 = 20,000 条消息。服务器“接收”线程将接收相应数量的消息。聊天室服务器将把每条消息传回给聊天室中的其他用户。因而，对于 10 个聊天室和 100 条消息而言，服务器“发送”线程将发送 10x20x100x19 = 380,000 条消息。客户机“接收”线程将接收相应数量的消息。
通过命令行会话启动聊天服务器，以另一个命令行会话启动客户机，来开始测试。客户机模拟工作负载，并且其结果表示由该客户机所发送的消息数。当客户机结束其测试时，服务器循环并接受来自该客户机的其它启动消息。在我们的测量中，我们用 20、30、40 和 50 个聊天室来运行该基准测试程序。相应的连接和线程数如表 3 所示。
[align=center]
表 3. 所测试的聊天室和线程的数量[/align]
表" 4 显示了超线程对聊天工作负载性能的影响。每个数据点表示五次运行的几何平均数。数据集清楚地说明超线程根据聊天室的数量能将工作负载吞吐量提高 22% 到 28%。大体说来，基于 4 个聊天室样本的几何平均数，超线程将把聊天性能提高 24%。
[align=center]
表 4. 超线程对聊天吞吐量的影响
图 1. 超线程对聊天工作负载的影响[/align]
swallow 于 2006-11-13 09:59:25发表:
除了 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%。
[align=center]
表 7. 超线程对 Linux 内核 2.5.32 的影响[/align]
swallow 于 2006-11-13 09:58:29发表:
tbench 是类似于 dbench 的另一个文件服务器工作负载。但是，tbench 只产生 TCP 和进程负载。tbench 进行套接字调用，和 SMBD 在 netbench 负载下进行的调用相同，但是 tbench 不进行文件系统调用。tbench 背后的思想是将 SMBD 从 netbench 测试中消除掉，尽管可以使 SMBD 代码快速运行。tbench 的吞吐量结果告诉我们，如果我们消除所有文件系统 I/O 和 SMB 信息包处理，netbench 可以运行得有多快。tbench 被构建成 dbench 包的一部分。
表 6 描述了超线程对 tbench 工作负载的影响。和前面一样，每个数据点代表五次运行的几何平均数。超线程的确会提高 tbench 的吞吐量，提高幅度从 22% 到 31%。基于这五个测试方案的几何平均数，整体提高幅度为 27%。
[align=center]
表 6. 超线程对 tbench 吞吐量的影响
图 3. 超线程对 tbench 工作负载的影响[/align]
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（所有的虚拟处理器必须为空闲），产生的代码就会“神奇地实现”在超线程系统进行调度的需要。
swallow 于 2006-11-13 09:57:41发表:
超线程对" Linux 多线程文件服务器工作负载的影响
用 dbench 及其“同伴”测试 tbench 来测量超线程对文件服务器的影响。dbench 类似于 Ziff-Davis Media 基准程序中著名的 NetBench 基准测试程序，它让您在文件服务器处理来自客户机的网络文件请求时，测量其性能。但是，NetBench 要求精心设置实际的物理客户机，而 dbench 则模拟 90,000 个操作以产生相同的工作负载，这些操作通常由 NetBench 客户机通过嗅探称为 client.txt 的 4 MB 文件来运行。这个文件的内容是文件操作伪指令，例如 SMBopenx、SMBclose、SMBwritebraw 和 SMBgetatr 等。这些 I/O 调用符合服务器消息块（Server Message Block，SMB）协议，SAMBA 中的 SMBD 服务器在 netbench 运行中将产生该协议。SMB 协议被 Microsoft Windows 3.11、NT 和 95/98 用于共享磁盘和打印机。
在我们的测试中，一共使用了 18 种不同类型的 I/O 调用，包括打开文件、读、写、锁定、解锁、获取文件属性、设置文件属性、关闭、获取磁盘可用空间、获取文件时间、设置文件时间、“查找”打开、“查找”下一个、“查找”关闭、重命名文件、删除文件、创建新文件和清空文件缓冲区。
dbench 可以模拟任何数量的客户机，而不必进行物理设置。dbench 只产生文件系统负载，它没有联网调用。运行期间，每个客户机记录所移动的数据字节数并将该数除以移动该数据所需的时间量。然后累加所有的客户机吞吐量数以确定该服务器的总吞吐量。总的 I/O 吞吐量分数表示测试期间每秒钟所传送的兆字节数。这个测量说明该服务器对来自客户机的文件请求的处理质量。
dbench 非常适合于对超线程的测试，因为它对 CPU 和 I/O 调度程序创建了大量负载和活动。dbench 可以严格测试超线程支持多线程文件服务的能力，因为客户机同时创建和访问许多文件。每个客户机必须创建相当于大约 21 兆字节的测试数据文件。对于要运行 20 个客户机的测试，预计要大约 420 兆字节的数据。对于测量 Linux 文件系统所用的电梯算法性能，dbench 被认为是非常不错的测试方法。dbench 用于测试该算法的工作正确性，并测试电梯的反应是否足够快速。它还是很有趣的页面替换测试。
表 5 显示了 HT 对 dbench 工作负载的影响。每个数据点表示五次运行的几何平均数。数据说明了超线程将 dbench 的性能最少提高了 9%，最多提高了 29%。基于这五个测试方案的几何平均数，总体的提高幅度是 18%。
[align=center]
图 2. 超线程对 dbench 工作负载的影响[/align]