Reexamining Direct Cache Access to Optimize I/O Intensive Applications for Multi-hundred-gigabit Networks
Reexamining Direct Cache Access to Optimize I/O Intensive Applications for Multi-hundred-gigabit Networks
Alireza Farshin, Amir Roozbeh+, Gerald Q. Maguire Jr., Dejan Kostić (KTH Royal Institute of Technology, School of Electrical Engineering and Computer Science (EECS) + Ericsson Research)
目录
1. 引言：I/O 技术的演进
1.1. 传统I/O
在传统的I/O模型中，数据处理流程如下：
1. I/O设备通过DMA*（直接内存访问）将数据包传输到主内存。
2. CPU稍后将这些数据包从主内存取回到缓存中进行处理。
这种方法的效率低下，具体表现为：
- 大量访问主内存
- 高昂的访问延迟（>60ns）
- 不必要的内存带宽占用
1.2. 直接缓存访问 (Direct Cache Access, DCA)
DCA技术旨在改善传统I/O的延迟问题：
1. I/O设备仍然通过DMA将数据包传输到主内存。
2. DCA利用TPH*（PCIe事务处理提示）将一部分数据包预取到缓存中。
3. CPU稍后可以直接从缓存中获取这些数据包。
然而，DCA仍然存在效率问题：
- 在内存带宽使用方面仍然效率低下，因为数据首先要写入主存。
- 需要操作系统干预和处理器的支持。
*TPH: PCIe Transaction protocol Processing Hint
1.3. 英特尔数据直接I/O技术 (Intel Data Direct I/O, DDIO)
为了解决上述问题，英特尔推出了DDIO技术：
- 自Xeon E5处理器起，DDIO已集成在至强处理器中。
- 它允许I/O设备将DMA数据包或描述符直接传入/传出处理器的末级缓存（Last Level Cache, LLC），从而绕过了主内存。
2. 挑战：高速网络带来的压力
2.1. 发展趋势
当前的技术趋势是：
- 越来越多的网络内计算（in-network computing）和卸载（offloading）能力。
- 这种趋势将昂贵的计算任务推向网络，而在处理器上执行有状态（stateful）的功能，这使得应用程序的I/O密集程度更高。
2.2. 趋势带来的压力
这些趋势，特别是不断增长的网络链路速度，带来了巨大压力：
- 更快的链路速度：网络速度已达到100G、400G甚至更高。在100 Gbps速率下，每6.72纳秒就有一个新的(64-B数据+20-B开销)数据包到达。
- 结论*：数百吉比特（Multi-hundred-gigabit）的网络无法容忍内存访问的延迟，并且数据包的到达间隔时间持续缩短。
*注：20B = 7B 前导码 + 1B 帧起始符 + 12B 帧间隙。
2.3. DCA的重要性
如果没有DCA（泛指DDIO这类直接缓存访问技术），我们将无法以线速处理I/O，从而在使用数百吉比特网络时导致丢包或延迟增加。
3. 实验：高网络速率下的性能表现
3.1. 在100 Gbps速率下转发数据包
实验设置：使用一个数据包生成器向被测设备（Device under Test）发送流量，被测设备负责转发数据包。
- 被测设备配置：
- CPU: Intel Xeon Gold 6140
- NIC: Mellanox ConnectX-5
- 每个NIC放置在PCIe 3.0 16x插槽中
- 实验结果*：
- 在100 Gbps速率下，第99百分位的延迟约为1050微秒。
*一个PCIe 3.0 16x插槽能够提供约125 Gbps的全双工带宽。
3.2. 在200 Gbps速率下会发生什么？
实验设置扩展为使用两个100 Gbps的NIC，总速率为200 Gbps。
- 实验结果：
- 当总速率达到200 Gbps时，为其中一个100 Gbps NIC测得的延迟比其单独工作时高出30%。第99百分位的延迟上升到约1350微秒，这表明存在性能瓶颈或资源竞争。
4. 深入剖析 DDIO
4.1. DDIO的工作原理
为了深入了解DDIO的行为，研究者设计了一套微基准测试（micro-benchmarks），旨在回答以下关键问题：
- DDIO具体使用哪些缓存路（ways）进行数据分配？
- DDIO如何与其他应用程序交互（是否存在干扰）？
- 通过远程CPU插槽（remote CPU socket）进行的DMA是否会污染本地LLC？
写入数据包/描述符：
- 写命中/更新：如果目标缓存行已存在于LLC的任何路（way）中，DDIO会直接覆写该缓存行。
- 写分配/未命中：否则，DDIO会在LLC的一个有限部分分配一个新的缓存行来存放入站数据。
读取数据包/描述符：
- 读命中：如果目标缓存行已存在于LLC的任何路中，NIC会直接从缓存中读取。
- 读未命中：否则，NIC会从主内存中读取。
4.2. DDIO 使用的 LLC Way 与缓存争用分析
本节通过实验探究直接数据I/O（DDIO）技术如何使用末级缓存（LLC），以及其与核心上运行的其他应用之间的缓存争用情况。
实验设置
实验环境包含一个运行I/O应用的核心C0和一个运行缓存敏感型应用的核心C1。逻辑LLC共有11个way。网络接口卡（NIC）通过DDIO收发数据包，这些数据包会被直接写入LLC的特定区域。同时，我们使用英特尔的缓存分配技术（CAT）来限制C1上运行的缓存敏感型应用（来自Splash-3基准测试的water_nsquared）可以使用的LLC way。
缓存争用分析
通过调整分配给缓存敏感型应用（C1）的LLC way，并观察I/O应用（C0）的缓存未命中（Cache Misses）总数，可以揭示争用情况。
-
初始阶段：当为C1分配远离DDIO区域的LLC way时（例如，way 1-2，2-3，3-4），I/O应用的缓存未命中数维持在约300万的较低水平。
-
与代码/数据的争用：当分配给C1的LLC way（例如，way 4-5）靠近某个区域时，I/O应用的缓存未命中数显著上升至近600万。这表明，当应用程序的代码/数据占用的缓存区域与I/O应用的工作集发生重叠或冲突时，会导致I/O应用的缓存性能急剧下降。
Page 22: 当分配给缓存敏感应用的LLC way与I/O应用的代码/数据区域发生争用时，I/O应用的缓存未命中数显著增加。 -
中间阶段：当为C1分配中间区域的LLC way时（例如，way 6-7，7-8，8-9），I/O应用的缓存未命中数回落到较低水平，表明此区域的争用较小。
-
与I/O数据的争用：当分配给C1的LLC way（例如，way 9-10，10-11）移动到LLC的另一端时，I/O应用的缓存未命中数再次急剧上升，甚至超过了之前的峰值，达到约600万至800万。
Page 27: 当分配给缓存敏感应用的LLC way与DDIO使用的I/O数据区域发生争用时，I/O应用的缓存未命中数再次显著增加。
结论
实验结果表明，DDIO倾向于使用LLC中特定的一部分way（在此例中为way 10和11）来存放网络数据包。当其他应用程序（无论是其代码/数据还是其自身）被分配到与DDIO区域或I/O应用工作集区域重叠的缓存way时，就会发生严重的性能争用，导致I/O应用的缓存未命中率大幅增加。
5. DDIO 的性能瓶颈与调优
5.1. DDIO的性能表现与问题根源
研究表明，DDIO并非总能提供预期的性能优势。
- 根据ResQ [NSDI'18]和英特尔的报告，DDIO可能无法带来预期的好处。
- 问题根源：采用写分配（Write-allocate）策略的DDIO可能会将尚未处理和已经处理过的数据包从LLC中驱逐出去。
- 这导致CPU需要从主内存而不是LLC中读取数据包，从而增加了延迟。
- 一种常见的缓解策略：减少接收（RX）描述符的数量，使得数据包缓冲区能够完全容纳在有限的DDIO缓存分区内。
5.2. 减少描述符数量的局限性
然而，仅仅减少描述符数量并不足以解决DDIO的性能问题。
- 性能瓶颈：实验数据显示，增加RX描述符的数量和数据包的大小会对DDIO的性能（写命中率）产生负面影响。如下图所示，随着RX描述符数量从128增加到4096，所有数据包大小（256-B, 512-B, 1024-B, 1500-B）下的DDIO写命中率都出现了下降，尤其是对于较大的数据包和较多的描述符。
- 容量限制：DDIO无法有效利用分配给它的全部LLC预留容量。
- 例如，即使为DDIO分配了2/11的LLC way（相当于4.5 MB），其实际有效使用的容量远小于此（图中高亮处显示有效数据量约375 KB远小于4.5 MB），导致命中率在缓冲区大小远未达到理论上限时就开始下降。
此外，在I/O密集型应用中，增加核心数量并不总能改善PCIe指标。如下图所示，随着核心数量从4个增加到18个，DDIO的写命中率反而下降。这是因为当使用18个核心，每个核心配置256个接收（RX）描述符来转发1500字节的数据包时，总数据量（约6.59 MB）会超过末级缓存（LLC）的容量（例如4.5 MB），导致缓存命中率降低。
因此，一个理想的DDIO实现应该能够在具有大量RX描述符的情况下依然保持良好性能。
5.3. 通过 IIO LLC WAYS 寄存器进行调优
通过调整一个很少被讨论的寄存器——IIO LLC WAYS，可以显著提升DDIO的性能。该寄存器的默认值为0x600。
如下图所示，通过在该寄存器中设置更多的比特位（即将值从0x600增加到0x7FF），可以有效提高DDIO的读写命中率。图中展示了逻辑上的末级缓存（Logical LLC）分区，调整该寄存器实质上是为I/O流量分配了更多的缓存路（ways）。
5.4. 调优 DDIO 的影响
DDIO对缓存命中率的影响会根据应用的特性，进一步影响到应用层面的性能。
以一个I/O密集型应用为例：使用2个核心在100 Gbps速率下转发1500字节的数据包。实验结果表明，通过在IIO LLC WAYS寄存器中设置更多的比特位（例如从2位增加到8位），可以显著降低应用的99百分位延迟（尾延迟）。如下图所示，当RX描述符数量增加时，设置更多比特位（如图中的6 bits和8 bits）的配置表现出更低且更稳定的延迟。
进一步分析上图可以发现，设置更多的比特位能够有效降低尾延迟。例如，在RX描述符数量为2048时，将设置的比特数从2位增加到8位，可以带来大约30%的尾延迟降低。
6. DDIO 调优的局限性与未来展望
6.1. 调整 DDIO 是否足够？
仅仅调整DDIO并非完美的解决方案，原因如下：
* 缓存竞争：缓存不仅用于I/O数据，还用于存放代码和应用数据。
* 配额限制：每个核心的缓存配额较小。
* 分区粒度：缓存分区是粗粒度的。
为了应对这些挑战，下一代DCA（Direct Cache Access）技术应提供以下功能：
* 细粒度放置 (Fine-grained placement)：类似于CacheDirector技术，能够更精确地控制数据在缓存中的位置。
* I/O隔离 (I/O isolation)：将现有的CAT+ (Cache Allocation Technology) 和CDP++ (Code/Data Prioritization) 技术扩展到I/O领域。
* 选择性DCA/DMA (Selective DCA/DMA)：只将数据包中相关的部分传输到末级缓存（LLC）。
6.2. 何时应绕过缓存：当前系统的情况
如果DMA操作可能导致重要的I/O数据被从缓存中驱逐，那么DMA就不应该直接写入缓存。
在需要性能隔离的多租户或多应用环境中，绕过缓存是有益的。实现这一目标的方法包括：
* 为特定的PCIe端口禁用DDIO。
* 利用远程socket（remote socket）进行数据传输。
7. 实践与关键发现
7.1. 将知识应用于 200 Gbps 网络
实验证明，调整DDIO可以改善200 Gbps网络环境下的数据包处理性能。如下图所示，在一个由多个100 Gbps网卡聚合到200 Gbps速率的测试平台中，与默认配置或禁用DDIO相比，经过调整的DDIO配置（例如设置4个比特位）可以获得更低的99百分位延迟。
这一结果表明，对于数百Gbps级别的网络，必须采用更优的缓存管理策略。
7.2. 处理时间对 DDIO 性能的影响
实验通过在一个测试设备中改变处理时间（通过调用随机数生成器的次数）来观察其对DDIO性能的影响。结果显示，增加处理时间可以提高DDIO的命中率。
然而，如下图所示，虽然增加处理时间能提高DDIO命中率，但同时也会导致系统总吞吐量的下降。
这引出一个重要结论：DDIO的性能在应用是I/O密集型时最为关键，而不是在CPU/内存密集型时。 当应用受限于CPU或内存时，I/O路径上的缓存命中率优化带来的整体效益有限。
7.3. 关键发现
- 如果一个应用是I/O密集型的，增加过多的核心可能会降低其性能。
- 对于I/O密集型应用，调整IIO LLC WAYS这个很少被讨论的寄存器，可以提升性能，其效果有时堪比增加更多核心。
- 当应用开始变为CPU密集型时，增加核心可以提高吞吐量，但必须平衡核心间的负载以最大化DDIO的效益。
- 当网络速率接近~100 Gbps时，DDIO可能成为瓶颈。因此，了解何时应绕过缓存以实现性能隔离至关重要。
- 如果一个应用是真正的CPU/内存密集型，那么调整DDIO的效率会降低，这是因为处理时间的增加虽然提高了命中率，但I/O本身不再是系统瓶颈。
7.4. 其他见解
本研究在不同场景下对DDIO的性能进行了深入分析。更多关于以下问题的详细结果，请参阅我们的论文：
* 接收速率如何影响DDIO性能？
* 处理时间如何影响DDIO性能？
* DDIO是否总是有益的？
* DDIO的扩展性问题。
8. 结论
- 对于I/O密集型应用，应该对DCA/DDIO进行调优。
- 对于未来的数百Gbps网络，需要对DCA/DDIO进行重新架构。
- 欢迎使用我们的开源代码在您的测试平台上进行基准测试：https://github.com/aliireza/ddio-bench">https://github.com/aliireza/ddio-bench