FMS ' 23:性能ssd的ATS/ATC支持

随着时间的推移，CPU计算能力呈指数级增长, 内存容量需求的增长速度甚至更快. 随着CPU和GPU计算能力的飞速发展, we’re seeing that many workloads like AI training are now limited by the lack of addressable system memory. While virtual memory (固态硬盘-based swap space) might help at the OS layer (it can stop the system from crashing from out-of-memory issues), 对于在高性能工作负载中扩展内存容量来说，这不是一个好的解决方案.

针对这个问题的一项技术回应是引入Compute Express Link™, 或CXL, which allows pools of memory to be connected and shared between several computing nodes and enables memory scalability by orders of magnitude over local DRAM. 它还需要基于性能和局部性对内存进行粒度分层, ranging from processor caches and GPU local memory (high-bandwidth memory (HBM) to much slower far memory with more esoteric coherence structures.

一般, this expansion of memory capacity is only related to DRAM + CXL; 存储 is largely unaffected and the operation of NVMe 固态硬盘s shouldn’t be impacted, 正确的? 不完全是. ssd应该知道分层内存，并且可以进行优化以提高性能, 延迟, 或两个, 对于高性能工作负载. One 固态硬盘 optimization for this use case requires the support of ATS and its related ATC that we’ll discuss here.

什么是ATS/ATC?

ATS/ATC最相关的用途是在虚拟化系统中. 它们也可以在非虚拟化系统中使用, but a simple description details how ATS/ATC works by tracing the data path of a virtual machine (VM) in a direct-assignment virtualized system, 使用标准技术，如SrIOV. 参考图表如下:

One of the key tenants of virtualization is that the guest VM does not know it is running on a virtualized environment. The system devices (like 固态硬盘s) believe they are communicating with a single host instead of a plethora of VMs, 因此，它们可以正常工作，而不需要在固态硬盘上附加逻辑.

这种方法的一个后果是内存寻址. 客户操作系统被设计为在专用系统上运行, so it thinks it is using system memory addresses (SVA = system virtual address; SPA = system physical address) but in reality, 它运行在一个VM空间中，由管理程序管理, providing guest addresses that are local to the VM but are entirely different from the system address mapping. 客户操作系统认为它正在使用SVA和SPA, 但它实际上是使用客户虚拟地址(GVA)和客户物理地址(GPA).

在从本地(来宾)寻址方案到全局(系统)寻址方案的转换过程中必须小心. There are two translation mechanisms in the processor: the memory management unit (MMU) that supports the memory addressed directly by programs (and is irrelevant for 固态硬盘) and the IOMMU that supports the translation of all DMA transfers, 哪个是最关键的.

如图1所示, 每次虚拟机中的客户操作系统想要从固态硬盘执行读取操作时, 它必须提供DMA地址. 它提供的是它认为是SPA，但实际上是GPA. 作为DMA地址发送到固态硬盘的只是GPA吗. 当固态硬盘盘发出请求的数据时, 它发送PCIe数据包(称为事务层数据包[TLPs]), (通常高达512B的大小)，它知道的GPA. 在这种情况下, IOMMU查看传入地址, 理解它是GPA, 查看其转换表以确定相应的SPA是什么, 并将GPA替换为SPA，以便可以使用正确的内存地址.

为什么我们关心NVMe的ATS/ATC?

Having many 固态硬盘s 或CXL devices in a system could cause a storm of address translations that could clog the IOMMU, 导致系统瓶颈.

例如，现代固态硬盘可以执行高达600万IOPS，每个4KB. 假设TLP = 512B，每个IO被分成8个TLP，因此有4800万个TLP需要翻译. 假设IOMMU每4个设备实例化一次，它每秒转换1.92亿TLP. 这是一个很大的数字，但情况可能会更糟，因为tlp“最高可达512B”，但也可能更小. 如果TLPs越小，翻译量就越高.

我们需要找到一种减少翻译次数的方法. And this is what ATS is about: a mechanism to ask for translations ahead of time and reuse them for as long as they are valid. 假设操作系统页面是4KB, 每次翻译使用8个TLP, 按比例减少翻译的数量. 但是在大多数虚拟化系统中，页面可以是连续的, 下一个有效粒度是2MB, so each translation can be used for 8*2M/4K = 4096 consecutive TLP (or more if using TLP smaller than 512B). 这使得IOMMU必须提供的翻译数量从200万降到100万以下, 这样就减轻了堵塞的风险.

NVMe的ATS/ATC建模

在NVMe, the addresses of the submission and completion queues (SQ and CQ) are each used once for every command. 我们不应该保留这样的(静态)翻译的副本吗? 绝对. 这正是ATC所做的:保存最常见翻译的缓存副本.

The main question at this point is what DMA address patterns would the 固态硬盘 receive so that ATS/ ATC can be designed around them? 不幸的是，没有相关的数据或文献.

We approached this problem by building a tool that tracks all addresses received by the 固态硬盘 and stores them so that they can be used for modeling purposes. 变得重要, the data needs to come from some acceptable representation of real-life applications with enough data points to represent a valid dataset for our cache implementation.

我们为一系列数据中心应用程序选择了通用的工作负载基准, 他们跑, 并进行了每段20分钟的IO跟踪. 这导致每个跟踪产生数亿个数据点，为建模工作提供数据.

收集到的数据示例如下图所示, 通过使用XFS文件系统在RocksDB上运行YCSB (Yahoo 云 Server Benchmark)来执行:

存储数据ATC评估:

• 表征方法:

1. 假设虚拟机运行标准工作负载.
2. 跟踪每个工作负载的唯一缓冲区地址
3. 将它们映射到STU (2mb)较低的页面
4. 构建ATC的Python模型
5. 重放跟踪到模型以验证命中率
6. 对尽可能多的工作负载和配置进行重复

观察结果:多虚拟机, 正如预期的, 具有比单个图像更少的局部性，但缩放不是线性的(4倍大小的16倍#VM)

计算缓存需求, we built a Python model of the cache and replayed the whole trace (all hundreds of millions of entries) and analyzed cache behavior. 这使我们能够对缓存大小(行数)的变化进行建模。, 拆迁政策, 斯图大小, 以及其他与建模相关的参数.

We analyzed between ~150 and ~370 million data points per benchmark and found that the unique addresses used typically measured in the tens of thousands, 对于缓存大小来说，这是一个很好的结果. 如果我们进一步将它们映射到最常用的2MB页面(最小的传输单元)上, 斯图), 页数减少到几百页或几千页.

这表明缓冲区的重用非常高, 这意味着即使系统内存在TB范围内, the amount of data buffers used for IOs is in the GB range and the number of addresses used is in the thousands range, 使其成为缓存的一个很好的候选.

我们担心高地址重用是由于我们特定系统配置中的局部性, 因此，我们针对几个不同的数据应用程序基准运行了额外的测试. The table below compares one of the above YCSB/RocksDB/XFS tests with a TPC-H on Microsoft SQL Server using XFS, 一个完全不同的基准:

与TPC-H的相关性:

• IO分布非常不同:

1. 3.2倍的唯一地址…
2. … but distributed in 70% of STU -> Higher locality

• 缓存命中率收敛在64项左右，与RocksDB一致

Data traces are quite different but if the cache size is large enough (say over a paltry 64 lines) they converge to the same hit rate.

类似的发现已经在其他几个基准测试中得到验证，为了简短起见，这里没有报告.

大小的依赖:

• 基准使用:YCSB WL B与卡桑德拉
• Cache: 4路Set Associative
• 算法:轮询
• 观察:

1. 正如预期的那样，命中率高度依赖于STU的大小
2. STU大小越大，命中率越高
3. Not all data are created equal: every NVMe command need access to SQ and CQ so such addresses have an outsized impact on hit rate

建模、数据固定和删除算法

We can also model the impact of different algorithms for special data pinning (Submission Queue and Completion Queue) and data replacement. 结果如下两张图所示:

第一组图验证了两行大小对缓存的依赖关系, STU尺寸以及是否将SQ和CQ固定到ATC会产生任何差异. 对于相对较小的缓存，答案显然是肯定的, as the two set of curves are very similar in shape but the ones with SQ/CQ caches start from a much higher hit rate at small caches. 例如, at STU = 2MB and only 1 cache line (very unlikely in practice but helps making the point) the hit rate without any SQ/CQ caching is somewhere below 10% but with SQ/CQ pinning is close to 70%. 因此，这是一个值得遵循的良好实践.

至于缓存的敏感性，所选择的清除算法, 我们测试了最近最少使用(LRU), 轮询(RR)和随机(Rand). 如下所示，其影响几乎可以忽略不计. 因此，应该选择最简单、最有效的算法.

算法依赖:

• 基准使用:

1. YCSB WL B和Cassandra
2. 一个更大的集合的一部分

• 结合性:全和四种方式
• 驱逐算法:LRU, Rand和Round Robin
• 结果:

1. 替换算法不会产生任何明显的差异
2. 选择最简单的实现可能是最有效的方法

结论

那么，我们能用这个做什么呢? 这种方法的缺陷是什么?

This proves a path to quantitatively designing the ATC cache around measured parameters so that performance and design impacts can be properly tuned.

对我们方法的一些警告:本报告代表了我们的初步分析，并非结论性的. 例如, 从ATS/ATC中获益最大的应用程序是在虚拟化环境中, 但这些痕迹不是来自这样的设置. 数据显示了如何弥合这一差距，但这种方法更多的是理论上的，而不是可用的, 每个ASIC设计都应该考虑适当的权衡. Another gap to close is that an ASIC design takes close to 3 years and new products can use it for another 2-3 years and have a field life for as many years. 预测3-7年后的工作量会是什么样子是很有挑战性的. 有多少虚拟机将在多少核心上运行，我们将使用多少内存?

在我们的测试中, 我们已经找到了一条通往定量解决和未知的道路, 虽然看起来很吓人, 在建模世界中并不罕见，需要通过任何新的ASIC设计来解决.