LWN: 怎样让kernel支撑400Gb/s的网络接口？

Memory management for 400Gb/s interfaces

By Jonathan Corbet , May 8, 2019 ,  LSFMM

Christoph Lameter多年来一直在为高性能计算场景改造Linux。在2019 Linux Storage, Filesystem, and Memory-Management Summit的memory-management相关讨论上，他介绍了他碰到的400Gb/s网络接口场景的问题。在这么高的速度下，系统完全没法及时完成相关工作。目前有一些可能的改善方向，但是整体来说非常困难，并且情况越来越糟。

这里的核心问题是，在这么高的数据速率下，kernel的page cache完全被拖垮了。这其实不是kernel的错，而是网络接口的速度和memory的速度差异过大导致的。所以，现在很多服务器不再继续升级他们的inifiniband（无限带宽技术） fabric，因为性能瓶颈已经不在fabric上了。PCIe 3总线的每个lane能支撑1GB/s的带宽，x86系统有44条lane，全部都用上，也无法支撑400Gb/s的网络接口。继续增加fabric容量已经完全没用了。

PCIe 4稍微好一点，毕竟它的double transfer rate技术能够减缓这个问题。不过Lameter认为这个方向进展非常缓慢，并且PCIe的latency会更高。因此所有基于Intel的计算体系都会碰到这个问题，它不再适应高性能计算场景。

有一个OpenCAPI架构，比PCIe更加快，但是只有POWER9系统上才有。而最快的互联结构是NVIDIA的NVLink，能达到300GB/s，POWER9也差不多这个水平。

关于memory带宽问题，处理器厂商都在增加更多的memory channel（内存通道），Intel有6通道，AMD有8通道，不过这种解决方案会增加更多的芯片引脚，也会导致走线更加困难。这些系统上，每个channel一般有20GB/s的带宽，这样一个单线程能利用的带宽上限就定了，这样一个单线程程序甚至无法支撑一个100Gb/s的网络接口，因此多核处理器是必须的。还可能利用GDDR和HBM方案，配合NVLink，能够比现有的服务器表现更好。

Jesper Brouer之前也做过很多工作来改善kernel的network stack性能。他曾经达到过10Gb/s的速率，不过如果数据传输速率达到100Gb/s的话，就意味着每个网络包必须在120ns的时间内处理完毕，这个过程中不能发生任何一次cache miss，否则就来不及处理了。真正合理的解决方案，应该是用硬件来做这些处理。近来在开发的express data path (XDP) 机制，也同样说明没法用软件的network stack来支撑这么高的速率，需要把一些功能，例如checksum和timestamp，交给网卡interface硬件来处理。

此外，还有kernel的direct I/O的问题。direct I/O会使用多组指针来指向4KB pages，不像做大块连续buffer那么高效。1GB的数据传输就会比较慢。而 Linux 5.1内核开始改善了这个情况，允许利用更大簇的数据块来作为传输单位，这样就能减少cache占用，减少内存分配，减少跟device发送的out-of-band data（带外传输数据，常指一些额外控制信息），总之，能提高performance。不过这个新功能暂时在各大发行版上还没有用起来，需要过一段时间才能看到真正应用。

kernel的page cache没法方便的扩大缩小，这是一个问题。而且它没法跟large pages（比4KB page大的page，例如64KB）配合，用户可能需要用direct I/O（绕过page cache）甚至干脆绕过kernel来做，很不方便。这一方面也有了一些进展，例如XArray数据结构就可以让page cache支持多种不同的page size，让slab分配对象movable的工作也能减少内存碎片化，在处理page fault的时候，也不用再去抓mmap_sem lock，还有文件系统也开始支持huge page了。除了这些改进点之外，还有一个方向，暂时没有开始，就是允许kernel改为缺省使用2MB的page size，或者至少比起现在4KB的page size增大一些。

在persistent memory里面，有不少数据是跟相关的memory channel绑定的，所以很快。DAX机制就能彻底绕过page cache。这样的存储空闲有限，没法用于RDMA（因为get_user_pages()的一些限制）。

他认为，将来kernel开发者需要考虑一下terabit stream（就是达到1Tb/s量级的数据流）了，今后迟早会有需求做例如3D全息图这样的应用，无可避免的需要快速搬移超大数据量的data，不过大家现在只是在想办法绕过kernel的限制，没有直面这些问题。最终，这个问题肯定需要一些新的硬件架构，来支撑高性能计算场景。memory-management子系统后续能有一个road map来逐步解决这类问题就好了。Matthew Wilcox说，没有一个road map也许不是一件坏事，community确实在这些问题上花了很多功夫，每个developer都在做出贡献。LSFMM会议的意义就在于能协调所有相关的开发工作，让维护者了解大家的需求。