【实践】浪潮信息KeyarchOS实现基于CXL的内存扩展和Redis应用加速

【实践】SMC-R透明加速TCP技术，在Redis场景下的应用实践

本文在浪潮信息云峦服务器操作系统KeyarchOS环境下，使用SMC-R透明加速TCP技术在Redis场景下进行了应用验证。

一. 背景

当前 Linux 网络协议栈是在性能（吞吐、CPU 使用率）、时延和通用性权衡下的实现。在真实场景中，常常需要高性能但是并不通用的用户态协议栈，亦或是通用、更高性能更低时延的方案，但是基于传统以太网卡的方案很难有大幅度的提升，更多是基于硬件的红利，例如 100G/400G 网络。

在大规模数据中心内部，如何为跨服务器之间的数据传输，提供高性能、低延迟的通信，从而加速数据中心内不同服务器之间的数据共享、数据备份、容灾等；在分布式存储系统中，如何为节点之间的数据传输，提供高带宽、低延迟的存储访问，加速数据的读写操作，提高存储系统的性能等；这些都成为新型网络协议栈的应用场景。

二. 简介

共享内存通信（Shared Memory Communication，SMC）是一种兼容 socket 层，利用共享内存操作实现高性能通信的内核网络协议栈。当共享内存通信基于远程内存直接访问（Remote Direct Memory Access，RDMA）技术实现时，称为 SMC over RDMA（SMC-R）。

SMC-R 兼容 socket 接口的特点使得 TCP 应用程序无需任何改造即可运行在 SMC协议栈上，底层使用的RDMA网络使SMC拥有相较于TCP更好的网络性能。SMC协议栈通过 TCP 连接自主发现对侧SMC能力，协商成功后使用SMC协议栈承载应用数据流量，协商失败则安全回退至TCP/IP协议栈，保证数据正常传输。

三. 协议透明替换

使用 SMC-R 协议有两种方法。

其一，是在应用程序中显式创建 AF_SMC 族的 socket；

其二，是利用 LD_PRELOAD 或 ULP + eBPF 的方式透明的将应用程序中的 AF_INET 族 socket 替换为 AF_SMC 族socket。我们默认使用 SMC-R 通信的节点已经加载了SMC 内核模块，并通过这种方法将应用程序运行在 SMC-R 协议上。

对于第二种方法：

使用 LD_PRELOAD 实现协议栈透明替换，在运行TCP应用程序时预加载一个动态库，在动态库中实现自定义 socket() 函数，将 TCP应用程序创建的 AF_INET 类型 socket 转换为 AF_SMC 类型的 socket，再调用标准 socket 创建流程，从而将 TCP 应用流量引入 SMC-R 协议栈。开源用户态工具集smc-tools中的 smc_run 指令即实现上述功能。

四. SMC-R在高性能数据查询和处理中的应用

SMC-R 作为一套与 TCP/IP 协议平行、向上兼容 socket 接口、底层使用 RDMA 完成共享内存通信的内核协议栈，其设计意图是为 TCP 应用提供透明的 RDMA 服务，同时保留了 TCP/IP 生态系统中的关键功能。基于此，本文针对redis数据库应用场景，在无需对redis进行任何改造的情况下，测试使用SMC-R前后吞吐性能对比，结果如下：

测试结果：redis-banchmarh测试中，SET方法在使用TCP协议下，无论线程数或数据包大小场景下均比较稳定，在使用SMC协议下，提升幅度较大，达到40%以上，在线程数8、数据包大小64情况下提升60%。GET方法测试结果与SET方法相近，性能提升趋势也基本一致。

五. 总结

基于SMC-R的高性能、透明替换等优势，适用于网络通信占比高的场景，在Redis等高性能数据查询与处理的场景，SMC-R为应用提供无侵入式透明替换TCP协议栈的能力，无需应用二次开发和适配，即可为应用提升QPS（Queries Per Second），在Redis应用场景下（64字节、8线程）可提升至60%。本文在浪潮信息云峦服务器操作系统KeyarchOS环境下，使用CXL和分层内存技术在Redis场景下进行了加速应用验证。

一. 背景

随着云计算、大数据、人工智能等技术的快速发展，数据呈现出爆发式增长趋势，同时驱动着算力持续提升，然而，传统DRAM并未实现同步扩展以满足应用需求，应用对内存容量和带宽不断提高的需求，推动着内存扩展技术不断发展，在此背景下，CXL成为解决内存扩展瓶颈的最有前景的技术；与DRAM内存相比，扩展内存面临高延迟、低带宽的技术挑战，为了解决这些挑战，分层内存技术应运而生。

二. 简介

CXL即Compute Express Link，是一种高速互连技术，将CPU、GPU、FPGA等处理器、内存和存储器等设备连接起来，形成高效的计算平台。CXL技术基于PCIe 5.0/6.0协议进行数据传输，具备高速互连、低延迟、高带宽、可扩展的特点，为主机在内存和存储扩展等方面提供了可行的解决方案。

分层内存将内存分为多个层次，每个层次的内存具有不同的特性和成本，应用程序能够根据需求选择不同层次的内存。通常，分层内存由两个或多个层次组成，其中最接近处理器的层次是最快速、最昂贵的内存，而离处理器最远的层次则是最慢、最便宜的内存。高性能的内存比较昂贵，而容量较大但性能较低的内存，则相对便宜。通过合理地组合不同性能和容量的内存，可以提供性价比更高的内存解决方案。

当前，CXL内存是CXL协议的主要应用方向，但CXL内存在延迟、吞吐量方面比DRAM要差。CXL内存与分层内存技术配合，将频繁访问的数据尽量放置到DRAM中，将访问次数较少的数据放置到CXL内存中，能够在实现内存扩展的同时减小CXL内存带来的性能损耗。

三. DRAM和CXL内存的性能差异

CXL内存在Linux系统中会被挂载到一个单独的、不具备CPU core的NUMA Node节点下，在NF5280M7平台上测试发现，CXL内存的延迟和吞吐量比本地DRAM节点和远端DRAM节点都慢，具体的性能数据（使用MLC测算）如下：

四. Redis场景的性能测试

使用YCSB作为测试工具对关闭了持久化的Redis数据库进行性能测试，验证采用CXL内存和分层内存进行内存扩展时对业务系统的影响。

1. 测试环境
   OS：浪潮信息云峦KeyarchOS
   服务器：NF5280M7
   CXL内存：浪潮信息自研CXL内存模块（E3.s）
2. 单独使用DRAM或CXL时的Redis性能测试
   单独使用DRAM时的Redis性能：将YCSB客户端和Redis-server都绑定到Node1上进行吞吐量性能测试；
   单独使用CXL时的Redis性能：将YCSB客户端绑定到Node1上，Redis-server绑定到Node2上，进行吞吐量性能测试；
   以这2个数据作为理论上的基准上线和基本下线。

测试结果：数据样本相同、采样算法相同时，Redis运行在CXL内存节点时延迟更高、耗时更长、吞吐量更低，整体性能比运行在DRAM上时差16%左右。

1. 混合使用DRAM和CXL内存/分层内存的效果测试
   混合使用DRAM和CXL内存时，Redis数据部分存在于DRAM上，部分存在于CXL内存中，所以理论上Redis性能测试应该弱于单独使用DRAM时的性能，而高于单独使用CXL时的性能。
   如果开启分层内存功能，使频繁访问的热数据尽量迁移/存放到DRAM内存节点中，使访问次数较少的冷数据尽量迁移/存放到CXL内存节点中，会对Redis性能起到加速的效果。
2. 普通场景
   据统计，对于实际场景而言经常访问的数据大约占全部数据的20%。本场景测试中我们混合使用DRAM和CXL内存并使它们的大小比例保持在1:4。

测试结果：以1:4的比例混合使用DRAM内存和CXL内存时，开启分层内存后的Redis性能比开启分层内存前提升了大约6%（Redis单条样本数据长度 和 采样算法对结果影响较大，本测试中单条样本数据长度为1K，采用算法使用latest）。

1. 最优场景

经过分析发现，YCSB的latest采样算法会使数据ID越大的记录访问概率越大，且基本上所有的数据都会被访问，而不是仅访问部分数据，所以开启分层内存前后的性能差异不大。

为了尽量体现出分层内存的效果，设计了一个特殊的测试场景：首先使用一个额外程序提前占据大部分DRAM，并且不进行数据读写，使其所占内存在后续测试中都成为冷页内存；其次使用YCSB为Redis加载样本数据，使Redis-server占用DRAM剩余部分内存，以及对应4倍大小的CXL内存（例如额外程序占8G DRAM，Redis-server占用2G DRAM和8G CXL内存）。

测试结果：在DRAM中的冷数据区域容量大于测试中Redis待访问数据容量，保证Redis待访问数据都可以promote到DRAM上时，开启分层内存后的Redis性能比开启分层内存前能提升12%以上，基本接近DRAM的性能水平，与之前的基准测试值相符。

五. 总结

使用CXL扩充系统内存容量时，虽然CXL内存性能比DRAM内存略差，但如果配合分层内存