同时多线程

2002年，Intel在Pentium 4上首次引入Hyper-Threading，宣称"一个物理核变两个逻辑核"。但很多用户发现，开启HT后某些工作负载反而变慢了。这个看似矛盾的结果揭示了SMT设计中最深刻的权衡——资源共享的收益和干扰之间的博弈。更令人警醒的是，2018年，PortSmash攻击证明SMT的资源共享还可以被利用为侧信道攻击向量，迫使多个云服务商关闭了生产环境的SMT。这些事件迫使我们追问一个根本性问题：让多个线程同时共享一个物理核心，究竟是巧妙的工程优化，还是一个注定充满隐患的设计选择？

设计提示

统一视角连接。处理器设计的本质是在有限的晶体管预算和功耗约束下，通过投机和并行的层层叠加来逼近指令吞吐率的理论上限。SMT是并行的终极体现——它不是增加硬件资源来获取并行（如多核），而是让多个线程并行共享现有资源来提高利用率。但共享意味着竞争，竞争意味着干扰——SMT的设计本质就是管理这种干扰。如果说超标量乱序执行（第 23.0 章 $\sim$ 第 38.0 章）是从单一线程中在空间上寻找独立指令来并行执行，那么SMT就是从多个线程中在时间上交叉选取指令来填充空闲资源。超标量挖掘ILP，SMT挖掘TLP，两者正交且互补。

现代处理器面临一个根本性的矛盾：为了提高单线程性能，处理器配备了越来越多的执行单元和越来越深的流水线，但单一线程中可开发的指令级并行性（ILP）是有限的。当流水线中出现cache miss、分支误预测或长延迟操作时，大量的执行资源处于空闲状态——这些空闲的功能单元、空闲的发射槽位、空闲的流水线级在每个周期都在消耗静态功耗却不产出任何有用的工作。

同时多线程（Simultaneous Multithreading，SMT）的核心思想极为直接：既然单一线程无法填满所有执行资源，那么就让多个线程同时共享这些资源。在同一个物理核心上同时维护多个体系结构状态（PC、寄存器文件、控制寄存器等），在同一个周期内从不同线程取指、解码、重命名、发射和执行指令，使得原本因某个线程停顿而空闲的执行槽位可以被其他线程的指令填充。

SMT的价值在于它以极低的额外面积代价（通常不到30%）换取了显著的吞吐量提升（在多线程负载下通常也约30%）。然而，SMT也引入了线程间的资源竞争、安全侧信道、单线程性能回退等复杂问题。本章将从线程级并行的基本概念出发，系统地讨论SMT的微架构设计、实际实现和安全挑战。

从系统层次的角度看，SMT位于操作系统线程调度和微架构指令调度的交汇处。操作系统将线程分配到逻辑处理器（logical processor），每个逻辑处理器对应一个SMT硬件线程上下文；微架构在每个时钟周期内从所有活跃的硬件线程中选取指令进行处理。这种软硬件协同使得SMT可以利用操作系统级别的并行性（多线程/多进程）来提高微架构级别的资源利用率。

线程级并行的利用

在深入SMT之前，我们需要理解多线程处理器的三种基本范式——细粒度多线程、粗粒度多线程和同时多线程。这三种设计在线程切换的粒度和资源共享的程度上有着本质的区别。

多线程技术的根本动机来自一个简单但深刻的观察：在现代超标量处理器中，单一线程的指令级并行性（ILP）是有限的。Jouppi和Wall在1989年的经典研究表明，典型的整数程序中可开发的ILP约为2 $\sim$ 4条指令/周期，而浮点程序约为4 $\sim$ 8条指令/周期。即使使用最先进的分支预测器和乱序执行引擎，在8-wide以上的超标量处理器中，单线程的平均发射率通常不超过宽度的60% $\sim$ 70%——这意味着30% $\sim$ 40%的执行资源在每个周期都处于空闲状态。

这些空闲资源有三种来源：（1）水平浪费——某个周期中可用的发射槽位未被填满，因为线程中没有足够的就绪指令；（2）垂直浪费——整个周期完全空闲（如因分支预测失败而冲洗流水线的周期）；（3）结构冒险——所需的功能单元被其他指令占用。三种多线程技术分别擅长于利用不同类型的空闲资源：FGMT主要利用垂直浪费，CGMT利用长停顿期间的完全垂直浪费，而SMT同时利用水平浪费和垂直浪费——这也是SMT效率最高的根本原因。

细粒度多线程

细粒度多线程（Fine-Grained Multithreading，FGMT）是最早期的多线程技术之一。其核心机制是在每个时钟周期切换执行的线程——周期0执行线程A的指令，周期1执行线程B的指令，周期2再回到线程A（如果只有两个硬件线程），如此交替进行。

这种逐周期交替的设计有一个优雅的工程效果：由于连续两条流水线中的指令来自不同的线程，它们之间不存在数据依赖。这意味着前一条指令的结果不需要旁路到下一条指令，流水线中的许多数据冒险（data hazard）被自然消除。在传统的单线程流水线中，旁路网络和流水线互锁逻辑占据了相当可观的面积和功耗——细粒度多线程通过线程交替执行，使得这些冒险处理机制可以被大幅简化甚至完全去除。

细粒度多线程的流水线执行示意。4个线程在4级流水线中逐周期轮转，任意时刻每一级中的指令来自不同线程，天然消除了数据冒险。

::: warning 性能分析 1 — 细粒度多线程的吞吐量模型

设一个 $N$ 线程的细粒度多线程处理器，流水线深度为 $D$ ，每个线程的L1 cache miss率为 $p_{\text{miss}}$ ，miss延迟为 $L_{\text{miss}}$ 个周期。

在 $N \geq D$ 时，流水线中每一级在每个周期都有一条来自不同线程的指令。每个线程的等效IPC为： $ $\text{IPC}_t = \frac{1}{N} \times (1 - p_{\text{miss}}) + \frac{1}{N + L_{\text{miss}}} \times p_{\text{miss}} \approx \frac{1}{N}$ $ （当 $L_{\text{miss}} \ll N$ 时，miss延迟被轮转间隔自然隐藏）。

总吞吐量为 $N \times \text{IPC}_t = 1.0$ 条指令/周期（1-wide流水线）。这意味着 $N$ 个线程的细粒度多线程可以将1-wide流水线的吞吐量提升到接近1.0 IPC——尽管每个线程的IPC仅为 $1/N$ 。

对于 $W$ -wide的超标量流水线，总吞吐量上限为 $W$ 条指令/周期。如果 $N$ 个线程的联合指令供给能力大于 $W$ ，则FGMT可以接近 $W$ IPC的峰值利用率。这正是GPU中数千线程FGMT能实现极高ALU利用率的原因。

:::

Sun UltraSPARC T1（代号Niagara，2005年）是细粒度多线程最著名的工业实现。每个核心支持4个硬件线程，以逐周期轮转的方式切换。流水线设计极为简洁——6级有序流水线，没有旁路网络，没有乱序执行机制。每个线程的单线程性能极低（IPC约为0.5 $\sim$ 0.8），但8个核心 $\times$ 4个线程提供了32个并发线程，在高度并行的服务器负载下实现了极高的吞吐量和极低的功耗。

UltraSPARC T1的后续产品UltraSPARC T2（代号Niagara 2，2007年）进一步将每核心的线程数扩展到8个，总共提供64个并发线程。T2还增加了每核心2条整数流水线，使得在8个线程充分供给的情况下，每周期可以发射2条指令（来自不同线程）。这种设计被称为"纵向多线程加横向超标量"的混合方式，是后来SMT思想的一种简化形式。

Oracle/Sun的后续产品SPARC T5（2013年）将这一设计推到了更极端的水平：16个核心，每核心8个线程，总计128个并发线程。每个核心拥有2条整数流水线和1条浮点流水线，在8线程充分供给下可以达到约3条指令/周期的IPC。SPARC T5在Java企业应用（如WebLogic Server、SAP HANA）中展示了极高的吞吐量——每CPU支持超过100万条Java线程的并发处理。这种"多线程多核心"的极端吞吐量设计思想直接影响了后来IBM POWER8/10的SMT8实现。

值得注意的是，SPARC T系列的细粒度多线程实现与后来的SMT有一个关键区别：SPARC T系列在每个时钟周期只从一个线程选择指令来填充其2-wide的发射槽位——虽然有2个执行管道，但同一周期内两条指令来自同一个线程。而真正的SMT（如Intel HT或IBM POWER SMT）允许在同一周期内从不同线程选取指令混合发射。SPARC T系列的设计更接近"2-wide FGMT"而非真正的SMT，但在高线程数下的吞吐量效果与SMT相似。

GPU（图形处理器）中的"warp"调度也是细粒度多线程的一种极端形式。NVIDIA的CUDA核心在每个流多处理器（SM）中维护数十个warp（每个warp包含32个线程），以逐周期或数周期轮转的方式切换warp来隐藏内存延迟和流水线延迟。GPU的线程数量远超CPU（一个SM可能维护超过1000个活跃线程），使得即使全局内存访问延迟高达数百周期，流水线仍能保持近乎满载。

细粒度多线程的核心优势和劣势可以概括如下：

延迟隐藏：当线程数量不少于流水线深度时，流水线中的数据冒险被完全消除。即使某个线程遇到cache miss（假设4周期的L1延迟），当该线程再次获得发射槽位时，数据可能已经返回。流水线始终保持满载状态。
硬件简化：无需旁路网络、互锁逻辑和复杂的冒险检测。每个线程需要独立的PC和寄存器文件，但流水线控制逻辑大幅简化。
单线程性能牺牲：这是细粒度多线程最根本的代价。在 $N$ 个线程轮转的情况下，每个线程每 $N$ 个周期才能执行一条指令，即使该线程没有任何停顿。单线程IPC的理论上限为 $1/N$ 。对于需要低延迟响应的交互式应用，这种性能降级是不可接受的。
线程数量要求：为了保持流水线满载，需要的活跃线程数量至少等于流水线深度。如果活跃线程不足，流水线中将出现气泡。这限制了细粒度多线程在线程数量较少时的效能。
上下文存储开销： $N$ 个硬件线程需要 $N$ 套完整的体系结构状态——包括 $N$ 组通用寄存器文件、 $N$ 个PC、 $N$ 组控制寄存器。这些状态在硬件中是常驻的——不同于操作系统的上下文切换（需要将寄存器保存到内存），硬件多线程将所有线程的体系结构状态永久存储在片上SRAM中。在SPARC架构中（32个通用寄存器 $\times$ 8个寄存器窗口 = 256个寄存器），4个线程需要1024个寄存器的存储——这是一个不可忽视的面积开销。然而，由于细粒度多线程不需要乱序执行的复杂结构（ROB、PRF重命名等），整体核心面积仍然很小。

表表 45.1列出了一些采用细粒度多线程的处理器实现。

处理器	年份	线程数/核	核心数	总线程数
Sun UltraSPARC T1	2005	4	8	32
Sun UltraSPARC T2	2007	8	8	64
Oracle SPARC T5	2013	8	16	128
Tera MTA	1998	128	1	128
NVIDIA GPU SM	2010+	32 $\sim$ 64 warps	多SM	数千

GPU中的细粒度多线程

GPU（图形处理器）中的warp调度是细粒度多线程最极端也最成功的应用。以NVIDIA的Ada Lovelace架构（RTX 4090）为例：

每个SM（Streaming Multiprocessor）包含128个CUDA核心，支持最多48个活跃warp（每个warp包含32个线程），总共 $48 \times 32 = 1536$ 个并发线程。
warp调度器每个周期从就绪的warp中选择一个发射指令。由于每个SM有4个warp调度器，每周期可以从4个不同的warp中各发射1条指令。
全局内存访问延迟高达200 $\sim$ 600个周期，但由于有48个warp可供切换，调度器几乎总能找到一个没有在等待内存的就绪warp来执行。
线程之间的切换是零成本的——每个warp的寄存器状态都常驻在寄存器文件中，不需要保存/恢复。代价是巨大的寄存器文件（每SM约256 KB）。

GPU的这种设计将细粒度多线程推到了极致：通过数千个硬件线程来隐藏数百周期的内存延迟，以寄存器文件的面积开销换取极高的执行效率。在GPU的吞吐量导向设计中，这种交换是完全划算的——每个SM的面积中，约30% $\sim$ 40%被寄存器文件占据，但换来的是接近100%的ALU利用率。

CPU中的SMT可以看作是GPU细粒度多线程的"缩小版"——用较少的线程（2 $\sim$ 8个）来隐藏较短的延迟（cache miss的10 $\sim$ 200个周期），在面积效率和单线程性能之间取得折衷。

设计提示

细粒度多线程本质上是一种空间换时间再时间换吞吐量的策略：用额外的体系结构状态存储空间（多套寄存器文件、PC等）消除流水线冒险，再用轮转调度将单线程性能换成多线程吞吐量。这种交换在高度并行的工作负载（如Web服务器、数据库事务处理）中是划算的，但在单线程性能敏感的应用中则得不偿失。

粗粒度多线程

粗粒度多线程（Coarse-Grained Multithreading，CGMT）采用了一种折衷策略：在正常执行期间只运行单一线程，但当该线程遇到长延迟事件——典型的如L2/L3 cache miss——时，切换到另一个线程继续执行。与细粒度多线程每周期切换不同，粗粒度多线程的线程切换是事件驱动的，切换频率远低于逐周期切换。

粗粒度多线程的关键设计参数是线程切换延迟——从检测到长延迟事件到新线程开始产出有效指令所需的周期数。这个延迟来自于两个方面：

流水线排空（Pipeline Drain）：当前线程在流水线中的指令需要完成执行或被取消。在有序流水线中，这需要等待流水线中最后一条指令到达写回级，通常需要与流水线深度相当的周期数。在乱序流水线中，情况更为复杂——ROB中可能有数十乃至上百条指令处于各种执行状态，全部完成或取消它们需要更长的时间。某些设计通过快速上下文冻结（fast context freeze）来加速排空——停止当前线程的提交但保留其流水线状态（ROB、发射队列中的表项不被释放），在切回该线程时从冻结点恢复执行。这种方法减少了排空开销但增加了资源占用。
流水线填充（Pipeline Fill）：新线程的指令从取指开始重新充填流水线。在一个15级流水线中，新线程的第一条指令需要15个周期才能到达写回级。此外，新线程还需要经历I-cache和分支预测器的暖机期——如果新线程的代码和数据在cache中完全是冷的，前几十条指令可能频繁cache miss，进一步延长有效的填充时间。

因此，对于一个 $D$ 级流水线，线程切换的总开销约为 $D$ 到 $2D$ 个周期。在典型的15 $\sim$ 20级流水线中，这意味着15 $\sim$ 40个周期的切换开销。只有当原始线程的停顿时间远大于切换开销时（如L2 miss的100+周期），粗粒度多线程才能带来净收益。

IBM POWER5（2004年）在实现SMT之前，其前身POWER4支持一种形式的粗粒度多线程。Intel的Montecito Itanium处理器（2006年）也采用了粗粒度多线程——当一个线程遇到L3 cache miss时，切换到备用线程，切换延迟约为23个周期。Alpha EV8处理器（虽然最终未投产，但设计于2001年完成）也计划实现一种CGMT/SMT混合方案——它是学术界和工业界对多线程技术探索的重要里程碑。

粗粒度多线程的触发逻辑

粗粒度多线程的性能关键在于切换触发逻辑——什么事件应该触发线程切换？过于激进的触发（如L1 cache miss就切换）会导致频繁的切换开销；过于保守的触发（如只在L3 miss时切换）会错过利用中等延迟停顿的机会。

典型的触发策略如下：

L2 miss触发：当L2 cache miss发生时触发切换。L2 miss的延迟通常为30 $\sim$ 100个周期（取决于LLC命中/miss），大于切换开销（ $\sim$ 25个周期），因此净收益为正。
ROB满触发：当ROB因长延迟事件而填满、无法再接纳新指令时触发切换。这是一个间接但更精确的触发条件——ROB满意味着处理器确实无法前进。
指令流枯竭触发：当前端因I-cache miss或分支预测器暖机而无法提供指令时触发切换。这种情况在代码段频繁变化的工作负载中较为常见。
软件触发：某些ISA（如POWER ISA、SPARC）提供了特殊的"线程yield"指令，允许软件主动放弃当前执行槽位。这在自旋锁等待和其他软件已知的等待场景中非常有用。

性能分析 2 — 粗粒度多线程的收益条件

设流水线深度为 $D$ ，线程切换开销为 $S$ 个周期（ $S \approx D$ 到 $2D$ ），长延迟事件的平均停顿时间为 $L$ 个周期。粗粒度多线程的净收益为： $ $\text{净节省周期} = L - S$ $ 只有当 $L > S$ 时切换才有正收益。对于典型参数： $D = 15$ ， $S = 25$ ， $L_{\text{L2 miss}} = 100$ ，净节省为75个周期。但如果仅是L1 miss（ $L \approx 12$ 个周期）， $L < S$ ，切换反而造成损失。

因此，粗粒度多线程的触发条件必须精心设计——只在确认为长延迟事件（L2/L3 miss或其他长停顿）时才触发切换，短暂的L1 miss不应触发切换。

粗粒度多线程的优势在于它对单线程性能的影响较小——在没有长延迟事件的时段，处理器完全专注于单一线程，性能与传统处理器相当。仅在长延迟停顿期间，原本浪费的周期被另一个线程利用。然而，切换开销意味着短暂停顿无法被有效利用，且每次切换都有一段生产率为零的"暖机"期。

粗粒度多线程的线程切换时序。当线程A遇到L2 miss后，经过流水线排空和线程B的填充阶段（总计约$D$到$2D$个周期的切换开销），线程B才开始产出有效指令。

粗粒度多线程的另一个重要变体是事件切换多线程（Switch-on-Event Multithreading，SoEMT）。在SoEMT中，切换事件不限于cache miss，还可以包括TLB miss、长延迟的除法操作、以及同步原语等待（如锁竞争）。通过扩大触发切换的事件类型，SoEMT可以更频繁地利用空闲周期。但这也增加了线程切换的频率和开销——处理器需要更快速的上下文保存/恢复机制。

在某些嵌入式处理器中，粗粒度多线程以极低成本的形式出现。例如，某些RISC-V处理器实现了2个硬件线程上下文，当一个线程执行WFI（Wait For Interrupt）指令或遇到外部中断延迟时，自动切换到另一个线程。这种轻量级的粗粒度多线程特别适合实时系统——一个线程运行主任务，另一个线程处理中断服务和后台维护任务。

粗粒度多线程与SMT的混合

一些处理器设计探索了CGMT与SMT的混合方案。在这种设计中，处理器同时维护 $T$ 个线程上下文（如4个），但只有 $S$ 个线程（如2个）同时在流水线中活跃执行（SMT模式）。其余 $T-S$ 个线程处于"就绪但不活跃"状态。当一个活跃线程遇到长延迟事件时，处理器将其切换为非活跃状态，并从就绪池中唤醒另一个线程——这是CGMT的切换机制，但切换速度比传统CGMT更快，因为备用线程的上下文已经驻留在硬件中。

IBM POWER7的SMT4实现中就包含了这种混合特性——4个线程上下文，但可以动态调整活跃线程数量。当某些线程因为持续的cache miss而不产出有效工作时，处理器可以暂时将其"冻结"（类似CGMT的线程切换），将执行资源集中给剩余的活跃线程。这种混合方案兼具了SMT的细粒度资源共享和CGMT的资源集中优势。

设计提示

粗粒度多线程在概念上与操作系统的上下文切换相似——都是在一个执行实体停顿时切换到另一个。关键区别在于粒度和开销：操作系统的上下文切换需要数百到数千个周期（保存/恢复完整寄存器状态、刷新TLB、可能的cache污染），而硬件的粗粒度多线程通常只需要十几到几十个周期（因为备用线程的体系结构状态始终驻留在硬件中）。

同时多线程

同时多线程（Simultaneous Multithreading，SMT）的概念最早由Dean Tullsen、Susan Eggers和Henry Levy在1995年的开创性论文《Simultaneous Multithreading: Maximizing On-Chip Parallelism》中提出，其核心思想是：在同一个时钟周期内，从多个线程中选取指令填充超标量处理器的多个发射槽位。这与细粒度多线程（每周期只执行一个线程的指令）和粗粒度多线程（在事件触发时才切换线程）有着本质的区别。

Tullsen等人在原论文中使用了一个8-wide的超标量处理器模型进行模拟，展示了SMT在同时运行8个SPEC92基准程序时可以达到接近6.0的联合IPC——而同一处理器运行单线程时的IPC仅约1.5 $\sim$ 2.5。这意味着SMT将处理器的发射槽位利用率从约25%提升到约75%，吞吐量提升了约2 $\sim$ 3倍——代价仅为多套体系结构状态的少量面积开销。这一结果在学术界引起了巨大反响，直接推动了Intel在2002年将SMT（以Hyper-Threading的名义）引入商用处理器。

从概念提出（1995年）到首次商用（2002年）经历了7年，这个时间跨度反映了SMT从理论到工程实现的巨大挑战——虽然SMT的基本思想简单，但在一个真实的超标量处理器中正确、高效地实现多线程的资源共享、线程管理和验证需要大量的工程投入。

图图 45.3对比了三种多线程方式在超标量处理器上的资源利用情况。在这个示意中，我们假设一个4-wide的超标量处理器在8个周期内的执行情况。

超标量单线程、细粒度多线程和同时多线程的资源利用对比。灰色格子表示空闲的发射槽位。SMT通过在同一周期内混合多个线程的指令，最大化了发射槽位的利用率。

SMT建立在超标量乱序处理器的基础之上。一个 $W$ -wide的超标量处理器每周期可以发射 $W$ 条指令，但单一线程由于数据依赖、控制依赖和存储器延迟，平均每周期通常只能发射 $W/2$ 到 $W/3$ 条有效指令——剩余的发射槽位处于空闲状态。SMT通过从多个线程中选取指令来填充这些空闲槽位，实现了接近理想的资源利用率。

性能分析 3 — SMT吞吐量提升的理论上限

设一个 $W$ -wide的超标量处理器中，单一线程的平均发射率为 $\bar{I}_1$ 条指令/周期（ $\bar{I}_1 < W$ ）。 $T$ 个线程在SMT模式下的总发射率上限为： $ $\bar{I}_{\text{SMT}} = \min\!\Bigl(W, \;\sum_{t=1}^{T} \bar{I}_t\Bigr)$ $ 其中 $\bar{I}_t$ 是线程 $t$ 在无竞争时的独立发射率。假设所有线程是同构的且 $\bar{I}_t = \bar{I}_1$ ，则： $ $\text{Throughput Gain} = \frac{\bar{I}_{\text{SMT}}}{\bar{I}_1} = \min\!\Bigl(\frac{W}{\bar{I}_1},\;T\Bigr)$ $ 对于一个6-wide的处理器，若单线程 $\bar{I}_1 = 2.5$ ，2线程SMT的理论吞吐量增益为 $\min(6/2.5, 2) = 2.0$ ，即100%提升。但由于线程间的资源竞争（cache争用、发射端口冲突等），实际增益通常只有30% $\sim$ 50%——远低于理论上限。这个差距正是SMT微架构设计所要最小化的对象。

从微架构的角度看，实现SMT需要满足以下基本条件：

多套体系结构状态：每个硬件线程需要独立的程序计数器（PC）、体系结构寄存器文件（或其映射表）、控制和状态寄存器（CSR）等。这是区分不同线程执行上下文的基本要求。
共享的执行资源：功能单元、发射队列、物理寄存器文件、cache等由所有线程共享。这是SMT面积效率的来源——不需要为每个线程复制整个执行引擎。
线程标识跟踪：流水线中的每条指令必须携带其所属线程的标识（Thread ID），以便在提交、异常处理和刷新时正确地操作对应线程的状态。
资源分配策略：需要某种机制来控制每个线程对共享资源（如ROB、物理寄存器、cache）的占用比例，防止一个线程独占资源而饿死其他线程。

硬件描述 1 — SMT对超标量处理器的增量改动

在一个已有的超标量乱序处理器上添加SMT支持，典型的增量改动包括：

需要复制的结构（每个线程独立一份）：

程序计数器（PC）及下一PC逻辑
体系结构寄存器到物理寄存器的映射表（RAT/RMT）
分支历史寄存器（GHR/PHR）和返回地址栈（RAS）
中断和异常状态寄存器
TLB的PCID/ASID标记逻辑

需要分区或标记的结构：

ROB（按线程分区或标记线程ID）
Store Queue和Load Queue（按线程分区）
物理寄存器文件的空闲列表（按线程独立管理或共享）

完全共享的结构：

功能单元（ALU、MUL、FPU、AGU等）
发射队列（指令从不同线程混合存储）
旁路网络
L1/L2 cache数据阵列

Intel在Pentium 4中首次实现超线程（Hyper-Threading）时报告，SMT支持仅增加了约5%的核心面积。

SMT的面积开销可以更细致地分解如下（以2线程SMT为例）：

组件	开销类型	估算占核心面积
额外的RAT（整数+向量）	完全复制	1.5% $\sim$ 2.5%
额外的PC和PC预测逻辑	完全复制	0.3% $\sim$ 0.5%
额外的GHR和RAS	完全复制	0.2% $\sim$ 0.4%
ROB标记/分区逻辑	新增控制	0.5% $\sim$ 1.0%
PRF扩大（约20% $\sim$ 30%）	容量扩展	2.0% $\sim$ 4.0%
取指仲裁和线程选择	新增控制	0.3% $\sim$ 0.5%
提交逻辑扩展	双指针	0.3% $\sim$ 0.5%
中断/异常状态复制	完全复制	0.2% $\sim$ 0.3%
线程ID位（贯穿流水线）	每级1位	0.5% $\sim$ 1.0%
总计		5.8% $\sim$ 10.7%

从表中可以看出，PRF扩大和RAT复制是SMT面积开销的两大来源，合计约占总开销的60% $\sim$ 70%。

SMT相比细粒度多线程和粗粒度多线程的关键区别在于：

对比FGMT：SMT允许在同一周期内执行多个线程的指令，而FGMT每周期只允许一个线程。SMT的单线程性能更高——当只有一个活跃线程时，SMT处理器退化为普通超标量处理器，该线程可以占用全部发射槽位。FGMT即使只有一个线程，也受限于轮转策略。
对比CGMT：SMT不需要显式的线程切换——所有线程的指令持续地在流水线中混合执行。不存在切换开销（流水线排空/填充）。SMT可以利用即使是很短暂的空闲槽位，而CGMT只能利用长延迟停顿。
代价：SMT需要超标量乱序处理器作为基础，硬件复杂度远高于FGMT。资源共享也引入了线程间干扰——一个线程的cache miss可能逐出另一个线程的热数据，一个线程的分支误预测可能消耗原本属于另一个线程的发射带宽。

从历史演进的角度看，这三种多线程技术并非简单的替代关系，而是反映了不同的设计目标和技术约束的演进：

FGMT（1990年代 $\sim$ 2000年代初）：诞生于处理器还相对简单、ILP开发刚起步的时代。FGMT的主要价值是用简单的硬件（无需乱序执行）获得高吞吐量。Sun Niagara系列是这一思想的巅峰——用极简的有序核心配合大量的硬件线程来服务高度并行的服务器工作负载。
CGMT（2000年代）：作为FGMT和SMT之间的折衷方案出现，主要用于乱序处理器上希望隐藏cache miss延迟但不愿意承担SMT全部复杂度的场景。Intel Montecito Itanium是一个代表性实现。
SMT（1995年提出，2002年首次商用）：需要成熟的超标量乱序处理器作为基础。SMT在2000年代到2020年代初期成为主流高性能处理器的标配。但从2024年开始，客户端处理器中SMT开始退潮，被大小核架构替代。
GPU FGMT（2006年至今）：GPU中FGMT的复兴和极端化。NVIDIA CUDA从G80（2006年）开始采用大规模FGMT，每个SM支持数百到数千个并发线程。GPU证明了在极端吞吐量导向的工作负载中，FGMT仍然是最优的多线程方案——它用寄存器文件面积换取了接近100%的ALU利用率，这种交换在GPU的计算模型中是高度划算的。

设计权衡 1 — 三种多线程方式的比较

特性	FGMT	CGMT	SMT
线程切换粒度	每周期	长延迟事件	无显式切换
同一周期多线程	否	否	是
单线程性能	差（ $1/N$ ）	接近无MT	略有降低
短停顿利用	好	差	好
长停顿利用	好	好	好
硬件复杂度	低	中	高
典型面积开销	$<$ 10%	$<$ 10%	5% $\sim$ 30%
典型吞吐提升	高（多线程）	中	高
处理器基础	有序/简单	有序/乱序	超标量乱序

图图 45.4展示了一个SMT-2处理器中，两个线程如何在完整流水线的各个阶段共享和分区资源。这是理解SMT资源管理的全局视图——从取指到提交，每个阶段的线程管理方式都不同。

SMT设计的核心挑战在于如何管理多个线程对共享资源的竞争。每一种微架构资源都面临三种基本的线程管理策略选择：完全共享、静态分区和动态分区。策略的选择不仅影响多线程吞吐量和单线程性能，还影响线程间的公平性和安全隔离。

三种资源分配策略的形式化分析

为了严格分析不同的资源分配策略，我们建立一个形式化模型。设某种共享资源的总容量为 $C$ ，线程数为 $T$ ，线程 $t$ 对该资源的瞬时需求为 $d_t$ 。

（1）完全共享（Full Sharing）：所有 $T$ 个线程自由竞争全部 $C$ 个资源单元。每个线程可以占用的资源量没有固定限制，仅受总容量约束： $$\label{eq:ch45-full-share} \sum_{t=1}^{T} a_t \leq C, \quad 0 \leq a_t \leq C$$ 其中 $a_t$ 是线程 $t$ 实际分配到的资源量。

完全共享的优势在于最大化利用率——当只有一个活跃线程时，该线程可以使用全部 $C$ 个资源单元。劣势在于无隔离保证——一个行为不良的线程（例如经历大量cache miss导致ROB堆积大量等待指令的线程）可能占用绝大部分资源，导致其他线程饥饿。完全共享的典型应用场景包括发射队列、功能单元和旁路网络。

（2）静态分区（Static Partitioning）：将 $C$ 个资源单元预先划分为 $T$ 份，每个线程固定分配 $C/T$ 个单元： $$\label{eq:ch45-static-part} a_t = C / T, \quad \forall t$$

静态分区提供了最强的隔离保证——每个线程有明确的最低资源配额，不受其他线程行为的影响。但代价是利用率降低——当只有一个活跃线程时，它仍然只能使用 $C/T$ 个资源单元，其余 $(T-1) \times C/T$ 个单元处于空闲状态。静态分区的典型应用包括ROB（在Intel早期HT实现中）和Store Buffer。

（3）动态分区（Dynamic/Hybrid Partitioning）：结合以上两种策略——为每个线程保证一个最低配额 $C_{\min}$ ，剩余的资源 $C - T \times C_{\min}$ 由所有线程动态共享： $$\label{eq:ch45-dynamic-part} C_{\min} \leq a_t \leq C - (T-1) \times C_{\min}, \quad \sum_{t=1}^{T} a_t \leq C$$

动态分区是现代SMT处理器最常用的策略——它兼顾了隔离（最低配额防止饥饿）和灵活性（剩余资源动态分配）。 $C_{\min}$ 的选择是一个关键的设计参数： $C_{\min}$ 过大会导致共享池过小，降低灵活性； $C_{\min}$ 过小则隔离效果不足。实际设计中， $C_{\min}$ 通常设置为 $C/(2T)$ 到 $C/T$ 之间。

设计提示

资源分配策略的选择取决于该资源的以下属性：（1）占用持续时间——如果资源单元的占用时间很短（如发射队列中的指令通常只停留几个周期），完全共享是安全的，因为一个线程难以长期独占；如果占用时间可能很长（如ROB中等待cache miss的指令可能停留数百周期），则需要分区来防止饥饿。（2）对单线程性能的影响——如果资源容量是单线程IPC的关键瓶颈（如ROB深度直接限制指令窗口），分区导致的容量减半会显著降低单线程性能；如果资源在单线程下就已有富余（如功能单元），完全共享不会影响单线程性能。（3）安全需求——如果资源的共享可能导致侧信道泄漏（如cache、TLB），安全敏感场景可能需要强制分区。

各微架构资源的最优分配策略

表表 45.4总结了现代SMT处理器中各关键资源的典型分配策略及其设计理由。

资源	典型策略	理由	单线程影响
PC/GHR/RAS	复制	体系结构状态，必须独立	无
RAT	复制	映射表不可共享	无
ROB	静态/动态分区	占用时间长，需防饥饿	容量减半
发射队列（RS）	完全共享	占用时间短，竞争自调节	无影响
物理寄存器文件	动态分区	占用时间中等	略有减少
Load Queue	静态分区	内存序需线程内有序	容量减半
Store Buffer	静态分区	Store-to-Load转发需隔离	容量减半
功能单元	完全共享	无状态，逐周期分配	端口竞争
L1 I-Cache	完全共享	物理索引结构	容量压力
L1 D-Cache	完全共享	物理索引结构	容量压力
分支预测表	完全共享	分区会减半精度	线程间别名
TLB	共享+PCID标记	PCID区分进程	容量压力

SMT处理器中各资源的分配策略总结

资源分区的量化影响

为了理解资源分区对性能的影响，考虑一个具体的例子。假设一个处理器的ROB有512项，单线程下的IPC为4.0。根据Little定律，飞行中的平均指令数为 $\text{IPC} \times \bar{L}_{\text{pipeline}} \approx 4.0 \times 20 = 80$ 条——远小于512项的ROB容量。这意味着在正常执行中，ROB远未被填满。然而，当出现cache miss链时，ROB中可能积累数百条等待的指令。在2线程SMT下，如果ROB静态分区为每线程256项，单线程在遇到长cache miss链时的指令窗口从512缩小到256——这可能导致处理器无法"越过"cache miss找到足够的独立指令来执行，IPC下降约5% $\sim$ 15%。

性能分析 4 — ROB分区对单线程性能的影响模型

设ROB深度为 $N$ ，单线程使用时有效窗口为 $N$ ，2线程静态分区时每线程有效窗口为 $N/2$ 。假设L2 cache miss的概率为 $p$ （每条指令），每次miss延迟为 $L$ 个周期。在遇到miss时，ROB中平均有 $\text{IPC} \times L$ 条指令在等待。如果 $\text{IPC} \times L > N/2$ （分区后的ROB容量），ROB会满，阻塞新指令的进入——这就是所谓的ROB满停顿（ROB-full stall）。

以Golden Cove为例： $N = 512$ , IPC $\approx 4.5$ , $L \approx 40$ 周期（L2 miss到L3 hit）， $\text{IPC} \times L = 180$ 。单线程ROB 512项时不会满；HT模式下每线程256项，仍然不会满（ $180 < 256$ ）。但如果遇到L3 miss（ $L \approx 200$ 周期）， $\text{IPC} \times L = 900 > 256$ ，ROB会在HT模式下迅速填满，而单线程模式下仍有余量（ $900 > 512$ 也会满，但满的时间更晚，期间可以执行更多独立指令）。

因此，ROB分区对性能的影响主要体现在长延迟事件的处理上——miss延迟越长、miss频率越高，分区的惩罚越大。

资源竞争检测与动态调节

现代SMT处理器实现了多种运行时资源竞争检测和动态调节机制，以在不同的工作负载场景下自适应地调整资源分配。

ROB占用率监控：处理器持续监控每个线程在ROB中的占用率。当某个线程的ROB占用率超过阈值（如75%）时，表明该线程可能正在经历长延迟事件（cache miss链），其大量不可提交的指令正在"堵塞"ROB。此时，取指策略可以降低该线程的取指优先级（减少为其取指的频率），避免进一步加剧ROB拥塞。

发射队列压力感知：当发射队列接近满载时，取指仲裁器收到反压信号（back-pressure signal），可以暂停为所有线程取指，或选择性地只为发射队列中指令较少的线程取指。这种反压机制防止了前端过度取指导致后端拥塞。

Cache miss计数器：某些处理器维护每线程的未完成cache miss计数器（outstanding miss counter）。当一个线程的未完成miss数量超过阈值时，表明该线程正在进行大量的内存密集型操作。调度器可以据此降低其资源配额或优先级，将资源释放给其他更能有效利用资源的线程。

动态线程禁用：在极端情况下（如一个线程因为连续的cache miss而完全停滞），处理器可以暂时禁用该线程（停止为其取指并冻结其流水线状态），将所有资源集中给其他活跃线程。当导致停滞的事件被解决后（如cache miss数据返回），再重新激活该线程。这种机制在IBM POWER系列中有实现——POWER10可以在运行时动态调整活跃线程数量。

硬件描述 2 — Intel Golden Cove的资源竞争检测

Intel Golden Cove微架构中的资源管理包含以下竞争检测机制：

ROB分区与动态上限：ROB的512项在HT模式下静态分区为每线程256项，但每个线程还有一个动态上限寄存器。当一个线程的指令全部处于等待状态（无指令就绪发射）超过一定周期数时，其动态上限被逐步降低到低于256，释放的空间可被另一个线程使用。
RS（发射队列）共享与反压：97项RS完全共享，但当任一线程在RS中的条目超过75%时，取指阶段会减少为该线程的取指带宽。这防止了一个高miss率线程用大量不可发射的指令填满RS。
PRF配额管理：物理寄存器文件动态共享，但通过空闲列表管理确保每个线程至少保有体系结构寄存器数量的物理寄存器（约32个整数+32个向量），剩余寄存器动态分配。当空闲寄存器总数低于阈值时，优先为ROB头部指令最接近提交的线程分配寄存器。

五种资源分区策略的深入分析

前面引入了完全共享、静态分区和动态分区三种基本策略。在工业实践中，资源分区策略实际上有五种变体，每种适用于不同的资源特性和设计目标。本节对每种策略进行深入的定量分析。

策略一：静态等分（Static Equal Partition）

将资源总量 $C$ 严格等分为 $T$ 份，每线程获得 $C/T$ 。以ROB为例，512项ROB在SMT-2下每线程256项，边界不可逾越。

**利用率分析。**设线程 $t$ 在时刻 $k$ 的资源需求为 $d_t(k)$ 。静态分区下的资源浪费率为： $$\label{eq:ch45-static-waste} W_{\text{static}} = 1 - \frac{\sum_{t=1}^{T} \min\bigl(d_t, C/T\bigr)}{C}$$ 当一个线程空闲（ $d_t = 0$ ）而另一个线程需求超过 $C/T$ 时，浪费率可达50%。在SPEC CPU 2017的基准测试对中，静态分区的平均ROB利用率约为62% $\sim$ 75%，而完全共享可达85% $\sim$ 92%。

**公平性分析。**定义公平性为各线程IPC的变异系数（Coefficient of Variation, CoV）的倒数。静态分区的CoV通常在0.05 $\sim$ 0.15之间（近乎完美公平），因为每个线程的资源配额完全不受对方行为影响。

为什么Intel早期（Pentium 4到Skylake）在ROB上选择静态分区？根本原因在于实现简单性。静态分区的ROB只需要将物理地址空间一分为二，每线程维护独立的头尾指针在各自的地址范围内循环。这种实现不需要任何动态仲裁逻辑，控制通路的时序容易满足。对于ROB这样处于提交关键路径上的结构，时序约束极为严格——任何额外的仲裁逻辑都可能增加关键路径延迟，降低时钟频率。

所有线程自由竞争全部 $C$ 个资源单元，无任何配额限制。发射队列（IQ/RS）是完全共享的典型案例——指令按就绪状态竞争发射，不区分线程。

**利用率分析。**完全共享的利用率公式为： $$\label{eq:ch45-full-util} U_{\text{full}} = \frac{\min\bigl(\sum_{t=1}^{T} d_t,;C\bigr)}{C}$$ 当只有一个活跃线程时，该线程可以使用全部 $C$ 项资源，利用率最高。但当一个"恶性"线程（例如经历连续cache miss的线程）占满所有资源时，其他线程完全饥饿——这就是完全共享的致命缺陷。

为什么不在ROB上使用完全共享？考虑以下场景：线程A经历一个L3 miss（延迟200周期），其ROB中的200+条指令全部阻塞等待。在完全共享的ROB中，这200条指令占据了512项中的200项，但由于线程A的头指针无法前进（miss未返回），这200项不会被释放。线程B只剩下312项可用——如果线程B也遇到一个miss，它的阻塞指令进一步占据ROB，最终两个线程都可能因ROB满而停顿。更严重的是，如果线程A的miss是一个长链（miss-after-miss），它可能逐步吞噬整个ROB的大部分容量，将线程B的有效窗口压缩到极小。这就是学术文献中描述的ROB饥饿（ROB starvation）问题。

每线程设置最大占用上限 $C_{\max}$ （如不超过总容量的3/4），但无最低保证。形式化约束为： $$\label{eq:ch45-capped} 0 \leq a_t \leq C_{\max}, \quad C_{\max} < C, \quad \sum_{t=1}^{T} a_t \leq C$$

上限共享防止了单个线程独占全部资源，但不保证每个线程的最低配额——当资源紧张时，低优先级或后到达的线程仍可能获得很少的资源。

**设计选择。**上限 $C_{\max}$ 的典型值为 $\frac{3}{4}C$ 到 $\frac{7}{8}C$ 。选择 $\frac{3}{4}C$ 意味着即使一个线程完全饱和，另一个线程仍可保证至少 $\frac{1}{4}C$ 的资源。Intel在Golden Cove的RS上使用了类似的上限共享策略——97项RS完全共享，但每线程在RS中的条目超过约75%时触发取指反压。

为不同线程分配不同的优先级权重 $w_t$ ，资源分配与权重成正比。高优先级线程在竞争时获得更多资源，低优先级线程在资源充裕时也能获得足够资源。

优先级共享的资源分配规则为： $$\label{eq:ch45-priority} a_t \propto w_t, \quad \text{约束} \sum_t a_t \leq C$$

**应用场景。**优先级共享适用于需要区分线程重要性的场景——例如操作系统前台线程（高优先级）和后台线程（低优先级）在同一核心上SMT执行时，前台线程应获得更多的执行资源以保证响应延迟。IBM POWER10的AIX操作系统支持通过硬件优先级寄存器（Thread Priority Register）设置每线程的优先级，处理器据此调整取指和发射的资源分配权重。

为什么不广泛使用？优先级共享的主要问题是优先级反转和活锁。如果高优先级线程的指令全部处于等待状态（如cache miss），它占用了大量资源却不产出有效工作，低优先级线程因资源不足而无法执行——这反而降低了总吞吐量。解决这一问题需要"有效优先级"的概念——基于线程的当前生产效率（而非静态权重）来动态调整优先级，但这增加了硬件复杂度。

策略五：混合策略（Hybrid Per-Resource Policy）

真实的SMT处理器对不同资源采用不同的策略——这是工业实践中最常见的做法。混合策略的选择基于每种资源的特性：

ROB：静态分区（占用时间长，需防饥饿，且位于提交关键路径上）
IQ/RS：完全共享（占用时间短，就绪即发射，自然调节）
PRF：动态分区（有最低保证配额，剩余共享。回调24.4 节中关于PRF容量设计的讨论）
Load Queue：静态分区（内存序验证需要线程内有序，回调38.1 节中关于ROB与LSQ协作的讨论）
Store Buffer：静态分区（Store-to-Load转发必须线程隔离）
L1 Cache：完全共享（物理索引结构，分区成本过高）
分支预测器：完全共享+部分线程ID哈希（回调27.1 节中关于发射队列唤醒逻辑的讨论）
TLB：共享+PCID标记（软硬件协同隔离）

图图 45.5直观展示了三种主要分区策略在ROB上的差异。

三种SMT资源分区策略在ROB上的可视化对比。静态分区保证公平但浪费空间；完全共享最大化利用率但可能导致饥饿；混合分区在保证最低配额的同时允许灵活共享。

::: warning 性能分析 5 — SMT-2吞吐量建模——资源竞争因子法

给定单线程IPC和各维度的资源竞争因子，可以估算SMT-2的总吞吐量。

**第一步：确定单线程基准IPC。**设线程A和线程B在独占模式下的IPC分别为 $I_A = 4.0$ 和 $I_B = 3.5$ （在一个6-wide处理器上）。

**第二步：量化各维度的竞争因子。**定义竞争因子 $\alpha_i \in [0, 1]$ ，表示资源 $i$ 的竞争导致的IPC降低比例：

$\alpha_{\text{cache}} = 0.06$ （L1 D-Cache容量竞争导致6%的IPC损失）
$\alpha_{\text{ROB}} = 0.04$ （ROB分区减小窗口导致4%的IPC损失）
$\alpha_{\text{port}} = 0.03$ （执行端口竞争导致3%的IPC损失）
$\alpha_{\text{fetch}} = 0.02$ （取指带宽减半导致2%的IPC损失）
$\alpha_{\text{BP}} = 0.01$ （分支预测器别名导致1%的IPC损失）

**第三步：计算SMT模式下的每线程IPC。**总竞争因子为 $\alpha = \sum_i \alpha_i = 0.16$ 。每线程的SMT IPC为： $ $I_A^{\text{smt}} = I_A \times (1 - \alpha) = 4.0 \times 0.84 = 3.36$ $ $ $I_B^{\text{smt}} = I_B \times (1 - \alpha) = 3.5 \times 0.84 = 2.94$ $

第四步：计算总吞吐量和加速比。 $ $I_{\text{total}} = I_A^{\text{smt}} + I_B^{\text{smt}} = 3.36 + 2.94 = 6.30$ $ 吞吐量加速比 $= 6.30 / \max(4.0, 3.5) = 6.30 / 4.0 = 1.575$ ，即57.5%的吞吐量提升。

第五步：验证约束。总IPC=6.30不超过处理器宽度 $W=6$ ？实际上 $6.30 > 6$ ，说明在峰值周期中发射宽度已成为瓶颈。修正后的总IPC应为 $\min(6.30, 6.0) = 6.0$ ，加速比 $= 6.0/4.0 = 1.50$ ，即50%的实际吞吐量提升。

这个五步模型揭示了SMT吞吐量的两个限制因素：（1）资源竞争导致的每线程IPC下降；（2）处理器发射宽度 $W$ 的上限。在宽发射处理器中，后者通常不是瓶颈——例如12-wide的Golden Cove中，两线程的IPC之和很少达到12。

:::

Intel Hyper-Threading逐结构深度分析

Intel从Golden Cove（Alder Lake P-core，2021年）到Lion Cove（Arrow Lake P-core，2024年——Arrow Lake取消了HT，但Lion Cove的微架构可以追溯到HT设计阶段的考量）的HT实现中，每个微架构结构的分区策略都经过了精心选择。以下逐一分析Golden Cove中每个关键结构的SMT处理方式。

ROB：静态分区（各256项）

Golden Cove的ROB共512项，在HT模式下严格静态分区为每线程256项。

**为什么不动态共享ROB？**这是一个看似"浪费"的选择——当只有一个线程活跃时，一半ROB空间闲置。Intel坚持静态分区的工程原因有三：

提交逻辑时序：ROB的提交（retire）操作位于处理器的关键路径上。静态分区下，每线程的提交指针在固定的地址范围内循环，指针比较和更新逻辑极为简单——仅需一个模 $N/2$ 的计数器。动态共享的ROB需要在混合排列的指令中找到每线程的"最老"指令来提交，这需要额外的标签比较和扫描逻辑，可能在关键路径上增加1 $\sim$ 2个逻辑层级。
防止ROB饥饿：如前文分析，一个经历长延迟miss的线程可能在完全共享的ROB中占据大部分条目，导致另一个线程饥饿。静态分区从根本上消除了这种风险。
刷新（flush）隔离：当一个线程的分支预测失败需要刷新流水线时，只需要清空该线程的ROB分区（标记其所有条目为无效）。如果ROB是动态共享的，刷新操作需要在混合排列的条目中逐一检查线程ID并选择性清除——这在512项的ROB上需要更多的时钟周期。

uop Cache（DSB）：共享但线程ID标记

Golden Cove的uop Cache（约4K uops容量）被两个线程完全共享。每个uop Cache行不携带线程ID——来自线程A的decoded uops和线程B的decoded uops混合存储在同一个uop Cache中，按代码地址索引。

这种共享设计的理由是：两个线程可能执行相同的共享库代码（如libc），共享uop Cache避免了代码的冗余存储。但代价是线程间可能发生uop Cache争用——一个线程的大循环可能将另一个线程的uop Cache行逐出，导致后者频繁回退到慢速的前端解码路径。

L1 I-Cache和L1 D-Cache：完全共享

L1 I-Cache（64KB，8路组相联）和L1 D-Cache（48KB，12路组相联）被两个线程完全共享，无任何路级或组级分区。

为什么不对L1 Cache进行路级分区？主要原因是容量。Golden Cove的L1 D-Cache只有48KB——在SMT-2下如果路级分区为每线程24KB（6路），有效容量与10年前的单线程处理器相当，Cache miss率将急剧上升。Intel选择依靠LRU替换策略在两个线程之间自然平衡Cache占用，而非通过分区人为限制。不过，Intel在安全缓解中提供了可选的L1D分区模式——当操作系统检测到安全敏感场景时，可以激活L1D路级分区来防止Cache侧信道，代价是性能下降约5% $\sim$ 10%。

L2 Cache：完全共享

Golden Cove的私有L2 Cache（1.25MB，20路组相联）被两个SMT线程完全共享。L2的大容量使得线程间的容量竞争相对缓和。L2预取器也被共享——两个线程的L2 miss流混合进入预取器的模式检测逻辑。如前文所述，这可能混淆预取器的stride检测，但Golden Cove的预取器设计据信包含了per-thread的stride跟踪状态来缓解这一问题。

TLB：共享，PCID隔离

L1 DTLB（64项全相联）和L2 STLB（2048项，16路组相联）被两个线程共享，但通过PCID（Process Context Identifier，12位）标记实现逻辑隔离。两个线程的TLB表项可以同时存在于TLB中——查找时VPN和PCID同时匹配。

分支预测器：共享BTB和PHT，部分线程ID哈希

Golden Cove的分支预测器结构——BTB、TAGE预测表、间接跳转预测器——被两个线程共享。但Intel在Golden Cove中引入了一项重要优化：TAGE表索引中混入线程ID位。具体来说，TAGE的某些表级别（如T1、T2）在计算索引时将线程ID与PC的一位异或，使得两个线程的同地址分支映射到不同的表行。这减少了线程间的直接别名冲突，同时每个线程仍可使用接近全部的表容量（因为异或只改变索引的一位，表的有效容量仅减少约50%的直接冲突概率，而非减半容量）。

然而，BTB仍然完全共享——BTB的条目按目标地址索引，不区分线程。这是因为BTB主要存储分支目标地址，两个线程的分支目标互不干扰（不同的PC映射到不同的BTB行），直接冲突的概率已经很低。

每个线程维护独立的全局历史寄存器（GHR/PHR）和返回地址栈（RAS），这是保证预测精度的必要条件——混合不同线程的分支历史会严重破坏TAGE的关联预测能力。

发射队列（RS）：完全动态共享

Golden Cove的分布式发射队列（多个scheduler，总计约160+项）被两个线程完全共享。线程A和线程B的待发射指令混合存储在同一组调度器中，按就绪状态竞争发射端口。

发射队列的完全共享在SMT中工作良好，原因在于指令在发射队列中的停留时间短——就绪的指令通常在1 $\sim$ 3个周期内即被发射，队列的周转率极高。一个线程的cache miss不会导致大量指令在发射队列中积压（miss的load指令只在发射队列中占一项，其依赖链上的后续指令尚未进入发射队列），因此不会像ROB那样出现饥饿问题。

物理寄存器文件（PRF）：动态共享+最低保证

Golden Cove的整数PRF约280项，向量PRF约280项，被两个线程动态共享。空闲列表由两个线程共同使用，但硬件保证每个线程至少持有 $R_{\text{arch}}$ 个物理寄存器（约32个整数+32个向量=64个），确保线程不会因寄存器耗尽而无法重命名任何新指令。剩余的寄存器（约 $280 - 2 \times 32 = 216$ 个整数PRF）由两个线程动态竞争。回调第 24.0 章中关于PRF设计的讨论——PRF容量是SMT面积开销的最大单项来源。

SMT对分支预测器的干扰量化

分支预测器的线程共享是SMT中最微妙的设计权衡之一。共享预测器的干扰来自两个独立的机制：BTB容量竞争和PHT/TAGE别名污染。本节定量分析这两种干扰的MPKI（Misses Per Kilo Instructions）影响。

BTB容量竞争

BTB（Branch Target Buffer）存储分支指令的目标地址。在SMT-2下，两个线程的分支指令争用同一个BTB。设BTB总容量为 $B$ 项，每个线程的分支活跃集（active branch working set）为 $W_A$ 和 $W_B$ 项。

当 $W_A + W_B > B$ 时，BTB容量不足以同时容纳两个线程的全部活跃分支，发生容量冲突。BTB miss导致处理器无法获取分支的目标地址，需要从I-Cache中重新取指并解码分支指令——延迟约4 $\sim$ 6个周期。

以Golden Cove为例：BTB约12K项，典型SPEC CPU INT程序的分支活跃集约3K $\sim$ 6K项。在单线程下，6K项的活跃集完全命中12K项的BTB（miss率 $<$ 0.1%）。在SMT-2下，两个6K项的程序共12K项的活跃集恰好填满BTB——BTB miss率上升到约0.5% $\sim$ 2%。

**MPKI增加量估算。**假设分支指令占总指令的约15%。BTB miss率从0.1%上升到1.5%，增加1.4个百分点。对应的分支MPKI增加量为 $0.014 \times 150 = 2.1$ （每千条指令增加2.1次BTB miss）。在20级流水线中，每次BTB miss导致约5个周期的气泡，MPKI增加2.1转化为IPC损失约 $2.1 \times 5 / 1000 \times \text{IPC} \approx 0.04$ （约1%的IPC）。

TAGE别名污染

TAGE预测器使用多级历史索引表来预测分支方向。在共享TAGE中，两个线程的分支可能哈希到同一个表项，导致破坏性别名（destructive aliasing）——线程A的分支训练了某个表项为"taken"，线程B的一个不相关分支恰好映射到同一表项，读取了错误的预测值。

为什么TAGE的别名污染比简单的PHT严重？TAGE使用长历史路径作为索引的一部分，理论上不同线程的分支映射到同一项的概率应该很低。但问题在于GHR（全局历史寄存器）的线程隔离。在共享TAGE中，虽然每个线程维护独立的GHR，但TAGE表本身是共享的。线程A在其GHR上下文下训练的表项，可能被线程B在不同GHR上下文下访问到（如果PC和部分历史位恰好碰撞）。

学术研究（Hily和Seznec，1996年）测量了共享TAGE在SPEC CPU工作负载对中的别名影响：方向预测的MPKI增加约0.3 $\sim$ 1.5，取决于工作负载组合。对于分支密集型代码（如解释器、JIT编译代码），MPKI增加可达2.0 $\sim$ 3.0，转化为3% $\sim$ 6%的IPC损失。

解决方案：线程ID编入哈希索引

最有效的缓解方案是将线程ID编入TAGE表的索引计算中。具体实现方式有两种：

**方案一：线程ID异或到索引低位。**将1位的线程ID与TAGE表索引的最低位异或。这使得两个线程的同一PC分支映射到不同的表行（相邻行），消除了直接的PC别名冲突。代价是每个线程可用的有效表行数减半（因为索引空间被线程ID分割），但TAGE的高关联度设计在这种容量减半下仍能维持较好的预测精度。

**方案二：线程ID异或到标签（tag）中。**将线程ID编入TAGE表项的标签匹配逻辑中。这在物理上不分区表（两个线程仍可映射到同一行），但在标签比较阶段区分了不同线程的训练数据——线程B不会命中线程A训练的表项（因为标签不匹配）。这种方案保留了表的全部容量（无容量减半），但增加了标签匹配的比较位数（1位额外比较）。Intel据信在Golden Cove中对TAGE的部分级别采用了方案二。

ROB静态分区的硬件实现

为了具体说明ROB静态分区在SMT中的硬件实现，以下提供一个简化的SystemVerilog模型。该代码展示了2线程SMT下ROB的分配和释放指针管理逻辑。

module rob_smt2_partition #(
  parameter ROB_DEPTH  = 512,
  parameter HALF       = ROB_DEPTH / 2,  // 256
  parameter PTR_W      = $clog2(HALF)     // 8
)(
  input  logic        clk, rst_n,
  // 分配接口 (来自重命名级)
  input  logic        alloc_req_t0, alloc_req_t1,
  output logic        alloc_ok_t0,  alloc_ok_t1,
  output logic [PTR_W:0] alloc_idx_t0, alloc_idx_t1,
  // 提交接口 (来自提交级)
  input  logic        retire_req_t0, retire_req_t1,
  // 状态输出
  output logic [PTR_W:0] used_t0, used_t1
);

  // 每线程独立的头/尾指针 (在各自HALF空间内循环)
  logic [PTR_W:0] head_t0, tail_t0;  // head=提交指针, tail=分配指针
  logic [PTR_W:0] head_t1, tail_t1;

  // 每线程已用条目数
  assign used_t0 = tail_t0 - head_t0;
  assign used_t1 = tail_t1 - head_t1;

  // 分配允许: 只要本线程分区未满即可
  assign alloc_ok_t0 = (used_t0 < HALF);
  assign alloc_ok_t1 = (used_t1 < HALF);

  // 分配索引: 线程0使用 [0, HALF-1], 线程1使用 [HALF, ROB_DEPTH-1]
  assign alloc_idx_t0 = tail_t0[PTR_W-1:0];           // 偏移0
  assign alloc_idx_t1 = tail_t1[PTR_W-1:0] + HALF;    // 偏移HALF

  // 指针更新逻辑
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      head_t0 <= '0; tail_t0 <= '0;
      head_t1 <= '0; tail_t1 <= '0;
    end else begin
      // 线程0分配
      if (alloc_req_t0 && alloc_ok_t0)
        tail_t0 <= tail_t0 + 1;
      // 线程0提交
      if (retire_req_t0 && used_t0 > 0)
        head_t0 <= head_t0 + 1;
      // 线程1分配
      if (alloc_req_t1 && alloc_ok_t1)
        tail_t1 <= tail_t1 + 1;
      // 线程1提交
      if (retire_req_t1 && used_t1 > 0)
        head_t1 <= head_t1 + 1;
    end
  end

endmodule

设计提示

上述代码的关键设计特征是两套完全独立的指针——线程0和线程1的头尾指针互不影响。每个线程的分配和提交操作只涉及自己的指针，不需要任何跨线程的仲裁或同步。这正是静态分区在工程上的核心优势——控制逻辑极为简洁，时序容易满足。相比之下，动态共享的ROB需要在分配时仲裁"将条目分配给哪个线程"，在提交时需要从混合排列的条目中找到每线程的最老指令——这些都增加了控制路径的复杂度。回调第 38.0 章中关于ROB组织结构的详细讨论——SMT的ROB分区设计必须与ROB的基本提交和刷新逻辑协同。

SMT的微架构设计

将SMT集成到超标量乱序处理器中涉及流水线每一级的设计改动。本节按前端和后端分别讨论各个关键微架构组件在SMT下的设计考量。

前端资源的线程管理

处理器前端——取指、解码和重命名阶段——是SMT设计中需要最仔细考虑的部分之一。前端的吞吐量直接决定了每个线程能够获得多少执行带宽。

图图 45.6展示了一个典型的2线程SMT处理器的流水线结构，标注了各个资源的线程管理方式。

2线程SMT处理器的流水线资源分配。蓝色/红色小块表示按线程复制或分区的资源，大块表示所有线程共享的资源。取指仲裁器决定每周期为哪个线程取指。

取指阶段

取指阶段是SMT前端的第一个关键决策点：每个周期从哪个（或哪些）线程取指？这个决策称为取指策略（Fetch Policy），它对SMT的性能和公平性有着深远的影响。

每个硬件线程需要独立的程序计数器（PC）。在一个 $T$ 线程的SMT处理器中，取指逻辑维护 $T$ 个独立的PC值。每个周期，取指逻辑需要从这 $T$ 个PC中选择一个或多个来进行取指。最常见的取指策略包括：

轮转取指（Round-Robin Fetch）：最简单的策略，周期性地在线程之间轮转取指优先级。线程0、线程1、线程0、线程1……这种策略实现简单但不考虑各线程的实际需求。
ICOUNT取指：由Tullsen等人提出的经典策略。优先从流水线中指令数量最少的线程取指。直觉是：流水线中指令少的线程可能正在经历取指带宽不足或I-cache miss，应该给予更多取指机会；而指令数量多的线程可能已经有充足的指令供后端消费。ICOUNT策略已被证明在多种工作负载下能够提供近似最优的吞吐量。
按需取指（Demand-Driven Fetch）：根据各线程在后端的资源消耗情况动态调整取指优先级。如果某个线程在ROB中占用了大量表项却进展缓慢（如等待L2 miss），则降低其取指优先级。
分支置信度过滤（Branch Confidence Filtering）：Fetch Gating的一种变体。如果某个线程频繁分支误预测，则暂时停止为该线程取指，避免其误预测路径的指令占用后端资源。这种策略基于一个观察：频繁误预测的线程其推测执行的指令大量是"无用功"——它们占用了ROB、RS和PRF但最终会被冲洗。暂停为这样的线程取指可以释放资源给预测精度更高的线程。
加权公平取指（Weighted Fair Fetch）：为每个线程分配一个动态权重，取指频率与权重成正比。权重可以基于线程的优先级（操作系统设定）或线程的资源使用效率（硬件测量）。权重较高的线程获得更多的取指机会。

I-cache的取指端口通常是所有线程共享的。在一个单端口I-cache的2线程SMT处理器中，每个周期只能为一个线程取指。如果两个线程的取指请求在同一周期到达，需要仲裁——这是取指策略需要解决的核心问题。某些设计通过双端口I-cache（或逻辑上的双Bank I-cache）来缓解这一瓶颈，允许在同一周期内为两个线程同时取指。但双端口I-cache的面积和功耗开销较大，大多数商用处理器仍然使用单端口I-cache配合取指仲裁。

取指阶段的另一个SMT相关问题是取指块对齐。每个线程的PC通常指向不同的地址，可能位于不同的cache line中。在单端口I-cache中，一次取指操作返回一个对齐的取指块（如32字节或64字节），其中可能包含目标线程的数条连续指令。如果两个线程在同一周期需要取指，且它们的PC恰好落在同一个cache line中（概率较低但并非不可能），单端口I-cache可以在一次访问中同时服务两个线程——虽然这需要额外的路由逻辑将取指块中的不同部分分发给不同线程。

取指带宽的量化分析

取指带宽的线程间分配是SMT前端性能的关键瓶颈。在一个2线程SMT处理器中，如果取指器每周期只能为一个线程取指（单端口I-cache），则在两个线程都活跃的情况下，每个线程的平均取指带宽降为单线程的50%。对于一个6-wide处理器，如果单线程取指带宽为6条指令/周期，SMT模式下每线程平均只有3条指令/周期——这可能成为解码和后端吞吐量的瓶颈。

为了缓解这一问题，现代SMT处理器采用了以下技术：

指令队列缓冲（Instruction Queue, IQ）：在取指器和解码器之间为每个线程设置独立的指令队列（通常8 $\sim$ 16条指令的容量）。当一个线程获得取指机会时，取指器可以一次性取出较多的指令并缓冲在队列中。这样即使在另一个线程取指的周期里，解码器仍可以从队列中获取指令继续解码。
uop Cache（DSB）：Intel处理器的uop Cache可以直接提供已解码的uops，绕过取指和解码阶段。在SMT模式下，如果两个线程的代码都命中uop Cache，取指带宽的竞争被大幅缓解——uop Cache通常有足够的带宽在同一周期内为两个线程提供uops（通过时分复用或多Bank设计）。
交替取指周期：在Golden Cove中，取指器在两个线程之间以近似轮转的方式交替取指，但会根据后端的反压信号动态调整——如果某个线程的指令队列已满，则跳过该线程，将取指机会让给另一个线程。

分支预测器

分支预测器的线程管理是一个有趣的设计决策。分支预测器的核心状态——方向预测表（如TAGE的T0 $\sim$ T4表）、分支目标缓冲区（BTB）——可以按两种方式处理：

完全共享：所有线程共享同一组预测表。不同线程的分支可能别名到同一个预测表项，造成线程间干扰（constructive或destructive aliasing）。好处是预测表的有效容量最大，且对于单线程执行没有容量损失。
静态分区：将预测表在物理上或逻辑上分为 $T$ 份，每个线程独占自己的分区。消除了线程间别名，但每个线程只能使用 $1/T$ 的预测容量。对于预测器容量已经紧张的处理器，这种容量减半可能导致显著的预测精度下降。

在实际设计中，大多数SMT处理器选择共享分支预测表——线程间别名的影响通常被认为小于容量减半的影响。学术研究表明，在典型的SPEC CPU工作负载对中，共享预测表导致的线程间别名仅增加约0.5% $\sim$ 1.5%的误预测率，而分区导致的容量减半可能增加2% $\sim$ 4%的误预测率。因此共享是更优的选择。

某些现代处理器采用了部分分区的折衷方案——将预测表的索引中混入线程ID的一位或两位。例如，将TAGE表的索引的最低位设为线程ID，使得两个线程的分支映射到不同的表行（set），消除了直接别名冲突，同时每个线程仍然可以使用表容量的约一半。这种方案在保持合理容量的同时显著减少了线程间的别名干扰。Intel据信在Golden Cove及后续微架构中对TAGE预测器的部分级别采用了类似的线程ID编入索引的技术。

然而，某些与线程紧密相关的状态必须独立维护：

全局历史寄存器（GHR/PHR）：每个线程的分支历史是独立的，必须为每个线程维护独立的GHR。这是因为分支预测的精度高度依赖于历史上下文，混合不同线程的历史会严重破坏预测能力。
返回地址栈（RAS）：每个线程的函数调用链是独立的，RAS必须按线程独立维护。一个线程的call指令不应影响另一个线程的RAS栈顶。

解码阶段

解码器通常被所有线程完全共享。从解码器的角度看，来自不同线程的指令只是普通的指令流——解码逻辑不需要区分指令属于哪个线程。指令在进入解码器之前已经被标记了线程ID，该标记随指令流经后续所有流水线级。

在变长指令集（如x86）中，解码器本身是一个有状态的结构——解码器需要追踪指令边界，处理指令前缀，处理REX/VEX/EVEX编码。在SMT模式下，如果两个线程的指令在同一周期进入解码器，解码器需要并行处理两个独立的指令流。某些设计通过在解码之前为每个线程维护独立的预解码缓冲区来简化这一问题——预解码缓冲区完成指令边界标记和长度解码后，后续的完整解码器可以交替处理来自不同线程的指令。

对于x86处理器的复杂解码器，解码资源（尤其是MSROM——微码ROM）的共享可能引入线程间竞争。当一个线程执行复杂的微码指令（如字符串操作REP MOVSB）时，MSROM被该线程独占，另一个线程的解码将被阻塞。在Intel处理器中，uop Cache（Decoded Stream Buffer，DSB）也被SMT线程共享。uop Cache中的表项不区分线程——两个线程的decoded uops混合存储在同一个uop Cache中。这可能导致线程间的uop Cache争用：一个线程的大循环可能占据uop Cache的大部分容量，导致另一个线程的代码频繁从前端解码器重新解码，增加解码延迟和功耗。

重命名阶段

寄存器重命名是SMT前端中最关键的线程管理环节。每个线程有独立的体系结构寄存器集合，因此每个线程需要独立的寄存器别名表（RAT/RMT）——从体系结构寄存器到物理寄存器的映射表。在2线程SMT中，需要两份完整的RAT。

然而，物理寄存器文件（PRF）本身是所有线程共享的。两个线程的指令可以被重命名到同一个PRF中的不同物理寄存器。重命名逻辑需要确保两个线程分配到的物理寄存器互不冲突。物理寄存器的空闲列表（Free List）可以按线程分区维护（每个线程有固定配额），也可以由所有线程共享（动态竞争）。

设计提示

PRF空闲列表的管理策略直接影响SMT的单线程性能和多线程公平性。共享空闲列表允许单一活跃线程使用全部物理寄存器，提供最佳单线程性能；但在多线程执行时，一个包含大量长延迟指令（如cache miss链）的线程可能分配了大量物理寄存器而不释放，导致另一个线程因寄存器耗尽而停顿。分区空闲列表保证了每个线程的最低配额，但单线程时只能使用 $1/T$ 的物理寄存器，限制了指令窗口大小。混合策略——每个线程保证一个最小配额，剩余寄存器共享竞争——在实践中通常是最佳选择。

后端资源的线程管理

处理器后端——发射队列、功能单元、重排序缓冲区和存储器序——是SMT资源共享最密集的区域。后端资源的管理策略直接决定了SMT的吞吐量和线程间公平性。

重排序缓冲区（ROB）

ROB是SMT后端管理中最关键的结构之一。ROB需要为每个线程维护独立的提交顺序——线程A的指令只能按照线程A的程序顺序提交，与线程B的提交完全独立。这意味着ROB的组织方式必须支持每个线程独立的头指针（commit pointer）。

ROB的线程管理有两种主要策略：

静态分区（Static Partitioning）：将ROB在物理上分为 $T$ 个等大的区域，每个线程独占自己的区域。线程A的指令只能写入区域A，线程B的指令只能写入区域B。每个区域有独立的头尾指针。
优点：实现简单，天然防止一个线程独占ROB。缺点：当只有一个活跃线程时，该线程只能使用ROB的 $1/T$ 容量，指令窗口大小减半。
动态共享（Dynamic Sharing）：所有线程共享同一个ROB，指令按到达顺序写入ROB表项，但每个表项携带线程ID标记。每个线程维护独立的逻辑头指针，提交时只提交属于自己的指令。
优点：当某个线程空闲时，另一个线程可以使用更多ROB表项。缺点：需要更复杂的头指针管理逻辑；一个停顿线程的指令可能占满ROB，阻塞其他线程新指令的分配。

在实际实现中，Intel Hyper-Threading在不同代际的处理器上采用了不同的策略。早期的Pentium 4使用静态分区（每个线程获得ROB一半的容量），而后续的处理器（如Skylake、Golden Cove）采用了更灵活的动态共享策略，但设置了每个线程的最大占用上限。

第三种策略是混合分区（Hybrid Partitioning）：将ROB的一部分（如前1/4和后1/4）静态分配给各线程，中间部分（1/2）动态共享。这种方案兼顾了公平性（每个线程有最低保证配额）和灵活性（空闲容量可以被任何线程使用）。混合分区的硬件复杂度介于静态分区和动态共享之间。

混合分区的实现需要更灵活的ROB指针管理。在纯静态分区中，每个线程有固定的ROB地址范围，头尾指针在该范围内循环——实现非常简单。在混合分区中，每个线程有一个"保证区域"和一个"共享区域"，分配逻辑需要在保证区域未满时使用保证区域，保证区域满后才溢出到共享区域。回收时需要区分条目属于保证区域还是共享区域。尽管增加了一些控制逻辑，混合分区在面积上的额外开销不超过ROB总面积的3% $\sim$ 5%。

硬件描述 3 — ROB分区策略对性能的实测影响

学术研究（Tullsen和Brown，2001年）通过模拟对比了不同ROB分区策略在8个SPEC CPU2000工作负载对上的性能影响：

静态分区：总IPC为基准的1.00 $\times$ （归一化），公平性系数0.92（接近完美公平）
完全共享：总IPC为1.08 $\times$ （+8%吞吐量），但公平性系数降至0.71（显著不公平）
混合分区（保证25%，共享50%）：总IPC为1.05 $\times$ （+5%），公平性系数0.88
动态共享+上限（每线程最多75%）：总IPC为1.06 $\times$ ，公平性系数0.85

这些结果表明，混合分区在吞吐量和公平性之间提供了最好的平衡。Intel在Skylake及后续微架构中采用的策略接近于"静态分区+动态调整上限"——在保证基本公平性的同时，通过动态调整每线程的有效ROB容量来优化吞吐量。

ROB在SMT中的另一个关键问题是提交带宽的分配。在单线程模式下，所有提交带宽（如每周期4条指令提交）都属于一个线程。在SMT模式下，两个线程需要共享提交带宽。常见的策略是交替提交——奇数周期提交线程A的指令，偶数周期提交线程B的指令。这种方式简化了提交逻辑，因为每个周期只需要操作一个线程的头指针。更激进的设计允许在同一周期内同时提交两个线程的指令，但这需要双端口的体系结构寄存器文件更新逻辑和更复杂的异常处理。

发射队列（IQ/RS）

发射队列在SMT中通常采用完全共享的策略——来自不同线程的指令在同一个发射队列中混合存储和竞争发射。这是因为发射队列的选择逻辑本身就是基于指令就绪状态的，不需要关心指令属于哪个线程。线程A的一条就绪指令和线程B的一条就绪指令以相同的方式竞争发射端口。

完全共享的发射队列天然实现了一种有效的动态资源分配：当某个线程的指令大量就绪时（该线程处于计算密集阶段），它自然获得更多的发射槽位；当另一个线程等待cache miss时，它在发射队列中的指令都处于等待状态，不与就绪指令竞争。

然而，发射队列的共享也存在风险。一个包含大量cache miss链的线程可能在发射队列中积累了大量等待的指令，占满了发射队列的容量，导致另一个线程的新指令无法进入发射队列。为此，某些处理器对每个线程在发射队列中的占用比例设置了上限。

物理寄存器文件（PRF）

物理寄存器文件被所有线程共享。从PRF的角度看，不同线程的物理寄存器之间没有任何区别——它们只是PRF中的不同表项。线程A的指令可能被重命名到物理寄存器P17，线程B的指令可能被重命名到P18，两者在PRF中相邻但互不影响。

PRF共享的关键挑战在于容量压力。在单线程模式下，所有物理寄存器都可供一个线程使用；在2线程SMT模式下，两个线程竞争同一个PRF，每个线程平均只能使用PRF容量的一半。为了在SMT模式下保持合理的指令窗口大小，处理器通常需要配置比单线程所需更大的PRF。

性能分析 6 — SMT模式下的PRF需求

设处理器的体系结构寄存器数为 $R_{\text{arch}}$ （如x86-64的16个通用寄存器+16个XMM寄存器），ROB深度为 $N_{\text{ROB}}$ ，线程数为 $T$ 。PRF的最小容量需要满足： $ $N_{\text{PRF}} \geq T \times R_{\text{arch}} + N_{\text{ROB,per\_thread}}$ $ 其中 $N_{\text{ROB,per\_thread}}$ 是每个线程分配到的ROB容量（决定了飞行中指令的最大数量）。在Intel Golden Cove中，2线程SMT模式下ROB有512项，每个线程最多使用约256项。加上每个线程32个体系结构寄存器（包括重命名用途），PRF需要约 $2 \times 32 + 512 \approx 576$ 个物理寄存器——这解释了为什么现代处理器的整数PRF通常有280 $\sim$ 300+个表项。

功能单元

功能单元（ALU、MUL、FPU、AGU等）在SMT中是完全共享的。功能单元是"无状态"的硬件资源——每条指令使用一个功能单元执行一次操作，操作完成后功能单元立即可用于下一条指令（无论该指令来自哪个线程）。因此，功能单元不需要任何线程管理逻辑。

功能单元的共享是SMT面积效率的核心来源。在一个不支持SMT的处理器中，功能单元在流水线气泡期间完全空闲。SMT允许其他线程的指令在这些空闲周期中使用功能单元，实现了"填充气泡"（filling bubbles）的效果。

功能单元共享的一个微妙效应是执行端口竞争对单线程性能的影响。在单线程模式下，一条指令如果有多个可选端口（如加法指令可以在端口0或端口1上执行），调度器可以选择当前最空闲的端口。在SMT模式下，所有端口的利用率都更高，指令被分配到次优端口的概率增加，某些指令可能因为首选端口被另一个线程的指令占用而多等待1 $\sim$ 2个周期。这种效应在单线程性能回退中贡献了约2% $\sim$ 5%的IPC损失。

端口竞争的量化模型

端口竞争对性能的影响可以通过以下模型估算。设处理器有 $P$ 个执行端口，单线程模式下每周期的平均端口利用率为 $\bar{u}$ （每端口），则在2线程SMT模式下，假设两个线程的端口需求相似，每端口的利用率增加为约 $\bar{u} + \Delta u$ ，其中 $\Delta u$ 取决于另一个线程的指令混合。

在Intel Golden Cove中，12个执行端口在单线程SPEC CPU INT负载下的平均利用率约为30% $\sim$ 40%。在HT模式下，利用率增加到约50% $\sim$ 60%。端口竞争导致的额外等待周期可以通过以下经验公式估算：

\Delta t_{\text{contention}} \approx \frac{\bar{u}_{\text{other}}}{1 - \bar{u}_{\text{self}} - \bar{u}_{\text{other}}} \times t_{\text{dispatch}}

其中 $\bar{u}_{\text{other}}$ 是另一个线程对同一端口的利用率， $t_{\text{dispatch}}$ 是端口的分派延迟（通常1个周期）。在利用率为60%时，竞争增加的平均延迟约为 $0.3/(1-0.6) \approx 0.75$ 个周期——对于一条平均延迟3 $\sim$ 4个周期的指令，这约占20%的额外延迟。

但实际的影响比这个简单模型预测的要小，原因有两个：（1）大多数指令有多个可选端口，调度器可以避开繁忙的端口；（2）端口竞争通常发生在特定类型的端口上（如端口5的向量移位单元），而非所有端口。

发射选择逻辑的SMT扩展

发射选择逻辑（Issue Select Logic）是SMT后端中硬件复杂度增加最显著的部分之一。在单线程模式下，发射选择器需要从发射队列中选择最多 $W$ 条就绪指令发射到 $P$ 个端口。在SMT模式下，虽然发射逻辑本身不需要区分线程（就绪指令无论来自哪个线程都同等竞争），但以下两个因素增加了复杂度：

公平性约束：可能需要添加每线程的发射计数器，确保一个线程不会在连续多个周期中完全独占所有发射端口。在实际设计中，如果一个线程有大量就绪指令而另一个线程的指令都在等待，公平性约束可以选择不施加——让有工作可做的线程充分利用端口。公平性约束主要在两个线程都有充足就绪指令时才介入。
唤醒逻辑的扩展：当一条指令完成执行时，它需要唤醒（wake up）发射队列中依赖它的所有指令。在SMT模式下，发射队列中混合了两个线程的指令，唤醒逻辑需要正确地处理跨线程的独立性——线程A完成的指令不应该唤醒线程B中等待同一物理寄存器的指令（除非它们真的有数据依赖，但在不同线程中不可能存在RAW依赖）。唤醒逻辑通常通过物理寄存器编号匹配来工作，而非线程ID匹配，因此天然不会产生跨线程的错误唤醒。

Store Buffer和Load Queue

存储器访问的有序性对于程序正确性至关重要。在SMT中，Store Buffer和Load Queue的管理需要特别小心：

Store Buffer通常按线程分区。每个线程维护独立的Store Buffer区域，因为Store-to-Load Forwarding只应在同一线程的store和load之间发生——不同线程的store不应被转发到另一个线程的load（在Total Store Order等强内存模型下）。
Load Queue通常也按线程分区或标记线程ID，因为Load-Load重排序的检测需要在同一线程的load之间进行。

Store Buffer的分区有一个重要的性能考量：在单线程模式下，只有一个分区被使用，另一个分区完全空闲。这意味着单线程可用的Store Buffer容量只有总容量的一半。对于store-heavy的工作负载（如数据库写入），这种容量减半可能导致Store Buffer满而引发流水线停顿。为此，某些处理器在检测到只有单一活跃线程时，会将整个Store Buffer的容量分配给该线程。

SMT中跨线程的存储器序还涉及内存一致性模型的实现。在x86的TSO（Total Store Order）模型下，同一核心的两个SMT线程共享同一个store buffer，但每个线程只能"看到"自己的store（通过store-to-load forwarding）。然而，一个线程的store在提交后对另一个线程立即可见（因为它们共享同一个L1 D-Cache）。这种"近距离"的一致性保证使得SMT线程之间的数据共享比跨核心更快——这在某些并行算法中可以被利用。

Store-to-Load Forwarding的线程隔离

Store-to-Load Forwarding（STLF）在SMT中需要严格的线程隔离。当线程A执行一条store指令（如MOV [addr], rax）并在Store Buffer中写入数据后，线程B对同一地址的load指令不应该从Store Buffer中获得转发数据——线程B应该从L1 D-Cache中读取。这是因为TSO模型要求：在store被提交到cache之前，它只对发出store的线程可见（通过STLF），对其他线程不可见。

STLF的线程隔离通过在Store Buffer查找逻辑中添加线程ID匹配来实现：只有当store的线程ID与load的线程ID相同时，才允许转发。这个检查的硬件代价很小（每个Store Buffer条目增加1位线程ID），但对正确性至关重要——如果跨线程的STLF被错误地允许，将违反TSO一致性模型，导致程序行为不正确。

SMT下的原子操作

原子操作（如x86的LOCK CMPXCHG、ARM的LL/SC序列）在SMT中有特殊的性能特征。在同一物理核心的两个SMT线程之间，原子操作的延迟比跨核心更低，因为两个线程共享L1 D-Cache——原子操作不需要通过互连网络发送一致性消息。

然而，原子操作的锁定机制在SMT模式下可能影响另一个线程的性能。在Intel处理器中，LOCK前缀的指令在执行期间会短暂地锁定相关的cache line，防止另一个线程的访问。如果两个SMT线程频繁地对同一cache line执行原子操作（如对同一个自旋锁进行cas操作），性能会严重下降——两个线程交替锁定和等待，实际吞吐量可能低于单线程。

设计提示

SMT线程之间的同步原语（互斥锁、条件变量、原子操作）的性能特征与跨核心的同步有质的不同。在跨核心场景中，cache一致性协议的延迟（数十到数百周期）是同步开销的主要来源。在SMT场景中，两个线程共享L1 cache，一致性延迟接近于零——但线程间的干扰（store buffer锁定、cache line乒乓）成为新的性能瓶颈。编写面向SMT的并行代码时，应尽量避免两个SMT线程频繁竞争同一cache line上的原子操作。

Cache与TLB的线程共享

Cache和TLB是SMT设计中最敏感的共享资源。与发射队列和功能单元不同——它们的内容（缓存的数据和页表项）具有持久性的意义——一个线程逐出的cache line或TLB表项会直接影响另一个线程的访问延迟。

L1指令缓存（I-Cache）

L1 I-Cache被所有线程共享。每个线程在执行过程中访问不同的代码区域，它们的代码足迹在I-Cache中形成不同的工作集。SMT的线程共享I-Cache会导致以下问题：

容量竞争：两个线程的代码工作集之和可能超过I-Cache的容量，导致一个线程的取指不断逐出另一个线程的代码行（cache thrashing）。在单线程下I-Cache命中率可能为99%+，但在SMT模式下可能降至95%以下——每个百分点的命中率下降都意味着显著的性能损失。
构造性共享：如果两个线程执行相同或相似的代码（如同一库的不同实例），它们的代码足迹高度重叠，共享I-Cache反而提高了有效容量。这在微服务架构中较为常见——多个相同服务的工作线程共享同一份代码。

在某些高性能处理器中，I-Cache被设计为具有线程感知的替换策略——LRU位可以考虑每个cache line最近被哪个线程访问过，在进行替换时倾向于保留两个线程都频繁访问的共享代码行。

性能分析 7 — SMT模式下的cache容量等效分析

cache容量的有效减少是SMT单线程性能回退的最大来源之一。以Intel Skylake的32 KB L1 D-Cache为例，考虑两个线程各自的独立工作集分别为 $W_A = 20$ KB和 $W_B = 18$ KB：

单线程模式：线程A独占32 KB cache，20 KB工作集完全装入，miss rate $\approx$ 0.5%。

SMT模式：两个工作集之和 $W_A + W_B = 38$ KB $> 32$ KB，cache容量不足。在8路组相联的32 KB cache中，LRU替换导致两个线程的数据互相驱逐。

等效每线程cache容量 $\approx 16$ KB（在均匀竞争下各占一半）
线程A的有效工作集20 KB $> 16$ KB，miss rate上升到 $\approx$ 5% $\sim$ 8%
线程B的有效工作集18 KB $> 16$ KB，miss rate上升到 $\approx$ 3% $\sim$ 6%

假设每次L1 D-Cache miss增加约5个周期的延迟（从L2获取数据），线程A的miss rate从0.5%增加到6%意味着每条load指令平均多0.275个周期的延迟。对于load占指令混合25%的典型工作负载，IPC损失约 $0.275 \times 25\% \approx 7\%$ 。

这解释了为什么Apple选择了128 KB的L1 D-Cache——即使在没有SMT的情况下，超大的L1也能容纳更大的工作集，避免了频繁的L1 miss。

L1数据缓存（D-Cache）

L1 D-Cache的线程共享是SMT性能干扰的主要来源。两个线程的数据工作集通常完全不同（除非它们共享数据结构），共享D-Cache意味着有效的per-thread cache容量降低。

考虑一个32 KB的L1 D-Cache。在单线程模式下，整个32 KB供一个线程使用。在2线程SMT模式下，如果两个线程的数据工作集不重叠，每个线程的有效容量降至约16 KB——这相当于将cache容量减半。对于cache-sensitive的工作负载，这种容量减半可能导致miss rate翻倍甚至更多。

为了量化D-Cache共享的影响，考虑一个具体的例子：假设线程A的数据工作集为24 KB，线程B的数据工作集为20 KB。在单线程模式下，两个工作集都能完全装入32 KB的L1 D-Cache中（miss rate $<$ 1%）。在SMT模式下，两个工作集之和为44 KB，超过了32 KB的cache容量。根据LRU替换策略的特性，两个线程将反复逐出对方的数据行，miss rate可能飙升至10% $\sim$ 20%以上。这种现象称为cache thrashing（缓存抖动），是SMT性能干扰的主要来源之一。

Cache替换策略的SMT感知

标准的LRU替换策略在SMT模式下可能对某些线程不公平。如果两个线程的cache访问率不同（例如线程A每周期访问2次cache，线程B每周期仅0.5次），线程A的高频访问会持续刷新其cache line的LRU状态，导致线程B的cache line更容易被替换。

为缓解这个问题，一些处理器实现了线程感知的替换策略：

Utility-based Cache Partitioning：在运行时监测每个线程的cache效用——如果给线程A多分配一路cache不能显著降低其miss率，但给线程B多分配一路能显著降低miss率，则替换策略偏向保留线程B的cache line。
Adaptive Insertion Policy：高miss率线程的新cache line被插入到LRU的"中间"位置，使其更快地被替换掉，释放空间给另一个线程。
Thread-aware RRIP：在Re-Reference Interval Prediction替换策略中，根据线程ID调整插入优先级，确保两个线程的cache占用更均衡。

这些优化在特定的不对称工作负载组合中（一个线程cache友好，另一个cache不友好）可以带来2% $\sim$ 5%的IPC改善——将SMT从"两个线程都受损"改善为"cache不友好线程适当让步，cache友好线程保持接近独占性能"。

L2/L3缓存

更高层次的cache（L2、L3）通常也被同一核心的所有SMT线程共享。由于L2/L3的容量通常远大于L1（256 KB $\sim$ 数MB），线程间的容量竞争相对缓和。但在某些内存密集型工作负载下，L2级别的cache thrashing仍然可能显著影响性能。

L2 cache的SMT共享有一个重要的优势：当两个线程访问相同的数据（如共享库代码、共享数据结构），共享的L2 cache避免了数据冗余——只需保存一份副本即可服务两个线程。这种构造性共享（Constructive Sharing）在以下场景中尤为显著：

多实例工作负载：如Web服务器的多个worker线程执行相同的处理逻辑，代码和只读数据高度重叠。
生产者-消费者模式：如果两个SMT线程形成生产者-消费者关系（一个线程产生数据，另一个线程消费），数据可以通过共享的L1/L2 cache传递，延迟仅几个周期——远低于跨核心通过一致性协议传递的数十到数百周期。
JIT编译环境：Java HotSpot、V8 JavaScript引擎等JIT编译器在运行时生成机器代码。两个运行相同JIT编译代码的SMT线程共享代码的cache行，提高了I-cache和uop cache的有效命中率。

然而，L2 cache共享也引入了预取器干扰。大多数处理器的L2预取器是线程共享的——它观察L2 miss的地址模式并发起预取请求。在SMT模式下，两个线程的L2 miss流混合在一起，可能混淆预取器的模式检测逻辑。例如，如果线程A以stride=64字节的模式顺序访问数组，而线程B以随机模式访问链表，预取器看到的混合流将不呈现清晰的stride模式，导致预取精度下降。某些处理器通过为每个线程维护独立的预取状态跟踪来缓解这一问题。

L3 cache的SMT影响

在多核处理器中，L3（LLC）通常由所有核心共享。SMT对L3的影响是间接的：由于SMT模式下每核心的L1/L2 miss率可能上升（两个线程竞争L1/L2容量），更多的请求到达L3 cache。如果L3的容量和带宽足够，这些额外的L3请求不会造成显著的性能影响；但如果L3已经接近饱和，SMT增加的L3压力可能导致L3命中率下降，间接影响所有核心（包括那些运行单线程的核心）的性能。

这种"SMT的L3溢出效应"在大规模服务器处理器中是一个实际的问题。例如，在一个32核64线程的Intel Xeon处理器中，启用全部核心的HT后，L3的总访问速率增加约40% $\sim$ 60%，可能导致L3的有效命中率下降2% $\sim$ 5%。Intel的CAT（Cache Allocation Technology）可以通过为不同核心分配不同的LLC Way来部分缓解这一问题。

TLB的线程共享

TLB（Translation Lookaside Buffer）的线程共享需要额外的硬件支持来区分不同线程（或不同进程）的页表项。核心挑战是：两个SMT线程可能属于不同的进程，拥有完全不同的页表——虚拟地址0x1000在线程A中可能映射到物理地址0x2000_1000，而在线程B中映射到0x5000_1000。TLB必须能够区分这两个映射。

带PCID/ASID标记的TLB表项。PCID字段使得不同线程/进程的页表映射可以同时存在于TLB中，避免了线程切换时的TLB刷新。

TLB容量的量化分析

TLB容量在SMT模式下的有效减少可以被精确量化。考虑一个64项、全相联的L1 DTLB。在单线程模式下，一个线程可以使用全部64个TLB项来映射 $64 \times 4\,\text{KB} = 256$ KB的虚拟地址空间（4 KB页）。在2线程SMT模式下，两个线程竞争64个TLB项。在最坏情况下（两个线程的地址空间完全不同），每个线程平均只有32个TLB项可用，可映射的地址空间缩小到128 KB。

对于工作集大于128 KB的工作负载，这意味着TLB miss率会显著上升。考虑到现代处理器的页表walk延迟约为10 $\sim$ 40个周期（L1 page table cache命中时）或100 $\sim$ 300个周期（需要从内存加载页表时），TLB miss率每上升1%就可能增加约1 $\sim$ 3个周期的平均每指令延迟。

如果两个SMT线程属于同一进程（共享同一页表），情况会好得多——两个线程的TLB项可以互相命中（因为虚拟地址到物理地址的映射相同），TLB的有效容量不减少。这也是为什么在同一进程的多个线程之间使用SMT通常比在不同进程的线程之间使用SMT更高效的原因之一。

解决这个问题的标准方案是PCID（Process-Context Identifier）或ASID（Address Space Identifier）标记。每个TLB表项除了存储VPN到PFN的映射外，还存储一个PCID/ASID标签。TLB查找时，输入的虚拟地址和当前线程的PCID同时参与比较——只有VPN和PCID都匹配的表项才算命中。这样，不同线程（即使运行不同进程）的TLB表项可以同时存在于TLB中而不会冲突。

在x86-64架构中，PCID是一个12位的标识符，支持4096个不同的地址空间标识。Intel从Westmere开始支持PCID。ARM架构中对应的概念是ASID，在ARMv8-A中为8位或16位。RISC-V中同样定义了ASID字段（在satp寄存器中），宽度取决于具体实现。

设计提示

在没有PCID/ASID支持的早期处理器中，SMT线程切换或不同进程的线程在同一核心上执行时，需要在每次"上下文切换"时刷新TLB（TLB flush）。这对性能影响巨大——刷新TLB意味着后续的每次地址翻译都会miss，直到TLB被重新填充（cold-start penalty）。PCID/ASID的引入使得TLB中可以同时保存多个地址空间的映射，大幅降低了SMT和上下文切换的开销。

线程优先级调度

在SMT处理器中，线程优先级调度涉及两个层面：前端调度（哪个线程获得取指带宽）和后端调度（哪个线程的指令优先发射到功能单元）。这两个层面的调度策略共同决定了SMT的性能和公平性特征。

前端调度：ICOUNT策略及其改进

ICOUNT策略（由Tullsen等人提出）是SMT取指调度最经典的算法。其核心思想简洁而有效：为每个线程维护一个计数器，记录该线程在流水线中（从取指到提交）的指令总数。每个周期，优先为计数器值最小的线程取指。

ICOUNT策略的直觉是：流水线中指令数量少的线程要么刚开始执行、要么经历了分支误预测后的流水线冲洗、要么取指带宽不足——无论哪种情况，给予更多取指机会都是合理的。而指令数量多的线程已经积累了足够的指令供后端消费，不需要额外的取指带宽。

然而，ICOUNT有一个显著的盲点：它无法区分"流水线中有很多指令且进展良好"的线程和"流水线中有很多指令但全部等待L2 miss"的线程。后者的指令虽然数量多，但它们堵塞了ROB和发射队列而不产出任何有用工作。ICOUNT会继续给这类线程分配正常（甚至更少）的取指带宽，但问题在于它已经占用了大量后端资源。

针对这个问题，后续研究提出了多种改进：

STALL策略：当检测到某个线程发生L2 cache miss时，停止为该线程取指（fetch gating），直到miss被解决。这防止了cache miss线程的后续指令继续涌入流水线、占用ROB和发射队列。STALL策略的实现相对简单——只需要一个per-thread的fetch gate信号和L2 miss检测逻辑。
FLUSH策略：更激进的做法——当检测到L2 miss时，不仅停止取指，还将该线程在流水线中的所有指令全部冲洗（flush），释放它们占用的所有后端资源。当miss数据返回后，从miss点重新开始取指和执行。这种策略能最大限度地释放资源给其他线程，但冲洗和重新执行的开销较大。FLUSH策略的代价是冲洗后需要从miss PC点重新取指、解码和重命名——这个"重建"开销约为流水线深度 $D$ 个周期（如15 $\sim$ 20个周期）。因此，FLUSH只在miss延迟远大于重建开销时才有正收益——典型的判断阈值是miss延迟 $> 3D$ 。
DCRA（Dynamic Critical Resource Allocation）：综合考虑多种共享资源（ROB、发射队列、L1/L2 cache miss率）的使用情况，动态地调整每个线程的资源配额。当某个线程的资源使用效率低下时（如大量ROB表项被无法提交的指令占据），降低其取指优先级和资源配额。DCRA的核心创新在于关键资源识别——它在运行时动态判断哪种资源是当前的性能瓶颈（可能是ROB、也可能是发射队列或物理寄存器），然后优先优化该关键资源的分配。
MLP感知取指（MLP-Aware Fetch Policy）：在STALL策略的基础上，识别一种重要的例外情况——如果cache miss线程正在执行一系列独立的内存访问（即Memory-Level Parallelism, MLP较高），继续为其取指实际上是有益的，因为后续的独立miss可以与当前的miss重叠执行。MLP感知取指策略在检测到miss线程具有高MLP时允许继续取指，只在miss线程的MLP较低时（如依赖链导致的串行miss）才触发取指门控。

取指策略的硬件实现复杂度

先进的取指策略（如DCRA和MLP感知策略）需要额外的硬件支持：

per-thread资源占用计数器：跟踪每个线程在ROB、RS、PRF中的占用量。这些计数器在每次分配和释放时递增/递减，面积开销约为数百个触发器。
miss状态追踪：跟踪每个线程的未完成cache miss数量和类型（L1/L2/L3 miss）。MSHR（Miss Status Holding Register）中已经包含了这些信息，只需要添加per-thread的聚合计数器。
IPC估算逻辑：某些策略需要估算每个线程的当前IPC，这可以通过滑动窗口计数器实现——统计最近 $K$ 个周期内每个线程提交的指令数。
决策逻辑：将以上信息综合为取指优先级决策。在商用处理器中，这通常实现为一组可编程的阈值比较器和优先级编码器，总面积不超过核心面积的0.1%。

后端调度：发射优先级

在发射队列中，来自不同线程的就绪指令竞争有限的功能单元。发射选择逻辑需要一种策略来在线程间分配发射带宽：

线程无关选择（Thread-Oblivious Selection）：最简单的策略，选择逻辑不考虑指令所属的线程，仅根据就绪状态和年龄（或其他优先级）选择发射。在大多数情况下，这种策略工作良好——就绪指令自然地获得发射机会，停顿线程的指令因为不就绪而不参与竞争。
线程感知选择（Thread-Aware Selection）：在线程无关选择的基础上增加公平性约束——如果某个线程在最近的 $K$ 个周期中获得了不成比例的发射带宽，则适当降低其优先级，给予其他线程更多机会。 $K$ 的典型值为16 $\sim$ 64个周期——太小会导致频繁的优先级切换（增加功耗和延迟），太大会导致不公平性积累。
优先级提升（Priority Boosting）：给关键路径上的指令更高的发射优先级。例如，距离提交最近的指令（ROB head附近的指令）获得更高优先级，因为它们的完成直接释放ROB空间，使所有线程受益。优先级提升还可以应用于miss数据刚返回后解除阻塞的指令链——这些指令处于该线程的关键路径上，优先执行它们可以更快地释放被占用的ROB和PRF资源。
最老优先（Oldest-First）：在所有就绪指令中选择年龄最大的——即最先进入发射队列的指令。这种策略天然倾向于公平性（两个线程的指令交替变老），且有助于尽快清空ROB（最老的指令通常距离提交最近）。许多商用处理器将"最老优先"作为基础策略，在此之上叠加行命中优先或线程感知等修正。

性能分析 8 — SMT调度策略对性能的影响

在模拟实验中，不同的SMT取指和发射调度策略对吞吐量的影响差异显著：

调度策略	吞吐量	公平性（CoV）
Round-Robin	1.00	0.35
ICOUNT	1.15	0.28
ICOUNT + STALL	1.22	0.22
ICOUNT + FLUSH	1.25	0.20
DCRA	1.28	0.18

（CoV为Coefficient of Variation，越小表示线程间越公平。数据来源于对SPEC CPU2000基准测试的学术模拟。）

ICOUNT相比简单轮转提供了约15%的吞吐量提升。加入STALL/FLUSH机制后，吞吐量进一步提升5% $\sim$ 10%，同时公平性也有所改善。

SMT的实际实现

从概念到产品，SMT技术已经在多个商用处理器系列中得到了广泛实现。不同厂商对SMT的线程数量、资源共享策略和设计哲学有着截然不同的选择，这些差异反映了不同的市场定位和技术权衡。

Intel Hyper-Threading

Intel的Hyper-Threading（HT）技术是工业界最成功和最广为人知的SMT实现。Hyper-Threading于2002年首次出现在Pentium 4（代号Northwood）中，此后在Intel的几乎每一代桌面和服务器处理器中都有搭载——从Core微架构到Skylake、Ice Lake，直到Alder Lake的P-core。

Pentium 4中的初始实现

Pentium 4的Hyper-Threading是第一个大规模商用的SMT实现。Pentium 4是一个极深流水线（20 $\sim$ 31级）的处理器，其IPC相对较低，这使得它特别适合通过SMT来填充空闲的流水线资源。Intel报告，HT在Pentium 4上仅增加了约5%的核心面积，但在多线程工作负载上提供了约15% $\sim$ 30%的吞吐量提升。

在Pentium 4的实现中，以下资源被复制（每个线程一份）：

体系结构寄存器集合及其重命名映射
程序计数器和下一地址逻辑
APIC（高级可编程中断控制器）的线程局部状态
少量控制寄存器

以下资源被静态分区：

ROB表项：每个线程获得一半
Store Buffer：每个线程获得一半
某些内部队列

以下资源被完全共享：

Trace Cache（Pentium 4特有的decoded指令缓存）
发射队列（Reservation Station）
所有执行单元
L1 D-Cache、L2 Cache
分支预测器（除GHR外）

Pentium 4 HT的设计教训

Pentium 4的HT实现提供了几个重要的设计教训：

教训一：Trace Cache的线程共享效果。Pentium 4使用Trace Cache（TC）替代传统的I-Cache来存储已解码的uops。TC被两个HT线程完全共享，容量约为12K uops。在SMT模式下，两个线程的TC工作集经常超过12K uops，导致频繁的TC miss。TC miss后需要从L2 cache重新取指和解码，延迟高达约20 $\sim$ 30个周期。这个经验表明，前端decoded指令cache的容量在SMT下需要比单线程设计更大。Intel在后续的Core微架构中用传统I-Cache替代了Trace Cache，但在Skylake中重新引入的uop Cache（DSB）吸取了这一教训，容量设计为约2K uops（远小于Trace Cache但与I-Cache并行工作），并在Golden Cove中进一步增大到约4K uops。

教训二：极深流水线放大了SMT的分支预测惩罚。Pentium 4的31级流水线在分支预测失败时需要冲洗大量的流水线级。在SMT模式下，一个线程的分支预测失败不仅浪费了该线程在流水线中的所有指令占用的资源，还间接影响了另一个线程——因为这些被冲洗的指令在冲洗完成之前仍然占用着ROB、RS和PRF资源。Intel在后续微架构中缩短了流水线深度（Core微架构约14级），部分原因就是为了降低SMT下分支预测失败的连锁影响。

教训三：静态分区的单线程惩罚。Pentium 4对ROB的严格静态分区（每线程一半）在单线程运行时造成了不必要的资源浪费。后续的Intel微架构逐渐从纯静态分区转向混合分区策略——在ROB上仍然使用分区（为了实现简单性和公平性保证），但PRF和RS则采用共享或动态分区。

Skylake及后续微架构中的HT

随着Intel微架构的演进，Hyper-Threading的实现也变得更加精细。以Skylake为例：

案例研究 1 — Intel Skylake的Hyper-Threading资源分配

Skylake是一个8-wide的超标量乱序处理器，ROB深度224项，支持2线程SMT。以下是其关键资源在HT模式下的分配策略：

资源	单线程	HT模式/线程	策略
ROB	224	112	静态分区
RS（发射队列）	97	共享97	完全共享
整数PRF	180	共享180	动态共享
向量PRF	168	共享168	动态共享
Load Buffer	72	36	静态分区
Store Buffer	56	28	静态分区
L1 D-Cache	32 KB	共享32 KB	完全共享
L2 Cache	256 KB	共享256 KB	完全共享
取指带宽	16 B/cyc	交替	轮转/按需
解码带宽	4 $\sim$ 5 uops/cyc	共享	竞争

Skylake在HT模式下的关键设计决策：

ROB采用静态分区（每个线程112项），保证了每个线程最低的指令窗口大小，防止一个线程饿死另一个线程。
RS（97项）完全共享——这是一个有意的选择。RS表项的寿命通常较短（指令就绪后很快发射），一个线程的长延迟操作主要消耗ROB而非RS。
PRF动态共享，但有每线程的最小保证配额。
Load/Store Buffer静态分区，确保存储器排序的正确性。

Golden Cove和Raptor Cove

Intel的Golden Cove（Alder Lake P-core，2021年）和后续的Raptor Cove继续支持HT，但资源规模显著增大。Golden Cove将ROB扩展到512项，RS扩展到多个分布式调度器共约160+项，执行端口增加到12个。在HT模式下，每个线程获得ROB的一半（256项），仍然大于Skylake的单线程ROB容量（224项）——这意味着即使在HT模式下，每个线程的指令窗口也足够大。

Golden Cove的HT实现相比Skylake还做了以下改进：

分支预测器部分分区：TAGE预测器的一级表按线程标记（使用thread ID拼接到索引或标签中），减少线程间的别名污染。BTB仍然完全共享。
更精细的取指调度：取指调度器考虑了更多的后端反压信号——如果某个线程的ROB分区即将填满，减少对该线程的取指分配。
uop Cache共享优化：uop Cache（Decoded Stream Buffer）被两个线程共享，但Intel在Golden Cove中增大了uop Cache的容量（约4K uops），使得HT模式下每个线程仍有充足的uop Cache空间。

HT模式切换的微架构细节

Intel处理器支持在运行时通过操作系统指令动态启用或禁用HT。当从单线程模式切换到HT模式（即第二个线程被激活）时，处理器需要执行以下微架构操作：

资源重新分区：ROB从单线程模式的全容量（如512项）切换到每线程256项。这需要更新ROB的尾指针逻辑，为新线程分配一个独立的ROB区域。Load Buffer和Store Buffer同样需要重新分区。
RAT初始化：为新线程创建一个新的寄存器别名表，将其所有体系结构寄存器映射到PRF中的初始物理寄存器。
分支预测器状态：为新线程分配独立的GHR和RAS。预测表本身不需要变化（共享），但新线程的初始预测精度会很低，需要经过暖机期。
取指仲裁器激活：将取指仲裁器从单线程直通模式切换到多线程轮转/ICOUNT模式。
uop Cache标记：uop Cache中已有的表项需要开始检查线程ID匹配（在单线程模式下可能被优化掉的检查）。

整个切换过程通常需要数千个时钟周期（约1 $\sim$ 2 $\mu$ s），在此期间处理器的性能可能出现短暂下降。操作系统通过MWAIT/MONITOR指令或直接的MSR写入来触发线程的激活/停用。

HT对微码操作的影响

在Intel处理器中，复杂的x86指令（如REP MOVSB、CPUID、某些系统指令）由微码引擎（Microcode Sequencer Unit, MSROM）生成大量的uops来实现。在HT模式下，微码操作面临特殊的挑战：

MSROM独占：当一个线程执行需要微码的指令时，MSROM被该线程独占。另一个线程的解码被阻塞，直到微码序列完成。在Golden Cove中，MSROM的独占时间可能长达数十个周期（例如CPUID需要约100+个uops）。
微码辅助（Microcode Assists）：某些看似简单的指令在特定条件下需要微码辅助——例如浮点非规格化数运算、某些页表walk场景。这些微码辅助在HT模式下同样会独占MSROM，对另一个线程造成干扰。
安全相关微码：Spectre/Meltdown缓解的微码补丁在上下文切换和系统调用入口处插入了额外的微码序列（如VERW缓冲区清洗）。这些额外的微码序列在HT模式下对两个线程都有性能影响，因为它们独占MSROM并消耗发射带宽。

Arrow Lake的HT取消

从Arrow Lake（2024年）开始，Intel在P-core上取消了Hyper-Threading。这是一个标志性的行业决策，反映了以下趋势：

核心宽度的增长：Arrow Lake P-core（Lion Cove微架构）的执行引擎进一步加宽，单线程IPC持续提升。在如此宽的核心中，单线程已经能较好地利用执行资源，SMT的边际收益降低。
混合架构的成熟：Arrow Lake拥有足够多的E-core，在多线程工作负载下可以通过E-core提供吞吐量，不再依赖P-core的SMT。
安全压力：SMT相关的安全漏洞（MDS、PortSmash等）持续被发现，维护SMT安全补丁的工程成本不断增加。
面积回收：取消SMT可以节省约5% $\sim$ 10%的核心面积，这些面积可以用于其他性能改进（如更大的cache、更宽的执行引擎）。

HT的面积开销分析

在Intel的不同代际微架构中，HT的面积开销随着核心宽度的增加而有所变化。表表 45.7展示了这一趋势：

微架构	年份	核心宽度	ROB深度	HT面积开销
Pentium 4 (Northwood)	2002	3-wide	126	$\sim$ 5%
Nehalem	2008	4-wide	128	$\sim$ 8%
Sandy Bridge	2011	4-wide	168	$\sim$ 8%
Haswell	2013	4-wide	192	$\sim$ 9%
Skylake	2015	4 $\sim$ 5-wide	224	$\sim$ 10%
Golden Cove	2021	6-wide	512	$\sim$ 12%

面积开销的增加主要来自两个因素：（1）更深的ROB需要更大的PRF来支持SMT模式下的指令窗口，PRF的扩大是面积增长的主要贡献者；（2）更宽的核心需要更复杂的线程仲裁逻辑（更多的发射端口需要更多的线程竞争检测逻辑）。尽管如此，HT的面积开销始终保持在核心面积的15%以下——这是SMT作为一种高效的性能增强技术的根本优势。

HT的性能特征

Intel Hyper-Threading在不同工作负载下的性能表现差异很大：

吞吐量型工作负载（如Web服务器、虚拟化、编译）：HT通常提供20% $\sim$ 30%的吞吐量提升，代价是每个线程的延迟略有增加（5% $\sim$ 15%）。
计算密集型工作负载（如矩阵运算、视频编码）：如果单线程已经能充分利用执行资源（高IPC），HT的吞吐量提升可能仅5% $\sim$ 10%，甚至为负——两个线程竞争L1 cache可能导致性能下降。
内存密集型工作负载（如大数据集的链表遍历）：HT效果显著，因为一个线程的cache miss停顿可以被另一个线程的有用工作填充。吞吐量提升可达30% $\sim$ 40%。
延迟敏感型工作负载（如高频交易、游戏）：HT可能导致单线程延迟增加，某些用户选择在BIOS中禁用HT以获得最低的单线程延迟。

案例研究 2 — HT对游戏性能的影响

游戏工作负载是HT影响最为复杂的场景之一。现代3D游戏的渲染管线通常包含以下线程：

主渲染线程：执行Draw Call提交、场景遍历和GPU命令生成——对单线程延迟极其敏感。
物理/AI线程：计算物理模拟和AI决策——计算密集型但可并行化。
资源加载线程：从磁盘加载纹理和模型——I/O密集型。
音频线程：实时音频处理——低延迟但低CPU占用。

在HT启用时，如果主渲染线程恰好与一个物理线程共享同一物理核心的两个SMT线程，主渲染线程的L1 cache和分支预测器会受到物理线程的干扰，导致帧时间增加1 $\sim$ 3 ms——在60 fps的目标下（每帧16.7 ms），这意味着约6% $\sim$ 18%的帧时间预算被消耗在SMT干扰上。

解决方案是操作系统的核亲和性（Core Affinity）——将主渲染线程绑定到一个物理核心上，并禁止其他线程使用该核心的第二个HT线程。Windows 11的Thread Director在与游戏引擎配合时，通常能自动做出合理的调度决策——将主渲染线程调度到P-core上，将物理/AI线程分散到E-core或其他P-core上。

设计提示

Intel在Alder Lake及后续的混合架构中做出了一个值得注意的决策：性能核（P-core）支持HT（每核2线程），而效率核（E-core）不支持HT（每核1线程）。E-core基于Gracemont微架构，其设计哲学是用更多的小核心而非通过SMT来提供吞吐量。这反映了一种行业趋势——对于面积受限的小核心，添加更多核心比在每个核心上添加SMT可能更高效。值得注意的是，从Arrow Lake开始，Intel在P-core上也取消了HT，转向纯粹的更多核心策略。

IBM POWER10的8线程SMT

与Intel的保守的2线程SMT不同，IBM在其POWER系列服务器处理器中一直采用更激进的多线程策略。POWER10（2021年）支持SMT8——每个核心同时支持8个硬件线程。这是商用处理器中SMT线程数最多的设计之一。

POWER系列的SMT演进

IBM的SMT实现经历了以下演进：

POWER5（2004年）：SMT2，2线程——IBM首次在POWER系列中引入SMT。
POWER7（2010年）：SMT4，4线程——每核心4个硬件线程，可在ST/SMT2/SMT4模式之间动态切换。
POWER8（2014年）：SMT8，8线程——大幅扩展到每核心8个硬件线程。
POWER9（2017年）：SMT4，4线程——回退到4线程（但核心微架构大幅改进）。
POWER10（2021年）：SMT8，8线程——重新回到8线程设计。

POWER10的SMT8微架构

POWER10是一个8发射的超标量乱序处理器，ROB深度约为512项。为了支持8线程SMT，POWER10在资源管理上做了以下设计：

灵活的线程模式：POWER10可以在运行时在ST（单线程）、SMT2（2线程）、SMT4（4线程）和SMT8（8线程）四种模式之间动态切换。操作系统（AIX或Linux）的调度器根据当前工作负载的特征选择最优的线程模式。在单线程模式下，所有资源（包括8份体系结构寄存器集合中的一份）全部由单一线程使用，提供最大的单线程性能。
取指轮转：在SMT8模式下，每2个周期为一个线程取指（8个线程每16个周期完成一轮）。在SMT4模式下，取指轮转速度更快。
ROB分区：ROB按线程数量等分——SMT8模式下每个线程获得约64项，SMT2模式下每个线程获得约256项。
发射队列共享：发射队列被所有活跃线程共享，但有per-thread配额限制。
独立的架构状态：8份完整的体系结构寄存器集合，包括64个通用寄存器（POWER ISA的GPR数量为32，但重命名后每线程需要更多）、向量寄存器、浮点寄存器和控制寄存器。

POWER10 SMT8的一致性与内存序考量

在8线程SMT中，内存一致性和存储器序的维护面临独特的挑战。8个线程共享同一个L1 D-Cache和Store Buffer，以下问题需要特别处理：

Store Buffer的分区：POWER10的Store Buffer需要支持8个线程的独立store序列。如果Store Buffer总容量为64项，每线程静态分区后只有8项——这对于store密集型的工作负载可能成为瓶颈。POWER10据信采用了混合分区策略——每线程保证最低4 $\sim$ 6项，剩余项动态共享。
Load-Load序的维护：POWER ISA采用弱一致性模型（与x86的TSO不同），某些load-load重排序是允许的。这简化了SMT8下的load ordering逻辑——不需要像x86那样严格检测所有load-load违规。
Barrier指令的处理：sync和lwsync等barrier指令在SMT8模式下需要确保只屏障发出barrier的那个线程的load/store，而不影响其他7个线程的正常执行。这需要per-thread的barrier状态追踪。

SMT8的应用场景

POWER10的SMT8设计主要面向以下工作负载：

数据库事务处理（OLTP）：大量并发的短事务，每个事务的IPC不高但并发量极大。SMT8允许单个核心同时处理8个事务，充分利用执行资源。
Java应用服务器：大量的Java线程并发执行，JVM的JIT编译代码通常cache友好但有频繁的短停顿（GC、同步）。
虚拟化：每个SMT线程可以运行一个独立的虚拟机线程，最大化物理核心的利用率。
AI推理：矩阵运算中的流水线气泡可以被其他线程填充。
加密和压缩：SSL/TLS握手和数据压缩/解压缩任务中存在大量短延迟停顿和分支密集的代码段，SMT8可以在这些停顿期间有效利用执行资源。

性能分析 9 — POWER10 SMT模式下的SAP SD性能

SAP Sales and Distribution（SD）基准测试是衡量企业服务器事务处理能力的标准测试。在POWER10上的实测数据展示了SMT8的威力：

假设一个POWER10处理器配备15个核心，运行SAP SD基准：

ST模式（15核15线程）：约90,000 SAPS
SMT2模式（15核30线程）：约140,000 SAPS（+55%）
SMT4模式（15核60线程）：约180,000 SAPS（+100%）
SMT8模式（15核120线程）：约210,000 SAPS（+133%）

从ST到SMT8，吞吐量提升了133%——核心数量不变，只靠SMT就获得了2.3倍的吞吐量。每线程的性能从6,000 SAPS降低到1,750 SAPS（降低71%），但这对于事务处理系统来说完全可以接受——每个事务的延迟从约1 ms增加到约3 ms，仍然在SLA（Service Level Agreement）要求的范围内。

这个案例清楚地说明了为什么IBM坚持SMT8策略——在企业工作负载中，SMT8带来的吞吐量增益是巨大且实际的。

POWER10的动态线程模式切换是其SMT实现的一大亮点。操作系统可以通过写入特殊的控制寄存器在不同SMT模式之间切换，切换延迟约为数十个周期。在实际部署中，AIX操作系统的调度器会监测工作负载的线程利用率和IPC特征：当检测到工作负载主要由少量高IPC线程组成时，自动降低SMT级别（如从SMT8降到SMT2或ST），将全部资源集中给少数线程以最大化单线程性能；当检测到大量并发线程且每线程IPC较低时，自动升级到SMT8以最大化吞吐量。

POWER10 SMT8的极端资源共享

支持8线程SMT对微架构资源管理提出了极端的挑战。与2线程SMT中每线程获得约50%的分区资源不同，8线程SMT中每线程在最差情况下只能获得约12.5%的分区资源。这要求POWER10在资源管理上做出更加精巧的设计。

取指带宽分配：POWER10的8-wide取指在SMT8模式下无法在单个周期内为所有8个线程取指。取指器采用2周期轮转策略——每2个周期为一个线程取指，8个线程完成一轮需要16个周期。这意味着在SMT8模式下，每个线程每16个周期才能获得一次取指机会，取指带宽降低为单线程的1/8。为了补偿这一带宽损失，POWER10为每个线程配备了独立的取指缓冲区（Instruction Buffer, IB），容量足以缓冲2 $\sim$ 4次取指的指令量，确保解码器在取指间隔期间仍有指令可供消费。

在SMT4和SMT2模式下，取指轮转速度更快——SMT4每8个周期完成一轮，SMT2每4个周期一轮。取指缓冲区在较少线程模式下的有效容量更大，允许前端更深的预取。

解码与分派带宽：POWER10的8-wide解码器在SMT8模式下的带宽分配面临一个有趣的设计决策。由于每个周期通常只有一个线程有取指结果可供解码，解码器实际上可以将全部8条解码槽位分配给该线程——这使得即使在SMT8模式下，单个线程在获得解码机会时仍然可以以全速解码。瓶颈在于获得解码机会的频率（每8 $\sim$ 16个周期一次），而非解码带宽本身。

ROB分区的极端影响：在SMT8模式下，512项ROB被均分为8份，每线程仅64项。64项的指令窗口在现代处理器中是极为有限的——它甚至不足以覆盖一次L3 cache miss的延迟（假设L3延迟50个周期，IPC=2，飞行指令数 $= 100 > 64$ ）。这意味着在SMT8模式下，每个线程的乱序执行能力被严重限制——处理器更像是一个8路细粒度多线程机器而非8路同时多线程机器。POWER10通过以下方式缓解这一问题：

大容量L2 cache：POWER10每核配备2 MB的私有L2 cache（远大于Intel的1.25 MB），降低L2 miss率，减少长延迟事件对ROB的占用。
激进的硬件预取：POWER10配备了多级硬件预取器，在数据到达之前提前将其加载到L2 cache，进一步降低有效的miss延迟。
目标工作负载的特性：POWER10面向的企业工作负载（如数据库事务、Java应用服务器）通常每线程IPC不高（约1 $\sim$ 2），飞行指令数在30 $\sim$ 50条左右，64项的ROB在大多数情况下足够。

物理寄存器文件的规模：支持8线程SMT要求极大的物理寄存器文件。POWER ISA定义了32个通用寄存器、64个向量/浮点寄存器和大量的控制/特殊寄存器。8个线程需要至少 $8 \times 32 = 256$ 个体系结构通用寄存器的映射空间，加上飞行中指令的重命名需求。POWER10的整数PRF估计有500+个物理寄存器，向量PRF同样规模庞大。这是POWER10 SMT面积开销达到25% $\sim$ 30%（远高于Intel HT的10% $\sim$ 15%）的主要原因之一。

性能分析 10 — POWER10不同SMT模式下的资源分配

资源	ST	SMT2	SMT4	SMT8
ROB（每线程）	512	256	128	64
取指频率	每周期	每2周期	每4周期	每8 $\sim$ 16周期
GPR（体系结构）	32	32	32	32
每线程有效IPC上限	8.0	4.0	2.0	1.0
发射队列	全部共享	共享	共享	共享
L1 D-Cache	独占	共享	共享	共享
L2 Cache (2MB)	独占	共享	共享	共享

从表中可以看出，POWER10的SMT8模式极大地牺牲了每线程的资源配额。64项的ROB和每8 $\sim$ 16周期一次的取指机会将每线程的有效IPC上限压缩到约1.0——但8个线程的总吞吐量可以达到近8.0 IPC，远超单线程的约4 $\sim$ 5 IPC。这种设计在吞吐量导向的服务器工作负载中非常高效。

案例研究 3 — POWER10与Intel Golden Cove的SMT设计对比

特性	IBM POWER10	Intel Golden Cove
SMT线程数	8	2
发射宽度	8	12
ROB深度	$\sim$ 512	512
每线程ROB（max SMT）	$\sim$ 64	256
单线程ROB	$\sim$ 512	512
SMT面积开销	$\sim$ 25% $\sim$ 30%	$\sim$ 10% $\sim$ 15%
单线程IPC	中等	高
多线程吞吐量	极高	高
典型工作负载	企业服务器	桌面/数据中心
制程	7 nm	Intel 7 (10 nm)

POWER10的设计哲学与Intel截然不同。POWER10更愿意牺牲单线程性能来换取多线程吞吐量——在SMT8模式下，每个线程的指令窗口仅有 $\sim$ 64项，远小于Golden Cove的256项。但8个线程共同产生的总吞吐量可能高于Golden Cove的2个线程。这种设计在吞吐量导向的服务器工作负载中非常有效。

这两种设计反映了不同的市场需求：

Intel面向通用计算市场——从游戏到办公到服务器，单线程性能始终重要。因此Intel选择保守的SMT2，确保单线程性能的回退最小。
IBM面向企业服务器市场——数据库事务处理、Java应用服务器等工作负载的特点是大量并发的轻量级线程。单线程性能不是首要指标，吞吐量和硬件线程数才是。因此IBM选择激进的SMT8，即使每线程性能大幅下降也可以接受。
AMD的EPYC系列也采用了SMT2，但通过Chiplet架构将核心数量推到极致（最多128核256线程）。AMD的策略是"更多的SMT2核心"而非"更少的SMT8核心"——这种选择在通用服务器市场上被证明是成功的。

为什么IBM能做到SMT8而Intel只做SMT2？

这个问题的答案涉及市场定位、ISA特性和微架构哲学三个层面的差异。

**第一，目标工作负载的IPC差异。**IBM POWER面向的企业工作负载（OLTP数据库、Java应用服务器、SAP）的每线程IPC通常不高——约1.0 $\sim$ 2.5。这类工作负载包含大量的短停顿（锁等待、GC暂停、I/O等待），执行资源在这些停顿期间完全空闲。SMT8可以用其他7个线程来填充这些空闲周期。相比之下，Intel面向的桌面和通用服务器工作负载的单线程IPC通常较高（3.0 $\sim$ 5.0），执行资源的空闲率较低，SMT的边际收益已经有限——从SMT2到SMT4的额外收益不足以补偿每线程ROB窗口缩小到128项（512/4）带来的单线程性能损失。

**第二，POWER ISA的弱内存模型优势。**POWER ISA采用弱一致性内存模型（Weak Consistency），允许某些load-load和load-store重排序。这简化了SMT8下的存储器序维护——不需要像x86 TSO那样对同一核心的所有线程严格维护store-to-load序。在x86的TSO模型下，8个线程共享的Store Buffer需要支持复杂的跨线程可见性检查，硬件复杂度随线程数呈超线性增长。POWER ISA的弱模型允许更宽松的store ordering，显著降低了SMT8的Store Buffer设计复杂度。

**第三，POWER核心的吞吐量导向微架构。**POWER10的8-wide核心在设计时就以多线程吞吐量为首要目标。它的L2 Cache更大（2MB vs Intel的1.25MB），可以容纳8个线程的工作集而不频繁miss。它的取指器设计支持8路轮转取指，每个线程有独立的取指缓冲区。这些设计从一开始就为SMT8做了准备，而非像Intel那样在单线程优先的微架构上"嫁接"SMT。

**第四，SMT模式动态切换能力。**POWER10的一大优势是可以在运行时在ST/SMT2/SMT4/SMT8四种模式之间平滑切换。当工作负载只有少量高IPC线程时，POWER10自动降级到ST或SMT2模式，将全部资源集中给少数线程；当大量低IPC线程涌入时，自动升级到SMT8最大化吞吐量。这种动态适应能力使得SMT8的"最差场景"（少量线程时每线程仅64项ROB）在实际运行中很少出现——处理器会智能地调整到最优的线程模式。Intel的HT只有开/关两种选择，灵活性远不如POWER。

硬件描述 4 — POWER10 SMT8的资源分区策略详解

POWER10在不同资源上采用了精心设计的分区策略组合：

ROB：严格按活跃线程数等分——SMT8时每线程64项，SMT4时128项，SMT2时256项，ST时512项。这种动态分区需要可重配置的ROB指针逻辑——当从SMT8切换到SMT4时，4个线程的ROB边界从64/64/64/64/64/64/64/64重组为128/128/128/128，已有的指令条目需要逻辑重映射。
发射队列：完全共享，但每线程有最大占用上限（不超过总容量的50%），防止单个线程独占。上限随活跃线程数动态调整——SMT8时上限为 $\frac{1}{2}$ ，SMT2时上限为 $\frac{3}{4}$ 。
L1 D-Cache（32KB）：完全共享，依靠LRU替换策略自然平衡。8个线程竞争32KB Cache确实会导致较高的miss率，但POWER10的大容量L2（2MB）可以快速补位。
Store Buffer：混合分区——每线程保证最低4 $\sim$ 6项，剩余项动态共享。总容量约64项，SMT8时每线程保证4项是刚够的——POWER ISA的弱序模型允许store在Buffer中停留较短的时间（不需要等待全局可见性），使得4项的保证配额在大多数场景下足够。
分支预测器：完全共享BTB和方向预测表。每线程维护独立的GHR和RAS。POWER ISA的分支密度比x86低（RISC指令集中分支指令比例约12% vs x86的约18%），使得预测器的线程间别名压力相对较小。

POWER10的SMT模式对单线程性能和吞吐量的影响

POWER10在不同SMT模式下的性能特征可以用以下专家洞察来总结：

设计提示

IBM POWER10的SMT设计揭示了一个深刻的微架构权衡：面积效率vs时间效率。将一个核心的ROB从512项分区为8 $\times$ 64项，每个线程的乱序执行能力骤降（64项的指令窗口甚至不足以覆盖一次L3 miss），但8个线程共同产生的吞吐量可以高达近 $8.0$ IPC——这是该核心在单线程下的约 $2\times$ 。关键洞察是：在企业工作负载中，大部分延迟不来自指令窗口不足，而来自I/O等待、锁竞争和GC暂停。SMT8的价值不在于让每个线程更快（事实上每线程更慢了），而在于让核心在某些线程等待时仍有其他线程的有用工作可做——这是SMT设计的第一性原理：将空闲的执行周期转化为有用的工作。

Apple和ARM不采用SMT的原因

并非所有高性能处理器都采用SMT。苹果公司的M系列处理器（M1/M2/M3/M4）以及ARM的多款Cortex-X系列高性能核心都不支持SMT。这一决策并非技术疏忽，而是基于多方面的设计权衡。

苹果不采用SMT的原因

核心已经足够宽：Apple的Firestorm（M1 P-core）和后续的Avalanche、Everest核心拥有8-wide的解码、超过600项的ROB、以及超宽的执行引擎（13+个执行端口）。在如此宽的核心中，单线程IPC已经很高（SPEC CPU2017中约6.0+的IPC），执行资源的利用率也相对较高。SMT的核心价值——填充空闲的执行槽位——在高IPC核心中的价值降低了。
SMT对能效的影响：Apple的M系列处理器主要面向移动和笔记本市场，能效（性能/功耗比）是首要设计目标。SMT增加了核心面积和功耗（额外的寄存器文件、映射表、控制逻辑），但在单线程负载下（移动设备的典型使用场景）提供的收益为零。Apple选择将这些晶体管预算用于加宽核心或增加核心数量。
安全考量：SMT带来的侧信道攻击风险（如Spectre、PortSmash、TLBleed等）对Apple而言是一个显著的负面因素。Apple设备运行的是高度集成的生态系统，安全性至关重要。避免SMT从根本上消除了一大类硬件侧信道攻击面。
大小核架构的替代：Apple采用大小核（big.LITTLE式）架构，通过E-core（效率核心）来提供额外的吞吐量。在多线程工作负载下，操作系统将线程调度到E-core上，而不是在P-core上通过SMT运行多个线程。这种方法的吞吐量可能略低于P-core SMT，但能效更高。

ARM不在Cortex-X系列中采用SMT的原因

ARM的Cortex-X系列（X1、X2、X3、X4）是面向旗舰智能手机的高性能核心，同样不支持SMT。其原因与Apple类似：

移动场景的特殊性：智能手机的典型使用模式是突发性的单线程任务（UI渲染、App启动），而非持续的多线程吞吐量。SMT在这种使用模式下几乎没有收益。
核心面积预算：Cortex-X系列需要在有限的面积和功耗预算内实现最高的单线程性能。SMT的额外面积更适合用于加大缓存、加宽执行引擎或增加乱序窗口深度。
DynamIQ的灵活性：ARM的DynamIQ架构支持灵活的大小核组合（如1 $\times$ X4 + 3 $\times$ A720 + 4 $\times$ A520），通过多种核心类型的组合来满足不同的性能和吞吐量需求。
高频率短流水线的设计取向：ARM Cortex-X系列追求高频率（3.4 GHz+），流水线较深（约13 $\sim$ 15级）。在这种设计中，分支预测失败的惩罚已经很高，SMT模式下预测器共享导致的精度下降会进一步放大这种惩罚。ARM选择将预测器的全部容量用于单线程，最大化预测精度。

ARM Neoverse V系列的SMT考量

值得注意的是，ARM在服务器端的Neoverse V系列中也没有采用SMT——尽管服务器工作负载通常对SMT最有利。ARM的理由是Neoverse V设计通过大量核心（128 $\sim$ 192核/芯片）来提供吞吐量，每核心保持最高的单线程性能和最佳的能效比。ARM认为，在相同的芯片面积下，更多的无SMT核心（每核心面积更小）比更少的SMT核心能提供更高的总吞吐量——特别是考虑到ARM核心相比x86核心面积更小、功耗更低，增加核心数量的边际成本较低。

然而，ARM在其技术路线图中保留了未来引入SMT的可能性。如果未来的工作负载特征（如更高的线程过量订阅比率、更深的缓存层次导致更长的miss延迟）使得SMT的收益-代价比改善，ARM可能会在Neoverse系列中引入SMT2或SMT4。

性能分析 11 — SMT vs 多核：面积效率的分析

考虑两种提供多线程吞吐量的策略：

方案A：1个大核心 + SMT2，面积为 $1.15A$ （SMT增加15%面积）
方案B：1个大核心 + 1个小核心，面积为 $A + 0.3A = 1.3A$ （小核心面积约为大核心的30%）

假设大核心的单线程IPC为4.0，小核心的IPC为1.5：

方案A在双线程下：总吞吐量 $\approx 4.0 \times 1.3 = 5.2$ （SMT提升30%吞吐量），面积1.15A，面积效率 $= 5.2 / 1.15 = 4.52$
方案B在双线程下：总吞吐量 $= 4.0 + 1.5 = 5.5$ ，面积1.3A，面积效率 $= 5.5 / 1.3 = 4.23$

两种方案的面积效率相近，但方案B没有SMT的安全风险和线程间干扰。如果小核心采用更激进的面积优化（面积降至0.2A），方案B的面积效率将超过方案A。这解释了Apple和ARM选择大小核而非SMT的经济理性。

然而，需要注意的是，不采用SMT并非在所有场景下都是最优选择。在服务器工作负载中——大量并发线程、每个线程的IPC不高、内存延迟是主要瓶颈——SMT（尤其是IBM式的SMT4/SMT8）仍然是提高核心利用率的最有效手段。ARM在其面向服务器的Neoverse系列中曾在部分设计中考虑过SMT，但截至目前（2025年）主流的Neoverse V2/V3仍不支持SMT。

Apple不用SMT的深层工程分析

Apple不采用SMT的决策值得更深入的分析，因为它反映了一种与传统x86处理器截然不同的设计哲学。

**（1）超宽核心的发射槽位利用率分析。**Apple Firestorm/Avalanche/Everest核心的解码宽度为8-wide，执行端口超过13个。在SPEC CPU 2017等基准测试上，这些核心的IPC已经达到6.0+——意味着在8个发射槽位中，平均每周期有6个被有效利用，空闲率仅约25%。相比之下，Intel Skylake的6-wide核心平均IPC约3.5，空闲率约42%。空闲率越低，SMT能够"填充"的空间越小，边际收益越低。

更重要的是，Apple核心的空闲槽位主要来自两种原因：（a）取指/解码带宽限制——某些周期取指器未能提供足够的指令；（b）长延迟数据依赖——cache miss导致的指令等待。对于原因(a)，SMT可能帮助有限，因为SMT线程同样需要竞争取指带宽。对于原因(b)，Apple选择了另一种方案——超大的L1 cache（192 KB I-Cache + 128 KB D-Cache）和共享的12 MB L2 cache，从根源上减少cache miss的频率，而非用SMT来填充miss导致的空闲周期。

**（2）能效分析：SMT的边际功耗。**Apple处理器的设计核心是每瓦性能。添加SMT需要以下额外硬件：

额外的RAT和PC：约占核心面积的2% $\sim$ 3%
扩大的PRF（需要更多物理寄存器）：约增加核心面积5% $\sim$ 8%
扩大的ROB（需要更深以在分区后仍有足够的单线程窗口）：约增加3% $\sim$ 5%
线程仲裁逻辑和线程ID追踪逻辑：约增加1% $\sim$ 2%

总计约增加11% $\sim$ 18%的核心面积，对应约8% $\sim$ 15%的额外功耗（考虑动态功耗和漏电流的增加）。在SMT被禁用的场景（即单线程执行时），这些额外的硬件仍然消耗漏电流功耗——这对于电池供电的移动设备来说是不可接受的净损失。Apple计算了在其目标工作负载组合中（80%的时间单线程或轻多线程，20%的时间重多线程），SMT的加权收益不足以抵消其加权功耗开销。

**（3）大小核架构作为SMT的替代方案。**Apple的设计哲学是用E-core集群替代SMT来提供多线程吞吐量。这种替代方案的优势在于：

E-core可以被完全关闭（power gate），在不需要多线程性能时功耗降到接近零
E-core和P-core的工作集不共享cache，不存在线程间cache干扰
E-core提供的是真正独立的执行资源，不存在SMT中的端口竞争和ROB分区问题
E-core不存在SMT相关的安全侧信道风险

**（4）软件生态系统的考量。**Apple的macOS/iOS软件栈高度优化了Grand Central Dispatch（GCD）多线程框架，使得应用程序的线程数量通常与物理核心数匹配。这意味着Apple系统上的线程过量订阅（oversubscription）程度远低于Windows/Linux上的通用工作负载。在没有线程过量订阅的情况下，SMT的收益接近于零——因为每个物理核心上最多只运行一个线程。

案例研究 4 — Apple M4 vs 假设的"M4+SMT"方案

假设Apple在M4 P-core中添加2线程SMT，估算面积和能效的影响：

M4实际方案：4个P-core（无SMT）+ 6个E-core = 10个物理线程。

P-core面积： $\sim$ 4.0 mm $^2$ /核（3nm），4核总计16.0 mm $^2$
E-core面积： $\sim$ 1.2 mm $^2$ /核，6核总计7.2 mm $^2$
CPU总面积： $\sim$ 23.2 mm $^2$
最大多线程吞吐量（归一化）： $4 \times 1.0 + 6 \times 0.35 = 6.1\times$

假设"M4+SMT"方案：4个P-core（SMT2）+ 4个E-core = 12个逻辑线程。

P-core面积（+15% SMT开销）： $\sim$ 4.6 mm $^2$ /核，4核总计18.4 mm $^2$
E-core面积（减少2个E-core以保持面积预算）： $\sim$ 1.2 mm $^2$ /核，4核总计4.8 mm $^2$
CPU总面积： $\sim$ 23.2 mm $^2$ （相同面积预算）
SMT2的P-core吞吐量提升约25%： $4 \times 1.25 + 4 \times 0.35 = 6.4\times$
但P-core单线程性能因SMT开销降低约3% $\sim$ 5%
P-core在单线程模式下的额外漏电流功耗增加约10%

在相同面积预算下，"M4+SMT"方案的多线程吞吐量略高（6.4 vs 6.1），但单线程功耗更高（漏电增加10%），且引入了安全攻击面。对于Apple的产品定位（注重单线程性能和能效），实际方案更优。

设计提示

SMT与大小核架构的选择并非非此即彼。在理论上，一个处理器可以同时采用两种技术——大核心支持SMT，小核心不支持SMT。实际上Intel在Alder Lake和Raptor Lake中正是这样做的（P-core支持HT，E-core不支持）。这种混合方案在设计空间中提供了最大的灵活性，但也增加了操作系统调度器的复杂性——调度器需要理解每个逻辑处理器是来自P-core的SMT线程还是独立的E-core。Intel为此设计了Thread Director硬件辅助调度机制，在第 46.0 章中将详细讨论。

SMT与功耗管理的交互

SMT对处理器的功耗特性有着复杂的影响。一方面，SMT通过提高执行单元的利用率增加了动态功耗；另一方面，SMT的面积开销增加了漏电流（静态功耗）。理解这些交互对于移动和服务器处理器的设计都至关重要。

SMT的功耗模型

在SMT模式下，处理器的功耗可以分解为以下几个部分：

P_{\text{SMT}} = P_{\text{base}} + P_{\text{dynamic}}(\text{IPC}_{\text{total}}) + P_{\text{static}}(\text{area}_{\text{SMT}})

其中 $P_{\text{base}}$ 是核心的基础功耗（时钟树、电源网格等）， $P_{\text{dynamic}}$ 是与执行活动成正比的动态功耗， $P_{\text{static}}$ 是面积相关的漏电流功耗。

动态功耗的增加：在SMT模式下，由于执行单元的利用率更高，动态功耗增加。如果SMT使总IPC从4.0增加到5.2（30%提升），动态功耗也大致增加30%。但这种功耗增加是"有用的"——它对应于更多的实际工作完成。

能效的变化：SMT的能效（性能/功耗比）取决于吞吐量增加的比例是否超过功耗增加的比例。在典型的2线程SMT中：

吞吐量增加： $\sim$ 30%
总功耗增加： $\sim$ 20% $\sim$ 25%（动态功耗增加 + SMT硬件的漏电流）
能效变化： $1.30 / 1.25 = 1.04$ ——约4%的能效提升

这意味着在多线程满载场景下，SMT的能效略优于不使用SMT——但优势非常小。如果SMT的吞吐量增益降低（如两个线程都是cache-heavy的），功耗增加可能超过吞吐量增加，导致能效下降。

SMT模式下的漏电流分析：SMT增加的硬件结构（额外的RAT、扩大的PRF等）即使在单线程模式下也持续消耗漏电流。在7nm/5nm工艺节点下，漏电流占总功耗的比例约为20% $\sim$ 35%。假设SMT增加了12%的核心面积，则SMT的额外漏电流约为核心总漏电流的12%，占总功耗的约 $12\% \times 30\% = 3.6\%$ 。对于一个TDP为15 W的笔记本处理器核心（每核约3 W），这意味着约100 mW的额外漏电——在电池供电的设备上，这不是一个可忽略的数字。

这也解释了为什么Apple在其M系列芯片中不采用SMT——对于面向MacBook和iPad的处理器，即使100 mW的额外漏电也会影响续航时间。Apple选择将这些晶体管预算用于更大的L1 cache和更深的ROB，获得确定性的单线程IPC提升，而非不确定的多线程吞吐量增益。

Turbo Boost的交互：现代处理器的Turbo Boost（频率提升）机制与SMT有复杂的交互。在Intel处理器中，Turbo Boost的最大频率取决于活跃核心数和线程数。当HT被启用且两个线程都活跃时，Turbo Boost的最大频率通常低于单线程模式的最大频率（因为功耗预算需要在更多的活跃逻辑之间分配）。例如，在Intel Core i9-13900K中：

单线程（1核1线程）Turbo Boost：5.8 GHz
单核双线程（HT）Turbo Boost：约5.5 GHz
全核双线程Turbo Boost：约5.2 GHz

这种频率降低部分抵消了SMT的吞吐量增益——SMT的实际吞吐量增益不是30%，而是 $1.30 \times (5.5/5.8) \approx 23\%$ （考虑频率降低后）。

案例研究 5 — SMT能效在不同工作负载下的变化

以Intel Core i7-12700K（Alder Lake，8P+4E）为例，测量P-core在不同工作负载下启用/禁用HT时的能效变化：

工作负载	HT关闭(W/perf)	HT开启(W/perf)	能效变化
Cinebench R23 (多线程)	95W / 12800	110W / 15600	+5.8%
7-Zip压缩	90W / 58000	105W / 72000	+3.4%
Handbrake视频编码	92W / 45fps	108W / 52fps	–1.2%
SPEC CPU 2017 INT (多拷贝)	88W / 620	102W / 740	+2.6%
内存密集型数据库	85W / 1.2M TPS	95W / 1.7M TPS	+26.8%

从上表可以看出，SMT的能效增益在不同工作负载之间差异巨大。在内存密集型数据库工作负载中，SMT的能效提升高达27%——因为cache miss期间的空闲功耗被另一个线程的有用工作所替代。但在视频编码等计算密集型工作负载中，SMT甚至可能导致能效下降——因为两个线程竞争cache和执行端口，导致频率降低和miss率上升。

动态SMT控制与功耗管理的结合：最先进的SMT实现支持根据功耗和温度条件动态调整SMT策略。例如，IBM POWER10的动态线程模式切换不仅受工作负载特征驱动，还受温度传感器和功耗监控器的反馈影响：当芯片温度接近限制时，处理器可以自动从SMT8降级到SMT4或SMT2，通过减少活跃线程数来降低功耗和发热。这种动态调整在每秒可以发生多次，用户和操作系统通常不会感知到。

SMT的性能特征化

在实际系统中，SMT的性能表现取决于工作负载的特征。本节系统地分析影响SMT性能的关键因素，并提供量化的分析框架。

SMT加速比与线程间干扰

SMT的性能可以从两个角度衡量：吞吐量加速比（总吞吐量相对于单线程的提升）和单线程性能回退（每个线程相对于独占模式的性能损失）。

设单线程独占模式下线程 $t$ 的IPC为 $I_t^{\text{alone}}$ ，SMT模式下线程 $t$ 的IPC为 $I_t^{\text{smt}}$ 。则：

\text{吞吐量加速比} = \frac{\sum_t I_t^{\text{smt}}}{\max_t I_t^{\text{alone}}}

\text{线程$t$的性能回退} = 1 - \frac{I_t^{\text{smt}}}{I_t^{\text{alone}}}

理想的SMT实现应该使吞吐量加速比尽可能高，同时使每个线程的性能回退尽可能小。但这两个目标之间存在固有的张力——更高的吞吐量通常伴随着更大的单线程性能回退。

在典型的2线程SMT处理器（如Intel Skylake/Golden Cove）中，不同工作负载组合下的性能表现差异很大：

两个计算密集型线程（如两个SPEC CPU INT基准）：吞吐量提升约15% $\sim$ 25%，每线程回退约10% $\sim$ 15%。两个线程竞争执行端口和cache容量。
一个计算密集型+一个内存密集型：吞吐量提升约30% $\sim$ 40%。这是SMT最有利的场景——内存密集型线程的cache miss停顿期间，计算密集型线程可以使用空闲的执行资源。
两个内存密集型线程：吞吐量提升约20% $\sim$ 30%，但两个线程的cache miss率都可能上升（由于cache容量竞争），使得每线程的性能回退可能达到15% $\sim$ 25%。
一个高IPC线程+一个低IPC线程：不对称的组合。高IPC线程的回退较大（因为低IPC线程占用的ROB/RS资源虽少但可能因长延迟事件而"锁定"），低IPC线程的回退较小。

工作负载的SMT友好度分析

工作负载的"SMT友好度"可以通过以下几个维度来评估：

**（1）资源利用率互补性。**如果两个线程使用不同类型的执行端口（如一个主要用整数ALU，另一个主要用浮点/SIMD单元），它们在SMT模式下的端口竞争很小，吞吐量提升显著。反之，如果两个线程都密集使用同一类型的端口，竞争会限制吞吐量增益。

**（2）Cache足迹的可叠加性。**如果两个线程的工作集之和不超过L1/L2 cache的容量，cache共享不会导致额外的miss。如果超过cache容量，则会发生cache thrashing，两个线程的miss率都上升，可能导致净性能下降。Cache足迹的测量可以通过硬件性能计数器（如Intel的LLC_MISSES和LLC_REFERENCES事件）或软件工具（如perf和Intel VTune）在不同SMT配置下对比获得。

一个有用的经验法则是：如果线程A的L1 D-Cache工作集为 $W_A$ ，线程B的为 $W_B$ ，L1 D-Cache容量为 $C_{\text{L1}}$ ，则：

$W_A + W_B < 0.8 \times C_{\text{L1}}$ ：cache共享安全，SMT收益正面
$0.8 \times C_{\text{L1}} < W_A + W_B < 1.5 \times C_{\text{L1}}$ ：开始出现cache争用，SMT收益受限
$W_A + W_B > 1.5 \times C_{\text{L1}}$ ：严重cache thrashing，SMT可能导致性能下降

**（3）分支预测器压力。**高分支密度的工作负载（如解释器、JIT编译代码）对分支预测器容量敏感。两个此类工作负载在SMT模式下共享预测器表，预测精度可能下降1% $\sim$ 3%——在深流水线处理器中，这转化为约2% $\sim$ 6%的IPC损失。

**（4）TLB压力。**如果两个SMT线程属于不同进程（不同的页表），它们的TLB表项互不相关。在共享TLB中，两个进程的TLB工作集之和可能超过TLB容量，导致TLB miss率上升。PCID/ASID标记虽然避免了线程切换时的TLB刷新，但不能增加TLB的有效容量。

设计提示

在数据中心和云计算环境中，VMM（虚拟机管理器）和操作系统调度器应该考虑将"SMT友好"的工作负载组合配对到同一物理核心的两个逻辑线程上。例如，将一个Web服务器线程（I/O密集型，低IPC，小cache足迹）与一个数据分析线程（计算密集型，高IPC，中等cache足迹）配对，通常比将两个Web服务器线程或两个数据分析线程配对获得更好的整体性能。Google的Borglet调度器和Microsoft的Azure Resource Manager都实现了类似的SMT感知调度策略。

SMT的安全问题

SMT的核心特征——多个线程共享物理资源——为安全攻击提供了天然的侧信道。当两个不同安全域的线程（如用户进程和内核线程，或不同用户的虚拟机线程）在同一物理核心上通过SMT同时执行时，一个线程可以通过观察共享资源的状态变化来推断另一个线程的行为，甚至窃取密钥等敏感信息。

共享资源侧信道

SMT侧信道攻击的基本原理是资源竞争推断：攻击者线程和受害者线程共享某个微架构资源（cache、TLB、分支预测器、执行端口等），攻击者通过测量自己对该资源的访问时间变化来推断受害者线程的行为。

Cache侧信道

Cache侧信道是最经典的SMT攻击向量。在SMT中，两个线程共享L1 D-Cache。攻击者可以利用以下技术：

Prime+Probe：攻击者首先用自己的数据填充整个cache（Prime），然后等待受害者执行一段时间。受害者的内存访问会逐出攻击者的某些cache line。攻击者再逐一访问自己之前填充的数据（Probe），测量每次访问的延迟。被逐出的cache line的访问延迟显著增加（cache miss），从而暴露了受害者访问了哪些cache set。
Flush+Reload：适用于攻击者和受害者共享内存页（如共享库）的场景。攻击者先用clflush指令将目标cache line刷出cache（Flush），然后等待受害者执行。如果受害者访问了该cache line，它将被重新加载到cache中。攻击者随后访问同一地址（Reload），如果命中（延迟短），说明受害者访问了该地址。

在SMT场景下，这些攻击特别有效，因为两个线程同时在同一核心上执行——攻击者可以在极短的时间窗口内（甚至逐周期地）探测受害者的行为，时间分辨率远高于在不同核心上执行的跨核攻击。

分支预测器侧信道

分支预测器的共享状态（BHT/PHT表项、BTB表项）可以被攻击者利用。如果攻击者知道受害者代码中某个分支的地址，它可以训练对应的BHT表项，然后观察受害者的执行是否改变了该表项的状态，从而推断受害者分支的方向（taken或not-taken）。

执行端口侧信道

当两个SMT线程竞争同一执行端口时，一个线程的指令会被延迟执行。攻击者可以通过精确测量自己指令的执行时间来检测另一个线程是否在使用特定类型的执行端口（如端口5上的向量移位单元）。

TLB侧信道

TLB表项的共享使得攻击者可以通过TLB miss的时间特征推断受害者的内存访问模式。

SMT共享资源侧信道攻击示意。攻击者线程通过观察共享资源（Cache、分支预测器、TLB、执行端口等）的状态变化来推断受害者线程的行为。

PortSmash和TLBleed攻击

PortSmash和TLBleed是两种针对SMT共享资源的具体攻击实例，它们证明了SMT侧信道不仅是理论上的威胁，而且可以在真实硬件上窃取密钥级别的敏感信息。

PortSmash攻击（2018年）

PortSmash由Aldaya等人提出，利用了SMT线程之间的执行端口竞争作为侧信道。

PortSmash的攻击原理如下：在Intel处理器中，不同的执行端口服务于不同类型的操作。例如，在Skylake中，端口0和端口1可以执行向量乘法，端口5可以执行向量移位。当受害者线程执行密码学运算（如OpenSSL的椭圆曲线数字签名算法ECDSA）时，某些密钥相关的分支会导致不同的指令序列被执行——一个分支路径可能包含大量的向量乘法（使用端口0/1），另一个分支路径可能包含更多的向量移位（使用端口5）。

攻击者线程持续地执行占用特定端口的指令（如大量的向量乘法），并精确测量每条指令的执行延迟。当受害者线程也在使用相同的端口时，攻击者的指令会因为端口竞争而被延迟发射——这种延迟的模式直接反映了受害者线程使用该端口的时间模式，进而暴露了密钥相关的分支方向。

Aldaya等人成功地使用PortSmash从运行在同一核心的另一个SMT线程中恢复了OpenSSL的ECDSA P-384私钥。攻击需要大约30,000次签名操作的观测，总时间约几秒钟。

硬件描述 5 — PortSmash的执行端口探测机制

PortSmash攻击的核心技术是端口竞争计时（Port Contention Timing）：

攻击者线程构造一个指令序列，所有指令都被发射到目标端口（如端口1）。
使用rdtsc或rdtscp指令精确测量每条指令的执行开始到完成的时间。
在无竞争时（受害者线程不使用端口1），攻击者的指令以1条/周期的速率执行。
当受害者线程也在使用端口1时，攻击者的指令被延迟——两个线程的就绪指令轮流获得端口1的使用权，攻击者的执行速率降至约0.5条/周期。
攻击者通过检测自己指令的执行速率变化（1 $\to$ 0.5），推断受害者线程当前是否在使用端口1。
将端口使用的时间序列与受害者密码算法的已知控制流结构关联，恢复密钥比特。

防御措施包括：（1）密码库使用常数时间实现（constant-time implementation），使密钥相关分支不影响执行端口的使用模式；（2）操作系统层面的Core Scheduling，避免不同安全域的线程在同一核心上SMT执行。

TLBleed攻击（2018年）

TLBleed由Gras等人提出，利用了SMT线程之间的TLB共享作为侧信道。

TLBleed的攻击原理建立在以下观察之上：在SMT处理器中，两个线程共享同一个L1 DTLB和L2 TLB。当受害者线程访问的内存页面的TLB表项与攻击者线程的TLB表项映射到同一个TLB set时，受害者的访问会逐出攻击者的TLB表项——攻击者随后访问同一虚拟地址时将经历TLB miss，延迟显著增加。

通过精心构造内存访问模式（Prime+Probe在TLB上的变体），攻击者可以确定受害者在特定时间窗口内访问了哪些内存页面。如果受害者的密码算法根据密钥值访问不同的内存页面（如使用查找表的AES实现），攻击者可以从TLB访问模式中恢复密钥。

Gras等人使用TLBleed成功恢复了libgcrypt的EdDSA签名密钥。他们还使用机器学习技术（神经网络分类器）来处理TLB侧信道中的噪声信号，显著提高了密钥恢复的成功率。

TLBleed攻击的关键技术挑战在于TLB的set数量较少（典型的L1 DTLB仅有64 $\sim$ 128个表项），每个set提供的信息量有限。攻击者需要在很短的时间窗口内（通常是密码运算的一个标量乘步骤，约数千周期）完成Prime和Probe操作，并从有限的TLB set信息中推断出受害者访问的内存页面。Gras等人使用深度神经网络来学习TLB竞争模式与密钥比特之间的关联，达到了在约98%的概率下正确恢复单个密钥比特的精度。

SMT侧信道攻击的时间分辨率优势

SMT侧信道攻击相比跨核攻击有一个根本性的优势：时间分辨率。在跨核攻击中，攻击者通过共享的L3 cache进行探测，每次Prime+Probe操作需要遍历整个L3 cache的目标set（数百次内存访问），时间分辨率通常在数万到数十万周期级别。在SMT攻击中，攻击者和受害者共享L1 cache，Prime+Probe操作仅需遍历L1的一个set（4 $\sim$ 8路），时间分辨率可以达到数十到数百周期级别——这使得攻击者可以观察到受害者执行中更细粒度的行为变化，极大地提高了攻击的信息泄露速率。

其他SMT相关的攻击

除了PortSmash和TLBleed，SMT还被以下攻击所利用：

CacheBleed（2016年）：利用cache bank竞争作为侧信道，在SMT线程之间泄露RSA密钥。
Spectre v1/v2的SMT变体：Spectre攻击在SMT环境中更加容易实施，因为攻击者和受害者共享分支预测器——攻击者可以直接训练受害者线程将使用的BTB/BHT表项，无需等待线程切换或跨核的预测器污染。SMT使得Spectre v2（Branch Target Injection）的攻击窗口极为精确——攻击者可以在受害者执行关键分支的前几个周期内完成BTB投毒。
MDS攻击（Microarchitectural Data Sampling，2019年）：包括RIDL、Fallout和ZombieLoad，这些攻击利用微架构缓冲区（如Line Fill Buffer、Store Buffer）中残留的数据。在SMT环境中，这些缓冲区被两个线程共享，使得攻击者可以读取受害者线程的内存数据——这不仅仅是侧信道泄露（timing information），而是直接数据泄露。

MDS攻击的详细机制

MDS攻击族群值得更详细的分析，因为它们代表了SMT安全威胁的最严重形式——直接的数据泄露，而非仅仅是时间侧信道。

ZombieLoad利用了Intel处理器中Line Fill Buffer（LFB）的数据泄露。LFB是连接L1 cache和L2 cache之间的缓冲区，用于暂存正在从L2加载到L1的cache line数据。在SMT模式下，LFB被两个线程共享。ZombieLoad的攻击步骤如下：

攻击者线程执行一条load指令，该load指令触发微架构异常（如访问一个将被取消的推测路径上的无效地址）。
在异常处理之前的短暂窗口内，load的数据路径从LFB中读取了残留数据——这些数据可能来自受害者线程之前的L1 miss操作。
攻击者线程使用这些残留数据作为后续推测执行的输入（如Spectre风格的数组索引），将数据编码到cache状态中。
异常处理取消了推测路径上的体系结构状态修改，但cache状态的变化已经发生。
攻击者通过cache侧信道（如Flush+Reload）恢复编码在cache中的数据。

RIDL（Rogue In-Flight Data Load）利用了类似的机制，但针对的是更多种类的内部缓冲区——包括Load Port Buffer和Store Buffer。RIDL证明了Intel处理器中多个微架构缓冲区都存在跨线程的数据泄露问题。

Fallout专门针对Store Buffer的数据泄露。当一个线程的store操作在Store Buffer中等待提交时，另一个线程可以通过特定的load操作"读取"Store Buffer中的残留数据。

MDS攻击的关键特征是它们不需要攻击者和受害者访问同一内存地址——攻击者可以读取受害者任意内存操作的数据残留。这使得MDS比传统的cache侧信道攻击（只能推断地址模式）更加危险。Intel在2019年发布了微码更新，在安全域切换时清洗相关缓冲区（通过VERW指令），但这增加了约3% $\sim$ 8%的系统调用开销。

硬件描述 6 — MDS缓解的硬件代价

Intel的MDS缓解措施在硬件和性能上的代价可以细分如下：

VERW缓冲区清洗：在每次从用户态进入内核态（系统调用入口）、从VM进入Hypervisor（VM Exit）时，执行VERW指令。VERW触发微码序列，将LFB和Store Buffer中的所有残留数据覆写为零。每次VERW的延迟约为50 $\sim$ 100个周期。
上下文切换清洗：当操作系统将CPU从一个安全域的线程切换到另一个安全域的线程时（通过Core Scheduling或常规调度），需要执行缓冲区清洗。
性能影响：对于系统调用密集型的工作负载（如数据库、网络服务器），MDS缓解的性能开销为5% $\sim$ 8%；对于计算密集型工作负载，开销不到1%。
后续硬件修复：从Ice Lake（第10代酷睿）开始，Intel在硬件层面修复了部分MDS漏洞——LFB在内部实现了线程隔离，减少了跨线程数据泄露的攻击面。但完全的硬件修复直到更新的微架构才逐步完成。

设计提示

SMT安全问题的根源在于微架构状态的共享。任何被两个线程共享的、具有有限容量的微架构结构——无论是cache、TLB、分支预测器还是执行端口——都可能成为侧信道的载体。从安全的角度看，SMT本质上是一种将不同安全域的信息混合在同一物理基础设施中的技术，这与安全工程中的"隔离原则"相矛盾。因此，在安全敏感的环境中（如云计算、密码学运算），是否启用SMT是一个需要仔细权衡的决策。

Core Scheduling防御

针对SMT侧信道攻击，业界开发了多种软硬件防御机制。其中最根本的防御是Core Scheduling——确保不同安全域的线程不会在同一物理核心的SMT线程上同时执行。

Linux Core Scheduling

Linux内核从5.14版本开始合入了Core Scheduling功能。其核心思想是：为每个任务（task）分配一个安全cookie（security cookie），调度器保证在同一物理核心的SMT线程上同时运行的任务必须拥有相同的cookie。属于同一用户、同一容器或同一虚拟机的任务共享相同的cookie，而不同安全域的任务拥有不同的cookie。

当调度器准备在某个SMT线程上运行一个任务时，它检查该核心上另一个SMT线程正在运行的任务的cookie。如果cookie不匹配，调度器不会在该核心上运行新任务——它要么选择另一个核心，要么将另一个SMT线程上的不匹配任务迁移走。
如果某个SMT线程无法找到与另一个线程cookie匹配的任务，该线程将被强制空闲（idle），运行一个空循环。这意味着Core Scheduling可能导致SMT的吞吐量优势部分或完全丧失。

Core Scheduling的实现细节

Linux Core Scheduling的实现涉及多个调度器层次的修改：

Cookie分配：管理员通过prctl(PR_SCHED_CORE)系统调用为进程组分配安全cookie。属于同一cgroup或同一用户的进程自动共享相同的cookie。
核心级别选择：当调度器需要在某个核心的SMT线程上运行一个任务时，它首先检查该核心另一个SMT线程的当前任务cookie。如果cookie不匹配，有两个选择：（a）找另一个核心；（b）强制抢占另一个SMT线程上的不匹配任务。
强制空闲：如果无法找到cookie匹配的任务对，核心的一个SMT线程将被强制空闲——运行一个特殊的idle线程。这意味着该核心实际上退化为单线程模式，SMT的吞吐量优势完全丧失。
性能开销：Core Scheduling的调度决策比标准CFS调度器更复杂——需要在核心级别而非线程级别做出匹配决策。在大规模系统中（如64核128线程），匹配算法的复杂度可能导致每次调度决策增加数微秒的开销。

在实际部署中，Core Scheduling的吞吐量损失高度依赖工作负载的多样性。如果同一安全域有大量线程（如同一容器内的所有线程），cookie匹配的成功率很高，吞吐量损失仅3% $\sim$ 5%。但如果安全域很多且每个域只有少量线程（如多租户虚拟化），强制空闲的比例增加，吞吐量损失可达10% $\sim$ 20%。

完全禁用SMT

最极端但最简单的防御是完全禁用SMT。在Linux中，可以通过内核参数nosmt或在运行时通过/sys/devices/system/cpu/smt/control来禁用SMT。许多云服务提供商（如AWS、Google Cloud）在其安全敏感的计算实例中默认禁用SMT。

禁用SMT的代价是失去SMT带来的吞吐量提升（通常约20% $\sim$ 30%的多线程吞吐量损失）。对于某些对安全性要求极高的工作负载（如HSM、密钥管理服务），这个代价被认为是值得的。

然而，禁用SMT在某些场景下可能意外提升单线程性能——因为禁用SMT后，处理器可以在Turbo Boost中达到更高的频率（更低的功耗预算消耗），且所有资源（ROB、PRF、cache）完全由单线程独占。在高频交易等对延迟极其敏感的场景中，禁用SMT后的单线程延迟改善（约2% $\sim$ 5%的IPC提升加上约100 $\sim$ 200 MHz的频率提升）可能远超丢失多线程吞吐量的代价。

微码补丁与缓冲区清洗

针对MDS类攻击（RIDL、ZombieLoad、Fallout），Intel发布了微码更新，在以下时机自动清洗微架构缓冲区中的残留数据：

VM Exit：当虚拟机执行退出到hypervisor时，清洗Line Fill Buffer和Store Buffer中的数据。
上下文切换：当操作系统切换到不同安全域的任务时，清洗相关缓冲区。
用户态到内核态切换：在系统调用入口处清洗缓冲区，防止用户态代码通过MDS读取内核数据。

缓冲区清洗通过执行VERW指令来触发——这条原本用于段描述符验证的指令被微码赋予了额外的缓冲区清洗功能。在每次安全域切换时插入VERW指令的性能开销通常在3% $\sim$ 8%之间，取决于系统调用和上下文切换的频率。

硬件级别的防御

除了软件层面的调度策略，硬件也可以提供更细粒度的隔离：

Cache分区：将L1 cache按线程分区（如Intel的L1D分区），使得一个线程的cache访问不会影响另一个线程的cache内容。代价是每个线程只能使用cache容量的 $1/T$ 。
TLB隔离：使用PCID/ASID严格隔离不同线程的TLB表项，并在TLB查找中强制匹配PCID。
分支预测器分区：将分支预测器的表项按线程分区，防止线程间的预测器干扰。这在某些Intel处理器中已经实现（如Alder Lake对某些预测器结构的分区）。
执行端口随机化：对指令到执行端口的分配引入随机性，使攻击者难以通过端口竞争推断受害者的行为。
微架构缓冲区的线程标记：为LFB、Store Buffer等内部缓冲区中的每个条目添加线程ID标记，在数据读出时验证请求线程是否匹配数据所有者线程。这可以从根本上消除MDS类攻击——不匹配的读出返回零或随机数据而非真实数据。Intel从Ice Lake开始在硬件层面实现了部分缓冲区的线程隔离。

安全防御的软硬件协同

最有效的SMT安全防御通常需要软硬件的协同配合：

硬件提供隔离原语：处理器通过微码补丁和硬件修复消除直接数据泄露（MDS类），通过缓冲区标记和可选的cache/TLB分区减少侧信道泄露。
操作系统实施调度策略：通过Core Scheduling确保不同安全域的线程不在同一核心的SMT线程上同时运行，或通过完全禁用SMT来消除攻击面。
应用层使用常数时间算法：密码学库使用常数时间实现（如OpenSSL的CT模式），确保密钥相关的操作不产生可观察的时间或资源使用模式差异。
虚拟化层的隔离保证：Hypervisor在安排虚拟CPU到物理核心的映射时，确保不同租户的vCPU不共享同一物理核心的SMT线程。

这种多层次的防御策略——纵深防御（Defense in Depth）——是当前工业界应对SMT安全挑战的主流方法。单一层次的防御总是可能被新发现的漏洞突破，但多层次的组合可以将攻击的难度提高到实际不可行的程度。

案例研究 6 — 云环境中的SMT安全决策

不同云服务提供商对SMT的安全决策反映了不同的风险偏好：

Amazon AWS：默认在大多数EC2实例中启用SMT，但提供禁用SMT的选项。对于安全敏感的Nitro Enclaves实例，SMT被默认禁用。AWS建议运行密码学工作负载的客户禁用SMT。
Google Cloud：在2019年MDS漏洞披露后，Google对Compute Engine实例应用了微码补丁并提供了禁用SMT的选项。Google的内部基础设施使用Core Scheduling来隔离不同租户的虚拟机。
Microsoft Azure：在Azure Confidential Computing实例中禁用SMT，在标准实例中保持SMT启用。
OpenBSD：从2018年开始，OpenBSD在支持的平台上默认禁用SMT（HT），成为第一个做出这一决策的主流操作系统。OpenBSD项目负责人Theo de Raadt的观点是："SMT从根本上与安全不兼容。"

这些不同的决策反映了安全性与性能之间的经典权衡。在高密度的云环境中——同一物理核心上可能同时运行来自不同客户的虚拟机线程——SMT的侧信道风险尤为突出。

未来方向：安全的SMT

学术界正在探索多种方向来构建"安全的SMT"——在保留SMT吞吐量优势的同时消除侧信道：

完全分区的微架构：将所有共享资源（cache、TLB、分支预测器、执行端口）按线程严格分区。这消除了所有已知的SMT侧信道，但也消除了动态资源共享的灵活性——实际上退化为在同一die上的两个独立核心。
时间分区（Temporal Partitioning）：在不同时间窗口中交替执行不同安全域的线程，并在切换时刷新所有微架构状态（cache、TLB、预测器）。这类似于粗粒度多线程，但以安全为目的而非性能。
噪声注入：在共享资源的访问模式中引入随机噪声，使攻击者难以从观测中提取有意义的信号。例如，在空闲的SMT线程上运行随机的"噪声线程"，混淆cache和执行端口的竞争模式。
常数时间硬件：设计共享资源使其访问时间不依赖于内容——例如，cache的访问时间不因hit/miss而变化（通过Always-miss或Oblivious RAM技术）。这在理论上是可行的，但性能开销极大。学术界提出的ORAM（Oblivious RAM）方案可以完全消除cache侧信道，但其访问延迟增加约10 $\sim$ 100倍，在商用处理器中不实用。一种更可行的变体是时间填充（Timing Padding）——将所有cache访问的返回时间统一填充到固定延迟（如L1 miss延迟），消除了hit/miss的时间差异，但代价是所有hit也承受miss级别的延迟。
选择性共享（Selective Sharing）：根据安全策略动态切换资源的共享模式。当两个SMT线程属于同一安全域时，允许完全共享以获得最大性能；当属于不同安全域时，自动切换到分区模式。这需要硬件支持的安全域标识和快速的分区/共享切换机制。
硬件信息流追踪（Hardware Information Flow Tracking，HIFT）：在硬件中为每个数据值附加安全标签，追踪数据在微架构结构中的流动。当检测到跨安全域的信息流动（如受害者的数据影响了攻击者可观察的微架构状态）时，硬件主动清除该信息流。HIFT的理论基础完善但硬件开销极大（每个数据位需要一个额外的标签位），目前仅存在于学术原型中。

设计权衡 2 — SMT的性能-安全权衡

SMT的性能-安全权衡可以概括为以下连续谱：

防御方案	多线程吞吐量损失	安全等级
无防御（完全共享）	0%	低
微码补丁（MDS缓解）	3% $\sim$ 8%	中
Core Scheduling	10% $\sim$ 20%	中高
L1D Cache分区	5% $\sim$ 15%	中
完全禁用SMT	20% $\sim$ 30%	高
完全资源分区	$\approx$ 禁用SMT	最高

在实际系统中，最常用的策略是微码补丁 + Core Scheduling的组合——微码补丁消除了MDS等直接数据泄露漏洞，Core Scheduling消除了跨安全域的侧信道。这种组合的性能开销约为5% $\sim$ 15%，在大多数部署场景中是可接受的。

SMT的设计空间探索

本节综合前面的讨论，从更高层次审视SMT的设计空间——包括线程数量的选择、SMT与其他并行技术的组合、以及SMT在不同市场定位下的最优配置。

SMT的验证挑战

SMT的实现引入了大量的微架构交互场景，使得处理器的验证复杂度显著增加。SMT相关的Bug在工业界造成了多次重大问题，理解这些挑战有助于设计者在初始设计阶段就考虑验证的可行性。

状态空间爆炸：在单线程处理器中，每个时钟周期的微架构状态由单一线程的PC、寄存器状态和流水线内容决定。在2线程SMT处理器中，状态空间是两个线程状态的笛卡尔积——理论上增加了一个指数因子。例如，如果单线程的ROB在某个时刻可能处于 $S$ 种不同的状态，则2线程SMT的ROB可能处于 $S^2$ 种状态（考虑两个线程的指令混合排列）。

资源竞争的边界条件：当多个线程同时耗尽某种共享资源（如PRF空闲列表为空、发射队列满、Store Buffer满）时，处理器必须正确地处理所有可能的优先级和回退场景。这些边界条件在单线程测试中几乎不会触发，需要专门的多线程测试向量来覆盖。

原子性和可见性的验证：在SMT模式下，两个线程共享L1 cache和store buffer。验证所有可能的load-store交互顺序是否符合内存一致性模型（如x86的TSO）是一个极其复杂的任务。Intel的Pentium 4在HT初期曾遭遇过与store buffer跨线程可见性相关的Bug，导致某些多线程程序在极罕见的竞争条件下产生错误结果。

安全属性的形式化验证：MDS等安全漏洞的发现促使业界探索对SMT安全属性的形式化验证——证明跨线程的信息泄露不超过某个可接受的阈值。但微架构状态空间的巨大使得完全的形式化验证在当前技术条件下不可行，需要依赖模拟、随机测试和有界模型检查的组合。

硬件描述 7 — SMT验证的工业实践

Intel和AMD在SMT验证中采用的主要方法论包括：

约束随机测试（Constrained Random Testing）：生成随机的多线程程序对，强制两个线程同时访问共享地址和竞争资源。每个测试向量运行数万到数十万个周期，验证体系结构可见状态的正确性。
SMT特有的检查器（SMT-specific Checkers）：在RTL仿真中添加专门的assertion，检查SMT特有的属性——如"线程A的store不应通过store buffer被线程B的load观察到"、"两个线程的ROB提交指针应该独立递增"等。
线程交错压力测试：专门设计的测试在两个线程之间创建极端的资源竞争场景——如一个线程快速产生大量指令填满ROB，另一个线程同时尝试执行大量的原子操作。
安全漏洞回归测试：将所有已知的SMT安全漏洞（MDS、PortSmash、TLBleed等）的攻击POC转化为自动化测试用例，确保每次微架构修改后这些漏洞不会复现。

据估计，SMT支持使处理器的验证工作量增加了约30% $\sim$ 50%，是SMT面积开销（5% $\sim$ 15%）之外的另一个重要设计代价。这也是Intel在Arrow Lake中取消P-core HT的原因之一——减少验证负担。

SMT线程数量的权衡

SMT的线程数量 $T$ 是最根本的设计参数。增加 $T$ 的收益和代价可以归纳如下：

收益的边际递减：从 $T=1$ 到 $T=2$ 的吞吐量提升通常约为30%；从 $T=2$ 到 $T=4$ 的额外提升约为15% $\sim$ 20%；从 $T=4$ 到 $T=8$ 的额外提升约为10% $\sim$ 15%。收益递减的原因是：（1）更多的线程竞争有限的执行端口，端口竞争损失随 $T$ 增加而加重；（2）cache和TLB的有效容量按 $1/T$ 缩减，miss率上升；（3）每线程的ROB窗口缩小，乱序执行能力下降。

面积开销的增长：每增加一个线程需要复制一套体系结构状态（PC、RAT、GHR等），面积开销大致为线性增长。从 $T=2$ 到 $T=8$ ，SMT相关的面积开销从约10%增长到约25% $\sim$ 30%。

单线程性能的持续下降：在 $T=2$ 的静态分区中，每线程获得50%的ROB；在 $T=4$ 中为25%；在 $T=8$ 中仅为12.5%。对于单线程性能敏感的工作负载，高 $T$ 值会导致不可接受的性能回退。

性能分析 12 — SMT线程数量与性能的关系

基于公开的学术模拟和工业数据，不同SMT线程数量的典型性能特征：

指标	SMT2	SMT4	SMT8	SMT16
吞吐量增益（多线程满载）	30%	50%	65%	70% $\sim$ 75%
单线程性能回退（HT活跃时）	5% $\sim$ 15%	15% $\sim$ 30%	30% $\sim$ 50%	$>$ 50%
面积开销	5% $\sim$ 15%	15% $\sim$ 20%	25% $\sim$ 30%	$>$ 35%
适合的处理器类型	通用	服务器	企业/吞吐量	学术/极端吞吐量

这些数字说明了为什么工业界的选择集中在SMT2和SMT4/SMT8——SMT16及以上的线程数量只在极端的吞吐量导向设计中才有意义，且接近细粒度多线程的特性。

SMT与大小核的协同

在混合架构处理器中（如Intel Alder Lake/Raptor Lake），SMT与大小核的协同使用引入了新的设计考量：

P-core SMT + E-core的调度复杂性：在Alder Lake中，8个P-core（各2线程HT）加8个E-core（无HT）产生24个逻辑处理器。操作系统调度器需要理解这些逻辑处理器的异构性质：

8个P-core的"主"线程（逻辑处理器0、2、4...14）在单独执行时性能最高
8个P-core的"副"线程（逻辑处理器1、3、5...15）与主线程共享物理核心，性能受SMT干扰
8个E-core（逻辑处理器16 $\sim$ 23）性能约为P-core的65% $\sim$ 70%

正确的调度优先级应该是：P-core主线程 $>$ E-core $>$ P-core副线程（当P-core主线程忙碌时）。这意味着在中等负载下（例如只有8 $\sim$ 12个活跃线程），调度器应该首先填满所有P-core主线程和E-core，而不是在P-core上启用HT。HT只应在所有物理核心都已占用且仍有更多线程需要运行时才被利用。

Intel的Thread Director通过HFI接口向操作系统提供这种调度指导——它为每个逻辑处理器报告不同的性能和能效评分，引导调度器做出正确的优先级决策。

取消P-core HT的工程合理性：Intel在Arrow Lake中取消P-core HT的一个核心原因正是上述调度复杂性。在大小核架构中，E-core可以更简洁地提供额外的多线程吞吐量：

E-core提供的是物理隔离的执行资源，不存在线程间干扰
E-core的调度语义比HT线程更简单——它就是一个独立的核心
取消HT后，每个P-core的全部资源（ROB、PRF、cache）都可供单线程使用，最大化单线程性能
取消HT释放的面积（约5% $\sim$ 10%）可以用于加宽核心或增加cache容量

SMT的未来方向

综合本章的讨论，SMT技术在2025年后可能沿以下方向发展：

**（1）服务器领域的持续演进。**在服务器和企业计算中，SMT仍将是提高吞吐量的重要技术。IBM POWER和可能的未来ARM Neoverse设计将继续探索SMT4/SMT8，配合更精细的安全隔离机制（硬件Core Scheduling、完全分区的cache和TLB）来应对安全挑战。

**（2）客户端的逐步退出。**在桌面和移动领域，SMT正在被大小核架构所取代。Intel Arrow Lake取消P-core HT是这一趋势的明确信号。Apple从未采用SMT的策略则证明了这条路径的可行性。未来的客户端处理器可能完全不支持SMT，转而通过更多的E-core来提供多线程吞吐量。

（3）安全驱动的架构变革。SMT的安全问题正在推动微架构设计的根本性变革。未来的处理器可能采用安全模式切换——在安全敏感的执行阶段（如密码学运算、Enclave代码）自动切换到严格的资源分区模式或直接禁用SMT，而在非安全敏感的阶段恢复完全共享以获得最大吞吐量。这种模式切换需要硬件和操作系统的紧密协作。

**（4）RISC-V的灵活实现。**RISC-V的模块化架构为SMT提供了新的实现灵活性。RISC-V处理器可以根据目标市场自由选择SMT的线程数量和资源共享策略，不受传统ISA兼容性的约束。某些RISC-V设计可能探索非对称SMT（两个线程有不同的资源配额）或条件SMT（只在特定工作负载模式下启用SMT）等创新方案。

RISC-V ISA的Hart（Hardware Thread）概念天然支持SMT——每个Hart是一个独立的硬件线程，拥有自己的体系结构状态（包括PC、通用寄存器文件、CSR等）。RISC-V规范没有规定Hart之间的资源共享方式，给予了微架构设计者完全的自由度。SiFive的P670/P870等高性能RISC-V核心已经开始探索多Hart实现，虽然截至2025年商用RISC-V处理器中的SMT实现尚不多见。

**（5）AI/ML工作负载对SMT的新需求。**AI推理工作负载的特点——高度并行的矩阵运算与不规则的控制流交替出现——可能重新定义SMT的价值。在Transformer模型的推理过程中，注意力机制的计算涉及大量的向量点积（高IPC、高ALU利用率），但Beam Search或Top-K采样阶段涉及不规则的分支和内存访问（低IPC、大量cache miss）。SMT可以在这两种阶段之间提供互补：一个线程执行当前的矩阵运算，另一个线程预取下一批次的数据——但这需要软件框架的配合来实现线程级的流水化。

SMT的量化总结

表表 45.13提供了主流处理器SMT实现的综合对比，作为本章的量化总结。

处理器	SMT线程	面积开销	吞吐量增益	ST回退	安全
Intel Skylake	2	$\sim$ 10%	25% $\sim$ 30%	5% $\sim$ 15%	MDS漏洞
Intel Golden Cove	2	$\sim$ 12%	20% $\sim$ 30%	5% $\sim$ 10%	部分修复
Intel Arrow Lake	无	0%	N/A	0%	无风险
IBM POWER10	8	$\sim$ 28%	50% $\sim$ 65%	30% $\sim$ 50%	Core Sched
AMD Zen 4	2	$\sim$ 10%	20% $\sim$ 30%	5% $\sim$ 12%	缓解措施
Apple M4	无	0%	N/A	0%	无风险
ARM Cortex-X4	无	0%	N/A	0%	无风险

主流处理器SMT实现的综合对比（截至2025年）

这张表清晰地展示了行业的分化趋势：在客户端/移动端，SMT正在退出；在服务器端，SMT仍然是重要的性能工具，但安全缓解的成本在增加。

设计提示

SMT的本质是一种时间维度的资源复用技术——它让多个线程在时间和空间上重叠使用同一套物理资源。这与大小核（空间维度的资源分化）和Chiplet（物理维度的资源分布）形成了正交的设计维度。最终，一个成功的多核处理器需要在这三个维度上做出协调的选择，以在性能、能效和安全性之间取得最适合其目标市场的平衡。

本章小结

本章系统地讨论了同时多线程（SMT）的设计原理、微架构实现和安全挑战。核心要点总结如下。

**统一视角回顾。**SMT体现了处理器设计中并行维度的极致利用——它不增加新的执行资源（这是多核的策略），而是让多个线程在时间和空间上共享现有资源来逼近吞吐率上限。在第 24.0 章中讨论的寄存器重命名机制和第 27.0 章中讨论的发射队列设计，在SMT下都需要扩展来支持多线程的映射和竞争。第 38.0 章中讨论的ROB提交机制在SMT下从单指针扩展为多指针，每个线程独立提交。

**五种分区策略。**每种微架构资源根据其占用时间、容量敏感性和安全需求选择不同的分区策略——ROB静态分区防止饥饿、发射队列完全共享利用就绪状态的自调节特性、PRF混合分区平衡公平性和灵活性。

**Intel与IBM的对比。**Intel的SMT-2追求最小的单线程性能回退（ $<$ 15%），适合通用计算；IBM POWER10的SMT-8追求最大的吞吐量增益（2.3倍），适合企业服务器的大规模并发事务处理。AMD选择了更多的SMT-2核心（而非更少的SMT-8核心）来在通用市场上取得平衡。

安全问题。SMT的资源共享天然提供了侧信道攻击面——PortSmash通过执行端口竞争窃取密钥，TLBleed通过TLB争用推断访存模式，MDS攻击更进一步实现了跨线程的直接数据泄露。Core Scheduling和微码补丁提供了软件层面的缓解，但完整的硬件级隔离（如Ice Lake的缓冲区线程标记）仍在演进中。安全问题的全面分析请参见第 50.0 章。

设计权衡 3 — SMT与大小核的选择——前向桥接

本章分析了Apple和ARM不采用SMT的工程理由——它们选择了大小核架构作为替代方案。第 46.0 章将深入讨论大小核与异构多核设计的原理：暗硅问题如何从物理定律层面推动异构设计的必要性、Hill-Marty模型如何证明异构优于同构、Intel Thread Director如何在硬件层面协助异构调度、以及ARM EAS如何在软件层面实现能量感知调度。

从SMT到大小核的演进反映了处理器设计思想的一个根本性转变：从资源共享到资源分化。SMT让多个线程共享同一份资源来提高利用率；大小核让不同类型的核心各自优化来提高效率。Intel在Arrow Lake中取消P-core的HT，正是这一转变的标志性事件——大小核架构已经成熟到足以替代SMT在客户端处理器中的角色。

同时多线程 ​

线程级并行的利用 ​

细粒度多线程 ​

GPU中的细粒度多线程 ​

粗粒度多线程 ​

粗粒度多线程的触发逻辑 ​

粗粒度多线程与SMT的混合 ​

同时多线程 ​

SMT资源共享与分区策略 ​

三种资源分配策略的形式化分析 ​

各微架构资源的最优分配策略 ​

资源分区的量化影响 ​

资源竞争检测与动态调节 ​

五种资源分区策略的深入分析 ​

策略一：静态等分（Static Equal Partition） ​

策略二：完全动态共享（Full Dynamic Sharing） ​

策略三：上限共享（Capped Sharing） ​

策略四：优先级共享（Priority-based Sharing） ​

策略五：混合策略（Hybrid Per-Resource Policy） ​

Intel Hyper-Threading逐结构深度分析 ​

ROB：静态分区（各256项） ​

uop Cache（DSB）：共享但线程ID标记 ​

L1 I-Cache和L1 D-Cache：完全共享 ​

L2 Cache：完全共享 ​

TLB：共享，PCID隔离 ​

分支预测器：共享BTB和PHT，部分线程ID哈希 ​

发射队列（RS）：完全动态共享 ​

物理寄存器文件（PRF）：动态共享+最低保证 ​

SMT对分支预测器的干扰量化 ​

BTB容量竞争 ​

TAGE别名污染 ​

解决方案：线程ID编入哈希索引 ​

ROB静态分区的硬件实现 ​

SMT的微架构设计 ​

前端资源的线程管理 ​

取指阶段 ​

取指带宽的量化分析 ​

分支预测器 ​

解码阶段 ​

重命名阶段 ​

后端资源的线程管理 ​

重排序缓冲区（ROB） ​

发射队列（IQ/RS） ​

物理寄存器文件（PRF） ​

功能单元 ​

端口竞争的量化模型 ​

发射选择逻辑的SMT扩展 ​

Store Buffer和Load Queue ​

Store-to-Load Forwarding的线程隔离 ​

SMT下的原子操作 ​

Cache与TLB的线程共享 ​

L1指令缓存（I-Cache） ​

L1数据缓存（D-Cache） ​

Cache替换策略的SMT感知 ​

L2/L3缓存 ​

L3 cache的SMT影响 ​

TLB的线程共享 ​

TLB容量的量化分析 ​

线程优先级调度 ​

前端调度：ICOUNT策略及其改进 ​

取指策略的硬件实现复杂度 ​

后端调度：发射优先级 ​

SMT的实际实现 ​

Intel Hyper-Threading ​

Pentium 4中的初始实现 ​

Pentium 4 HT的设计教训 ​

Skylake及后续微架构中的HT ​

Golden Cove和Raptor Cove ​

HT模式切换的微架构细节 ​

HT对微码操作的影响 ​

Arrow Lake的HT取消 ​

HT的面积开销分析 ​

HT的性能特征 ​

IBM POWER10的8线程SMT ​

POWER系列的SMT演进 ​

POWER10的SMT8微架构 ​

POWER10 SMT8的一致性与内存序考量 ​

SMT8的应用场景 ​

POWER10 SMT8的极端资源共享 ​

为什么IBM能做到SMT8而Intel只做SMT2？ ​

同时多线程

线程级并行的利用

细粒度多线程

GPU中的细粒度多线程

粗粒度多线程

粗粒度多线程的触发逻辑

粗粒度多线程与SMT的混合

同时多线程

SMT资源共享与分区策略

三种资源分配策略的形式化分析

各微架构资源的最优分配策略

资源分区的量化影响

资源竞争检测与动态调节

五种资源分区策略的深入分析

策略一：静态等分（Static Equal Partition）

策略二：完全动态共享（Full Dynamic Sharing）

策略三：上限共享（Capped Sharing）

策略四：优先级共享（Priority-based Sharing）

策略五：混合策略（Hybrid Per-Resource Policy）

Intel Hyper-Threading逐结构深度分析

ROB：静态分区（各256项）

uop Cache（DSB）：共享但线程ID标记

L1 I-Cache和L1 D-Cache：完全共享

L2 Cache：完全共享

TLB：共享，PCID隔离

分支预测器：共享BTB和PHT，部分线程ID哈希

发射队列（RS）：完全动态共享

物理寄存器文件（PRF）：动态共享+最低保证

SMT对分支预测器的干扰量化

BTB容量竞争

TAGE别名污染

解决方案：线程ID编入哈希索引

ROB静态分区的硬件实现

SMT的微架构设计

前端资源的线程管理

取指阶段

取指带宽的量化分析

分支预测器

解码阶段

重命名阶段

后端资源的线程管理

重排序缓冲区（ROB）

发射队列（IQ/RS）

物理寄存器文件（PRF）

功能单元

端口竞争的量化模型

发射选择逻辑的SMT扩展

Store Buffer和Load Queue

Store-to-Load Forwarding的线程隔离

SMT下的原子操作

Cache与TLB的线程共享

L1指令缓存（I-Cache）

L1数据缓存（D-Cache）

Cache替换策略的SMT感知

L2/L3缓存

L3 cache的SMT影响

TLB的线程共享

TLB容量的量化分析

线程优先级调度

前端调度：ICOUNT策略及其改进

取指策略的硬件实现复杂度

后端调度：发射优先级

SMT的实际实现

Intel Hyper-Threading

Pentium 4中的初始实现

Pentium 4 HT的设计教训

Skylake及后续微架构中的HT

Golden Cove和Raptor Cove

HT模式切换的微架构细节

HT对微码操作的影响

Arrow Lake的HT取消

HT的面积开销分析

HT的性能特征

IBM POWER10的8线程SMT

POWER系列的SMT演进

POWER10的SMT8微架构

POWER10 SMT8的一致性与内存序考量

SMT8的应用场景

POWER10 SMT8的极端资源共享

为什么IBM能做到SMT8而Intel只做SMT2？