一文看懂Infinity Fabric

科技 2024-12-02 18:53 北京

大会预告

12月5-6日，智猩猩联合主办的2024中国生成式AI大会（上海站）将举办。主会场将进行大模型峰会、AI Infra峰会，分会场将进行端侧生成式AI、AI视频生成和具身智能三场技术研讨会。欢迎报名～

文章转载自公众号：半导体行业观察。本文只做学术/技术分享，如有侵权，联系删文。

自 Zen 以来，AMD 芯片一直使用多级互连来创建模块化系统，让 AMD 能够快速且廉价地实现高核心数。多个 Zen 核心在一个集群中共享一个 L3 缓存，称为核心复合体 (CCX)。CCX 通过 AMD 的 Infinity Fabric 访问系统的其余部分，这是一种灵活的互连，可让 AMD 根据需要调整系统拓扑。

自 Zen 2 以来，这意味着将 CPU 核心放在核心复合体芯片 (CCD) 上。CCD 连接到单独的 IO 芯片，该芯片与系统内存和较慢的组件（如 PCIe、SATA 和 USB）通信。这创建了一个中心辐射模型，让 AMD 的核心数量高于英特尔。

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

当然，也可能存在其他争用点。在 Zen 2 上，多个 CCX-es 可以争用一个 IFOP 接口。在这里，我将研究在多个点上推动带宽限制如何影响争用同一共享资源的延迟敏感线程。我不会在一个轴上显示延迟数据，在另一个轴上显示带宽数据，而是将延迟和带宽绘制为两个单独的系列，以显示延迟如何受到核心数量的影响。

Zen 4 是 AMD 现有的一代CPU ，由于它是我日常使用的台式机，因此是一个方便的测试平台。作为 Zen 系列的最新成员，它每个 CCD 都有一个八核 CCX。单个 Zen 4 核心可以以大约 50 GB/s 的速度从 3 GB 阵列读取数据，因此与之前的 Zen 一代相比，它可以消耗大量内存带宽。这应该会使任何瓶颈很容易被发现。我使用的是典型的 DDR5 配置，具有中等规格的 DDR5-5600。

在最小负载下，我的系统的 DRAM 延迟为 82-83 纳秒。延迟测试线程很快就会发现延迟更严重，因为其他核心的带宽需求开始填满整个内存子系统的队列。只需几个带宽测试线程就足以将 CCD 的内存子系统推到极限。

增加线程数会导致延迟飙升，可能是因为内核数量越多，队列容量的竞争就越激烈。当有五个带宽线程竞争时，延迟会超过 400 纳秒。

将带宽负载推向另一个 CCD 可显著改善延迟。当 CCD0 有一个核心需要带宽，而 CCD1 正在运行延迟测试时，我看到一个奇怪的延迟峰值。在 CCD0 上加载更多核心会奇怪地降低延迟，即使实现的带宽有所增加。我想知道 AMD 是否正在检测活动核心数，并开始保留队列条目，或者如果有足够多的核心需要高带宽，则以其他方式限制每个核心的带宽消耗。

带宽随延迟而提高。事实上，运行八个带宽测试线程的 CCD 可达到近 64 GB/s。当带宽测试线程不与延迟线程发生冲突时，AMD 似乎可以从 IFOP 接口获得出色的带宽效率。综合起来，这两个观察结果表明 AMD 的双 CCD 设置可以充当某种 QoS 机制。在一个 CCD 中包含带宽消耗大的代码可以让另一个 CCD 上的延迟敏感代码以最小的影响继续运行。

为了测试整个系统，我在添加带宽测试线程时切换了核心加载顺序，以便在 CCD 之间交替。这样我就可以使用两个 IFOP 链接，希望能够最大化内存带宽。当然，实现的带宽更高，并且使用几个带宽测试线程时，延迟仍然得到很好的控制。我还在每个 CCD 上运行一个带宽测试线程，实现了最大带宽。

但随着我生成更多带宽测试线程，情况迅速失控。我们可能正在考虑 CCD 和内存控制器级别的争用。这两个层的延迟似乎都是累加的，当延迟测试线程必须与 10 个以上的带宽消耗线程作斗争时，它的情况真的很糟糕。

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

01 硬件性能监控

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

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

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

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

有趣的是，来自另一个 CCD 的性能监控数据表明 Zen 4 优先考虑了带宽消耗大的线程，而牺牲了对延迟敏感的线程。作为健全性检查，托管带宽测试线程的 CCD 的 L3 未命中带宽为 59 GB/s，几乎与我从软件中计算的结果完全一致。

一旦我生成更多带宽测试线程，性能监控数据表明平均延迟上升到 200 纳秒左右。但是，从延迟测试线程的软件观察结果来看，延迟超过了 700 纳秒。来自延迟测试线程的请求只占通过内存子系统的流量的一小部分，因此 Xi 看到的平均延迟不能反映我的测量结果，这是有道理的。

02 Zen5搭配快速DDR5

Zen 5 是 AMD Zen 系列中最新、最出色的成员。它使用与 Zen 4 相同的 IO 芯片，但 CCD 有所变化。Cheese (George) 已将系统设置为非常快的 DDR5，并以稍高的时钟频率运行 Infinity Fabric 以启动。

我不会将此称为典型设置。DDR5-8000 套件价格昂贵。AMD 的评论指南建议将 6000 MT/s 作为最佳点。然而，这种配置可以让我们了解 Infinity Fabric 在大量内存带宽可用的情况下的性能。在单个 CCD 中，我不应该接近 DRAM 带宽限制。事实上，当我推到 IFOP 的带宽限制时，延迟要好得多。在高负载下，延迟也开始降低，这可能是由于非常快的 DRAM 配置。

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

这可能会降低带宽需求大的线程独占所有队列条目并导致延迟敏感的线程无法工作的可能性。此外，在此设置中，IFOP 带宽仅覆盖 DDR5 带宽的 55%，而我的 Zen 4 系统上则为 71.4%。内存控制器上的负载较低，使其有更多空间来管理 DRAM 效率低下的问题，例如总线周转、刷新或存储体冲突。我怀疑 Zen 5 的更好表现归结于这两个因素的结合。

与 Zen 4 一样，CCD 边界可以将延迟敏感线程与带宽消耗大的代码隔离开来。在这个 Zen 5 系统上，更快的内存和更快的 Infinity Fabric 时钟使一切整体上变得更好。更重要的是，在 Zen 4 上观察到的具有一个带宽线程的延迟峰值消失了。

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

当我加载两个 CCD 时，Ryzen 9 9950X 及其快速内存设置继续令人印象深刻。即使内存带宽超过 100 GB/s，延迟仍然得到很好的控制。这些 DDR5-8000 内存条 48 GB 套件的价格似乎为 250 美元。花这么多钱，你最好能得到一流的性能。

再次，我怀疑 AMD 做了一些调整以改善负载下的延迟。Zen 4 的疯狂 700 纳秒测量值已经消失。我并没有将 Zen 4 推向接近 DDR5 带宽限制，但 Zen 4 的性能监控数据表明延迟不应该远远超过 200 纳秒。

03 Zen2：每个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 纳秒要好。在可比的 CCD 级争用测试中，Zen 5 比两者都好，约为 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 告诉您将延迟事件除以请求数以获得周期延迟。基本上，它告诉您解决Little 定律。反向工作，延迟事件随着 XI 每个周期的队列占用率而增加。

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

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

使用 Zen 5，AMD 可能每个 CCX 有 320 个 XI 队列条目，CCD 的两个 XI 块中每个块可能有 160 个条目。

不幸的是，我没有找到有关 Zen 4 的 XI 队列容量的任何信息。也许 Zen 4 增加了队列条目的数量，但还不足以适应 Zen 4 在内存级并行能力方面的大幅提升。

L2 和 L3 都获得了更大的未命中队列，以支持更多未完成的请求。

Kai Troester 在 AMD 2023 年 Hot Chips 演讲中介绍 Zen 4。

如果是这样，那就可以解释我在 Zen 4 上看到的一些奇怪的行为。队列条目当然不是免费的，更大的队列既需要占用空间又需要耗电。如果用户很少遇到这些限制，AMD 可以在 Zen 4 上做出合理的权衡。AMD 可能评估了许多程序并决定做出合理的权衡。我没有时间或资源去做全职员工能做的事情，但我可以举几个例子。

04 实践中的延迟和宽带

在这里，我以 1080P 运行 Cyberpunk 2077 的内置基准测试。我将游戏固定在不同的 CCD 上，运行了两次基准测试，这应该会使性能监控数据更容易解释。在非 VCache CCD 上，游戏看到 10-15 GB/s 的 L3 未命中流量。在 1 秒间隔内，带宽并不多，但带宽使用率在该采样间隔内可能不恒定。带宽需求的短暂峰值可能会被整个内存子系统中的队列平滑，但较长的峰值（仍然在纳秒级）可能会填满这些队列并增加访问延迟。其中一些可能发生在 Cyberpunk 2077 中，因为性能监控数据表明 L3 未命中延迟通常高于 90 纳秒。

将 Cyberpunk 2077 固定到 VCache 芯片上可显著减少 L3 未命中流量，这显示了拥有三倍 L3 容量的价值。L3 未命中的服务延迟也更低。在整个内存子系统中，更少的内存流量可减少排队延迟。因此，VCache 具有降低平均 DRAM 延迟的次要优势。这是一个强大的组合，并且反映在基准测试的输出中。Cyberpunk 2077 的基准测试在固定到非 VCache 芯片时平均为 122.34 FPS，在固定到 VCache 芯片时平均为 153.98 FPS。尽管时钟频率较低，但 VCache 芯片的性能提高了 25.8%。

退一步说，这两种情况都不会让游戏在内存子系统的任何位置突破带宽限制。两种情况下的延迟都得到了很好的控制，基准延迟对性能的影响比接近带宽限制导致的延迟更大。

GHPC 是一款坦克游戏，是另一个例子。模式类似，但带宽需求较低。VCache 再次通过在芯片上处理更多内存请求来显示其价值。同样，减少 L3 之后的内存子系统的负载可以降低平均 L3 未命中延迟。

博德之门 3 是一款角色扮演类游戏，玩家可以掷骰子和投掷物品。带宽需求每秒变化很大，但采样内存延迟仍然得到很好的控制。我们并没有接近 200 纳秒，这表明存在带宽瓶颈。

同样，Zen 4 的内存子系统没有承受太大压力。VCache 继续表现出色，将 L3 命中率从 31.65% 提高到 79.46%。但即使没有 VCache，也有足够的备用 Infinity Fabric 和 DDR5 带宽可供使用。

RawTherapee 是一款免费的开源原始文件转换程序。发烧友相机可以记录原始的 12 位或 14 位传感器数据，而不是经过处理的 JPEG。原始文件为摄影师提供了更多的编辑空间来调整曝光和白平衡。它们还允许编辑者在保留细节和降低噪点之间做出有意识的权衡。然而，图像处理可能需要大量计算。在这里，我将几个 45.7 兆像素的 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 等芯片只有 1 MB 的 L2 缓存，没有 L3。大型 L3 缓存占用大量芯片面积并增加了复杂性，所以我理解为什么 AMD 在某些产品上省略了它。但我只能想象，即使是快速的 DDR5 设置，如果被一个假设的台式机芯片推动，也会有多么困难，该芯片有 16 个内核，每个内核有 1 MB 的 L2，没有 L3。内核和内存之间的任何互连也会负载很重。当然，这样的设置不存在是有原因的。

05 最后的话

AMD 成功的 Zen 系列基于具有多个互连级别的可扩展系统架构。但设计可扩展架构并不容易。一个级别的多个块可能必须通过下一个级别的瓶颈。如果许多核心要求尽可能多地使用带宽，队列可能会开始填满并导致延迟。这有可能产生“吵闹邻居”问题，即延迟敏感的代码会受到系统其他地方运行的带宽密集型代码的惩罚。

内存子系统级别的延迟是附加的。一个请求因等待 XI 队列条目而延迟了十几个周期，在争夺 IFOP 周期时，它将晚到几十个周期。IFOP 的任何额外延迟都意味着请求稍后会经过各种 Infinity Fabric 组件，依此类推。Zen 4 似乎受到复合延迟的影响最为严重，可能是因为 AMD 让单个内核消耗的带宽比以前多得多。但正如性能计数器和对 Zen 2 的观察所显示的那样，AMD 的 Infinity Fabric 和内存控制器在负载下保持合理延迟方面做得很好。CCX 级争用似乎导致了我看到的最严重的加载延迟峰值。

在大多数情况下，这些限制在典型的客户端应用程序中并不常见。游戏可能对延迟很敏感，但我测试的游戏不会产生足够的带宽需求来给内存子系统的某些部分带来压力。即使是线程良好的生产力工作负载也可能不会突破带宽限制，因为 AMD 的大型 L3 缓存可以包含大量内存访问。有些工作负载，如 RawTherapee，既难以缓存又线程良好。我不建议在游戏或其他延迟敏感程序的同时运行这样的工作负载。尽管如此，Zen 5 表明 AMD 正在关注确保延迟敏感任务的良好基准性能水平，即使在内存子系统非常繁忙的情况下也是如此。

参考链接

https://chipsandcheese.com/p/pushing-amds-infinity-fabric-to-its

—END—

点击下方名片

即刻关注我们

算力猩

隶属于智猩猩，关注计算芯片创新，解读中国算力突破。