深入解读 aws graviton3

序言

继去年发布 graviton2 之后，今年 aws 如期发布了 graviton3。graviton3 在 aws 数据中心的落地标志着其在自研芯片的道路上又成功的迈进了一大步，同时也标志着其在公有云上的护城河又一次得到了加宽。

aws graviton 芯片生态打造

在分析 graviton3 之前，我们先来看一下 aws 在打造 graviton 生态方面都取得了哪些成果

• 基于 graviton aws 推出一系列实例，覆盖到存储，数据库，计算，大数据分析

• 计算密集型：c6g, c6gd, c6gn

• 内存密集型：r6g, r6gd, x2gd

• 存储密集型：lm4gn, ls4gn

• GPU 实例：g5g

• 操作系统兼容

• cetos, redhat, debian, fedora, freebsd, ubuntu, netbsd, suse

• containers

• aws fargate, aws EKS, docker, k8s

• 第三方合作伙伴

• NVIDIA HPC sdk available in 2022

• SAPHANA

大胆预测，未来 aws 在自己的数据中心内，大部分的服务器以及硬件都可能是自研的。理由也比较简单，一个是可控，一个是成本优势比如 aws 推出的 nitro ssd 直接跟 flash memory 厂商合作省去了中间商的差价。另外一个最重要的是，未来云厂商的护城河有多宽取决于云厂商自研硬件的能力。同时相对于传统服务器厂商，云厂商能够根据自己客户的业务痛点以及相关的性能瓶颈做有针对性的优化，而这个优势像 intel, AMD 这种厂商是完全没有的。

graviton3 架构

• cpu：ARM V1， 64core, 2.6GHZ

• 内存：8 channel DDR5，内存全加密设计, 内存带宽 300GB/s

• 晶体管：550 亿

• I/O：2 * PCIe gen5

• 设计工艺：chiplet, 7 silicon die, 5nm

graviton3 interconnet&system 图

如上图所示，64 core 占用了一个 die, 其余的分别是 2 个 die for pcie gen5, 4 个 die for DDR5 mem controller。基于 graviton3，aws 发布了 c7g 服务器

c7g 服务器架构如下：

• no numa 架构，无 SMT，每个 vcpu 都是一个 physical core

• 3 sockets/server, 采用一个 Nitro card 带 3 个 graviton 3 sockets, 将传统 42U 机架利用率提高 50%的同时，也顺便降低了功耗。

• 8 channel DDR5

一带三架构

关于这个一带三架构这里我详细介绍一下，这里的每个 sockets 其实都一个单路的 graviton3 服务器。底层实现原理其实也比较简单，每台单路的服务器通过物理 link 直接跟 nitro 卡链接，然后这个 link 主要是用来传输标准的 pcie 协议，使得 nitro card 能为三台服务器模拟设备。

其实这种设计并不是 aws 首创，国外的 dpu 创业公司 fungible 很早就提出了这种设计，只是 aws 成功的把这种设计在其数据中心进行了落地。

graviton3 背后的设计逻辑

1. graviton3 只提供 64 cores，2.6GHZ

大多数人认为如果要提升 workload 的 performance，天然就会想到增加服务器 cpu 的数量以及提升 cpu 运行频率。确实，大多数服务器厂商也都是这么做的。比如，不管是 intel 还是 amd 都在疯狂的堆 core 和提高频率，这一点可以从这两家下一代的服务器架构上看出一些端倪。intel 的下一代 SPR 平台最大 56C(112HT), 而 AMD 下一代平台 Genoa 达到了 96C(192HT)，而两者的 cpu 运行频率基本都是 3.0GHZ 以上。

但是，随着 Dennard scaling 定律的失效，当你提升频率的同时 cpu 功耗也在不断的提高。站在 aws 角度来看，这并不是他们想要的，他们希望在 performance 和功耗之间找到一种平衡。那么 graviton3 是怎么做的呢？答案就是他们把 core 做的更 wider，也就是说让每个 cpu cycle 内做更多的工作。

上面的这张图展示了 graviton3 cpu 增强部分：

• 取指(Fetch), 译码(decode)，执行(issue, instruction window) 性能翻倍

前两个大家都比较熟悉，这里主要解释一下 issue instruction window, 这个窗口大小决定了一个 cpu cycle 内可以选取多少已经 ready 的指令来进行执行。窗口越大那么就可以选取越多的指认来执行(这些指令之间是无依赖的)。但是这个窗口大小是受限于 cycle time 的，也就是说不能无限放大。

• 支持 bfloat 16, 256b SVE(可扩展矢量指令 Scalable Vector Extension,主要针对 HPC，机器学习场景)

• 两倍的 mem ops 的增强

• 两倍的 TLS 性能

2. graviton3 不支持 numa

numa 架构大家都很熟悉了，它主是为了解决 SMP 即对称多处理器架构下，随着 cpu 的增多而产生的内部访问瓶颈。做过性能优化的同学应该都了解，在像 graviton 这种 ARM 架构下跨 numa 访问内存导致的性能衰减在某些业务场景下可达到 50%，而云上业务如果要做业务优化都必须要 case by case 的分析，尤其是像 aws 这种超大规模云厂商的场景下，这种优化策略基本上不可行。因此，graviton 系列干脆从一开始就不支持 numa 架构。那么怎么解决这个内存访问的问题呢，aws 一方面保持核的数量不会太多 graviton 系列都是 64 核，另一方面增加内存带宽比如 gravion3 直接上 DDR5，当然上 DDR5 不仅仅是为了解决这个问题，后面会再聊到这个话题。所以，可以预见后面其他大云厂商也都会紧跟 aws 脚步陆续推出无 numa 的 ARM server。

3.PCIe gen5 and DDR5 一次给你上齐

这一点上可能大家都没有想到，这些新的硬件会在 AWS 这种云厂商在自研的 ARM 服务器上提前 release 出来。其他的硬件服务器厂商基本上都要到 2022 年才能提供，比如 intel SPR 以及 AMD 的 Genoa。其实仔细想想也可以理解，aws 这种云厂商主要是有业务驱动的，而其他的硬件厂商都是面向技术驱动的。当然还有一点就是开篇所提到的，graviton3 得益于 chiplet 的设计工艺，使得它能更加快速的推向市场。

刚才提到了 aws 是面向业务的芯片设计，在设计 graviton3 的时候也确实考虑了真实的业务场景。比如现在的很多业务只要你给他更多的内存带宽和更低的内存访问延时他就能跑的很“开心”，因此这也是 graviton3 上 ddr5 原因之一。

另外，graviton3 未来面向的场景更多的是 HPC 和机器学习，这些更多的是以 hpc 集群或者机器学习集群呈现给用户。这些场景的特点一是东西向 node 之间 interconnect 带宽要求很高，另一方面就是这些业务都是吃内存的主。

上图是一张 aws 的 HPC 超算集群图，从图中可以看到东西向连接带宽已经达到 400Gbps，考虑到后面的扩展需求，上 pcie gen5 就顺理成章了。另外，除了 pcie 链路的压力，这种高带宽对 memory 带宽也同样有压力。不管是 RDMA 还是 DMA，最终都是要跟 memory controller 打交道，如果你的内存带宽达不到，你使用性能再高的 pcie 链路也是不行的。

5. 性能测试

本文最早发表于公众号[技不辱你]上，未经授权情况下不允许其他网站转载。