探索AMD Infinity Fabric的极限

某些AMD芯片对线程放置特别敏感。某些核心亲和性选择会导致延迟急剧上升，而其他选择则显示出即使在相似或更高的带宽下，延迟也能得到很好的控制。现在，是时候更深入地研究AMD的系统拓扑结构和可能存在的各种瓶颈了。

Ampere在Hot Chips 2024演讲中展示的加载延迟图

AMD芯片从Zen开始就使用多级互连来创建模块化系统，使AMD能够快速、低成本地实现高内核数。多个Zen内核在一个集群中共享一个L3高速缓存，该集群被称为内核复合体 (CCX)。CCX通过AMD的Infinity Fabric访问系统的其他部分，这是一种灵活的互连技术，可让AMD根据需要调整系统拓扑结构。从Zen 2开始，这意味着将CPU内核放在核心复合芯片（CCD）上。CCD 连接到独立的IO芯片，IO芯片与系统内存以及PCIe、SATA和USB等较慢的组件进行通信。这就形成了一种集线器和辐条模式，使AMD的核心数量超过了英特尔。

来自AMD Zen 2平台（Matisse/Rome）的IFOP链接，摘自ISSCC 2020论文

CCD通过Infinity Fabric On-Package（IFOP）接口连接到IO芯片。一个CCD的IFOP链接在Infinity Fabric时钟（FCLK）下提供每周期32字节的读取带宽和每周期16字节的写入带宽。FCLK通常远低于L3和核心时钟。在后续采用更快DDR5的Zen系统中，一个IFOP可能无法提供足够的带宽来饱和DDR5的带宽。超过这个潜在的带宽限制后，DDR内存无法提供足够带宽来满足高核心数系统中所有核心的需求。

当然，还可能有其他争用点。在Zen 2上，多个CCX可能会争夺一个IFOP接口。本文将研究在多个点推高带宽限制时，如何影响一个争用相同共享资源的延迟敏感线程。不再以延迟和带宽为两个轴来呈现数据，而是将延迟和带宽作为两个独立系列来绘制，以显示核心数对延迟的影响。

Zen 4：AMD Ryzen 9 7950X3D

Zen 4是AMD即将淘汰的CPU系列，但它是一个方便的测试平台。作为Zen系列的最新成员，它每个CCD有一个八核CCX。单个Zen 4核心可以从3GB数组中读取数据，速度约为50GB/s，因此与之前的Zen系列相比，它可以吞噬惊人的内存带宽。这应该使任何瓶颈都很容易观察到。我使用的是典型的DDR5配置，带有中等规格的DDR5-5600。

在最小负载下，测试系统的DRAM延迟为82-83纳秒。当其他内核的带宽需求开始填满整个内存子系统的队列时，延迟测试线程很快就会出现更糟糕的延迟。仅几个带宽测试线程就足以将CCD的内存子系统推向极限。

最多 7 个带宽测试线程和延迟测试线程，全部固定在非高速缓存 CCD 上

随着线程数的增加，延迟急剧上升，这可能是因为更多核心导致队列容量争用更加激烈。当与五个带宽线程竞争时，延迟超过了400纳秒。

将带宽负载转移到另一个CCD可以显著降低延迟。当CCD0上的一个核心占用大量带宽时，而CCD1正在运行延迟测试，会出现一个奇怪的延迟峰值。有趣的是，当在CCD0上加载更多核心时，延迟反而会下降，即使此时达到的带宽略有上升。

带宽和延迟都有所改善。事实上，运行八个带宽测试线程的CCD能够达到近64 GB/s的带宽。当带宽测试线程不与延迟测试线程争抢资源时，AMD似乎能够通过IFOP接口获得极高的带宽效率。综合这两点观察，AMD的双CCD设置可以作为一种服务质量（QoS）机制。将占用大量带宽的代码限制在一个CCD内，可以让另一个CCD上运行的对延迟敏感的代码以最小的影响进行。

为了测试整个系统，测试改变了核心加载顺序，在添加带宽测试线程时交替使用CCD。这样我就可以使用两条IFOP链路，希望能最大限度地提高内存带宽。实现的带宽当然会更高，而且在有几个带宽测试线程的情况下，延迟仍在可控范围内。在每个CCD上运行一个带宽测试线程时，也能获得最大带宽。

然而，当生成更多带宽测试线程时，情况迅速失控。我们可能正面临CCD和内存控制器两个层面的争用问题。这两个层面的延迟似乎是累加的，当延迟测试线程需要与超过10个占用大量带宽的线程竞争时，其性能会受到严重影响。

此时，系统也开始出现异常行为。例如，打开任务管理器的“详细信息”选项卡需要很长时间，尽管测试只加载了每个物理核心上的一个线程。不过，可以认为这是一种相当极端且非典型的工作负载。

硬件性能监控

从软件中观察延迟很简单，但可以通过询问硬件来获得更多信息。Zen 4的L3缓存具有性能监控功能。它的一个功能是随机采样L3未命中，并跟踪它们的延迟。

AMD Zen 4处理器编程参考 (PPR) 中记录的事件

虽然这个性能监测事件与我的C语言和汇编代码一样，提供了平均延迟的概念，但它们测量的并不是完全相同的内容。软件只能观察到从加载到使用的延迟，这包括从核心内的地址生成到从内存层次结构的某个地方获取数据的全部延迟。AMD使用助记符“XiSampledLatency”来描述他们的事件。“Xi”是Zen的L3缓存复合体中与系统其余部分接口的组件。很可能，“Xi”代表“外部接口”（eXternal Interface）。它可能有一组队列来跟踪未完成的请求。采样延迟就像记录一个队列条目保持分配了多长时间一样简单。

来自AMD关于Zen 1的ISSCC论文中的图表，显示了L3缓存复合体。Xi很可能是外部接口。DP可能是数据路径（Datapath），STM是状态宏（State Macros），LRU是最近最少使用元数据（least recently used metadata）。

因为这个事件很可能是在Xi中实现的，所以它只测量L3未命中后的延迟。软件看到的DRAM延迟将包括在许多其他层引入的延迟。这包括地址生成，以及在发现L3未命中之前检查每个缓存层。

因此，Xi看到的延迟应该低于软件看到的延迟。然而，这个事件对于观察L3未命中后内存子系统的行为是非常有用的。在CC1运行延迟测试且CCD0运行单线程生成带宽负载时，Xi的数据与我的全系统带宽测试开始时的软件观察结果大致相关。软件观察到190纳秒的延迟，而CCD1上的L3性能监测则看到166纳秒的延迟。

X轴=测试运行期间的经过时间。延迟测试线程在CCCD1上。我在添加带宽测试线程时会在CCD之间交替

有趣的是，来自另一个CCD的性能监控数据表明，Zen 4优先处理了对带宽要求较高的线程，而牺牲了对延迟敏感的线程。为了确保万无一失，带宽测试线程所在CCD的L3错失带宽为 59 GB/s，几乎与通过软件计算得出的结果完全一致。

当产生更多带宽测试线程时，性能监控数据显示平均延迟上升到200纳秒左右。不过，从延迟测试线程的软件观察结果来看，延迟超过了700纳秒。来自延迟测试线程的请求只占通过内存子系统流量的一小部分，因此 Xi 所看到的平均延迟并不能反映我的测量结果。

Zen 5与快速DDR5

Zen 5是AMD Zen系列中最新且最强大的成员。它使用了与Zen 4相同的IO芯片，但CCD已经发生了变化。George（昵称Cheese）为系统配置了非常快的DDR5，并且还将Infinity Fabric的时钟频率稍微提高了一些。

这或许不是一个典型的设置。DDR5-8000套件价格昂贵。AMD的评测人员指南建议将 6000 MT/s作为最佳配置。但这种配置可以让我们了解Infinity Fabric在内存带宽很大的情况下是如何运行的。在单个CCD中，我不应该接近DRAM带宽限制。事实上，当将IFOP的带宽推向极限时，延迟会好很多。在高负载情况下，延迟也开始降低，这可能要归功于非常快速的DRAM配置。

在单个CCX内的争用仍然会增加延迟，但程度不如Zen 4。Zen 5内核也可以像其前代一样单独消耗大量带宽。也许CCX级别的更改发挥了作用。在2024年的Hot Chips上，AMD展示了一张幻灯片，暗示每个Zen 5 CCX都有一对XI。这两个XI一起可能比Zen 4有更多的队列条目可用，幻灯片也暗示了这一点。

这可能降低了带宽密集型线程占用所有队列条目并导致对延迟敏感线程饥饿的风险。此外，在此设置中，IFOP带宽仅覆盖DDR5带宽的55%，而在测试的Zen 4系统上则为71.4%。内存控制器上的负载较低，使其有更多的空间来管理DRAM低效问题，如总线转向、刷新或bank冲突。或许Zen 5表现更好的原因是这两个因素的结合。

与Zen 4一样，CCD边界可以将对延迟敏感的线程与带宽密集型代码隔离。在这个Zen 5系统上，更快的内存和更快的Infinity Fabric时钟使整体性能更好。更重要的是，在Zen 4上观察到的由一个带宽线程引起的延迟峰值已经消失了。

在Zen 4上，该峰值一定是由Infinity Fabric中的某个因素引起的。毕竟，如果延迟和带宽测试线程在不同的CCD上，它们无法争夺相同的XI或IFOP。尽管Zen 5使用了相同的I/O芯片，但AMD可能调整了其流量管理策略，以更公平地为具有不同内存访问模式的内核提供服务。

Ryzen 9 9950X及其快速内存设置在加载两个CCD时仍然令人印象深刻。即使内存带宽超过100 GB/s，延迟也仍然控制得很好。那些DDR5-8000内存条的价格似乎为48 GB套装250美元。花那么多钱，当然应该获得顶级性能。

AMD或许做了调整，以改善负载下的延迟。Zen 4中疯狂的700纳秒测量值已经不复存在。测试没有在Zen 4上使用接近DDR5带宽限制的内存，但Zen 4的性能监控数据表明，延迟不应该超过200纳秒。

Zen 2：每个CCD/IFOP两个集群

Zen 2可能有些过时，但它首次亮相了AMD的现代芯片设计。更有趣的是，它每个CCD有两个四核CCX。这让我可以分别查看CCX级别和CCD级别的瓶颈。

与Zen 4和Zen 5不同，运行Zen 2时FCLK和DRAM速度相匹配。因此，一个CCD的IFOP带宽与DRAM带宽相匹配。Zen 2从单个CCX实现了约84.4%的理论DRAM带宽。这个百分比高于Zen 4（71.4%）或Zen 5（55%）。当然，后两代实现了更好的绝对带宽。

延迟从71.7纳秒开始，当三个带宽密集型线程共享同一个CCX时，延迟增加到142.77纳秒。但是，在一个CCX上运行的延迟测试线程与另一个CCX上的带宽负载相当好地隔离，即使这两个CCX在同一个CCD上也是如此。这让我认为CCX的XI可能是比IFOP下游链路更严重的瓶颈。

在单个CCD内的两个CCX上创建带宽需求会提高延迟。这并不奇怪，因为现在在CCX的XI和IFOP处都存在争用。尽管如此，Zen 2的表现还不错。285纳秒的延迟并不出色，但比Zen 4单个CCD的400纳秒要好。Zen 5在类似的CCD级别争用测试中表现更好，约为151纳秒。

Zen 2比Zen 4表现更好的原因或许是Zen 2内核单独无法消耗那么多带宽。DRAM延迟较高，这意味着需要有很多正在处理的请求排队才能维持高DRAM带宽。Zen 2内核只能维持足够的正在处理的请求，以实现24-25 GB/s的DRAM带宽。这远低于Infinity Fabric或DRAM带宽限制，因此延迟测试线程有很好的机会为其自己的请求找到空闲的队列条目。

与Zen 4和Zen 5一样，Zen 2也能从CCD级隔离中受益。与Zen 5一样，Zen 2也不会因为单个带宽负载线程而导致延迟激增。不能确定这里是否存在复杂的流量管理。同样，单个线程无法维持足够的L3未命中来垄断下游队列。

回顾来看，Zen 2的DDR4控制器在高负载下对内存请求的调度表现优异。尽管已接近其带宽极限，但Ryzen 9 3950X仍能控制延迟。在CCD1的带宽测试中，从CCD0场景测试的延迟来看，3950X的延迟表现优于7950X3D。

同时加载两个CCD确实会增加延迟，但总比通过一个CCD的IFOP占用所有DRAM带宽要好。尽管一个IFOP接口的带宽足以让DDR4控制器达到饱和，但同时使用两个IFOP接口却能提供更好的延迟。这可能是因为我目前只是在挑战DDR4的带宽极限，而不是同时挑战DDR4和单个IFOP的极限。

这些观察结果表明，CCX内部的争用最成问题，尽管通过IFOP接口的争用也可能略微增加延迟。

Zen 2还有一对XI性能监控事件，用于跟踪L3平均未命中延迟。不过，Zen 2的测量方法更直接，是以周期为单位，而不是随机抽样请求。PPR会告诉你将延迟事件除以请求数，从而得到以周期为单位的延迟。基本上，它是在告诉你如何求解利特尔定律。倒推一下，延迟事件会随着XI每个周期的队列占用率递增。

根据AMD的Zen 2性能监控报告，有一个相应的事件，你可以通过除以它来得到以周期为单位的L3未命中延迟。即延迟 = 队列占用率 / 请求计数。因此，延迟事件跟踪的是队列占用率。

如果单独查看队列占用率，会发现平均队列占用率约为59-61，非常接近64。遗憾的是，AMD 的L3性能计数器不支持计数屏蔽，但平均数字可能意味着每个CCX的XI有64个队列条目。如果是这样，两个CCX加在一起就有128个XI队列条目。

在Hot Chips 33上，AMD展示了一张幻灯片，表明Zen 3的合并八核CCX的XI有192个队列条目。

AMD在Hot Chips 33上的幻灯片显示了来自CCX到内存的192个待处理未命中。

到了Zen 5，AMD的每个CCX可能有320个XI队列条目，可能是CCD的两个XI块中各有160个条目。

目前还没有找到关于Zen 4的XI队列容量的任何信息。也许Zen 4增加了队列条目的数量，但增加的数量不足以适应Zen 4在内存级并行能力上的巨大飞跃。

AMD在Hot Chips 2023关于Zen 4的演讲中，Kai Troester提到L2和L3都收到了更大的未命中队列，以支持更多的未完成请求。

如果是这样，那就能解释在Zen 4上看到的一些奇怪操作了。当然，队列条目不是免费的，队列越大，面积和功耗就越大。如果用户很少遇到这些限制，AMD可以在Zen 4上做出合理的权衡。AMD很可能对许多程序进行了评估，然后做出了合理的权衡。我没有时间或资源去做全职员工能做的事情，但我可以举几个例子。

实践中的延迟和带宽

在这里，测试以1080P分辨率运行了《赛博朋克2077》的内置基准测试。将游戏固定在两个不同的CCD上各运行了一次基准测试，这样应该更容易解释性能监控数据。在非VCache（Vertical Cache，垂直缓存）CCD上，游戏产生了10-15 GB/s的L3未命中流量。在1秒的间隔内，这并不是很大的带宽，但在这个采样间隔内，带宽使用可能并不是恒定的。内存子系统中各个队列可能会平滑掉短暂的带宽需求峰值，但更长的峰值（仍然在纳秒级）可能会填满这些队列并增加访问延迟。在《赛博朋克2077》中就可能发生这种情况，因为性能监控数据显示L3未命中延迟经常超过90纳秒。

将《赛博朋克2077》定位于VCache芯片可显著减少L3缺失流量，显示出拥有三倍L3容量的价值。L3 miss服务的延迟也更低。更少的内存流量减少了整个内存子系统的排队延迟。因此，VCache还能降低DRAM的平均延迟。这是一个强有力的组合，基准测试的结果也反映了这一点。《赛博朋克 2077》的基准测试在非 VCache 芯片上的平均帧数为 122.34，而在VCache芯片上的平均帧数为 153.98。尽管时钟频率较低，但 VCache 芯片的性能提高了 25.8%。

回过头来看，在这两种情况下，游戏都没有在任何内存子系统的地方达到带宽极限。两种情况下的延迟都得到了很好的控制，而且基线延迟对性能的影响比接近带宽极限时产生的延迟更大。

坦克游戏《钢铁雄心：冷战》提供了另一个例子。模式相似，但带宽需求较低。再次证明，VCache通过在芯片上处理更多的内存请求展现了其价值。同样，减少L3之后的内存子系统负载也会降低平均L3未命中延迟。

《博德之门3》是一款角色扮演游戏，可以掷骰子和投掷物品。带宽需求每秒都有很大变化，但采样的内存延迟仍然得到了很好的控制。远未达到表明带宽瓶颈的200纳秒。

再次强调，Zen 4的内存子系统并没有受到太大压力。VCache继续发挥着出色的作用，将L3命中率从31.65%提高到79.46%。但即使没有VCache，也有足够的Infinity Fabric和DDR5带宽可供使用。

RawTherapee是一款免费且开源的原始文件转换程序。专业相机可以记录原始的12位或14位传感器数据，而不是处理过的JPEG图像。原始文件为摄影师提供了更多的编辑空间来进行曝光和白平衡调整。它们还让编辑者能够在保留细节和减少噪声之间做出有意识的权衡。然而，图像处理可能是计算密集型的。在这里，我将几个4570万像素的D850原始文件转换为JPEG图像，并应用了曝光和降噪处理。

测试没有将RawTherapee固定在一个CCD上，因为图像处理是一项并行任务，需要大量核心（与大多数游戏不同）。测试同时记录两个CCD的数据。RawTherapee 的带宽需求量很大，足以填满队列，但运行时间往往不够长，无法超过1秒的采样间隔。

这就是采样延迟数据提供有价值见解的地方。延迟飙升到超过200纳秒，表明内存子系统已被推到极限。

然而，并不是所有多线程程序都会给内存子系统带来压力。当在后台运行视频编码任务的同时玩了《博德之门3》。L3未命中流量很大，但并不算过分。延迟得到了控制，游戏大部分时间都保持了60 FPS。

视频编码可能需要大量的带宽，但Ryzen 9 7950X3D的L3缓存足够大，可以避免在XI、Infinity Fabric或DRAM控制器层面出现争用。在某些采样间隔内，非核心流量超过了85 GB/s，因此，如果没有L3缓存，假设的Zen 4配置将严重受制于DRAM和Infinity Fabric的瓶颈。为了更直观地说明，这里提供了一张包含L3命中带宽的带宽图。

很久以前，像AMD的Llano或Excavator这样的芯片只有1MB的L2缓存，而没有L3缓存。大容量的L3缓存需要占用大量的芯片面积，并增加设计的复杂性，所以我理解为什么AMD在某些产品上省略了它。但可以想象，即使是一个快速的DDR5配置，如果用在一个假设的拥有16核、每核1MB L2缓存但没有L3缓存的桌面芯片上，也会面临巨大的压力。任何位于核心和内存之间的互连都会承受沉重的负载。当然，这样的配置出于充分的理由并不存在。

最后总结

AMD成功的Zen系列建立在具有多个互连级别的可扩展系统架构之上。但设计一个可扩展的架构是困难的。某一层级的多个模块可能需要通过一个下一层级的瓶颈点进行传输。如果许多核心都在请求尽可能多的带宽，那么队列可能会开始填满并导致延迟。延迟敏感的代码会受到在系统其他地方运行的带宽密集型代码的惩罚。

内存子系统中的延迟是累加的。一个因为等待XI队列条目而被延迟了十几个周期的请求，在争夺IFOP周期时，将会晚到几十个周期。在IFOP处的任何额外延迟都意味着该请求将在更晚的时间通过Infinity Fabric的各个组件。Zen 4似乎受到累积延迟的影响最为严重，这可能是因为AMD允许单个核心消耗的带宽比以前多得多。但根据对Zen 2的性能计数器和观察结果，AMD的Infinity Fabric和内存控制器在负载下能够很好地保持合理的延迟。CCX 级争用似乎是我看到的负载延迟峰值中最严重的原因。

在大多数情况下，这些限制在典型的客户端应用程序中并不会显现。游戏可能对延迟敏感，但本次测试过的游戏并没有产生足够的带宽需求来压力测试内存子系统的某些部分。即使是多线程的生产力工作负载也可能不会触及带宽限制，因为AMD的大容量L3缓存可以容纳大量的内存访问。有些工作负载，如RawTherapee，既难以缓存又是多线程的。

不建议在运行此类工作负载的同时运行游戏或其他对延迟敏感的程序。不过，Zen 5显示出AMD正在关注确保即使在内存子系统非常繁忙的情况下，也能为延迟敏感的任务提供良好的基线性能。