Linux Kernel中AEP的现状和发展

AEP简介

AEP是Intel推出的一种新型的非易失Optane Memory设备，又被称作Apache Pass，所以一般习惯称作AEP。在这之前也有类似的设备称作NVDIMM或PMEM，目前Linux创建的AEP设备节点也是叫做pmem(如/dev/pmem0)，所以本文中NVDIMM或PMEM都指AEP。但是本文不是为了科普AEP，如果想了解AEP的一些基本知识，可以参考以下几篇文章：NVDIMM Enabling in SUSE Linux Enterprise Part 1NVDIMM Enabling in SUSE Linux Enterprise Part 2Persistent Memory Wiki

DAX

目前Linux Kernel中主要把PMEM看成一个类似于磁盘的块设备，所以可以在PMEM设备上创建文件系统，使它看起来和一般的磁盘没什么区别。但是设备的具体物理属性完全不一样，比如读写的latency，PMEM可以达到和DRAM接近的程度，磁盘当然是望尘莫及的。所以，这就带来一个问题，众所周知，一般在Linux上常见的文件系统，比如ext4，xfs等，都是给磁盘设计的，都用到了page cache来缓存磁盘上的数据来提高性能。但是，对于PMEM设备来说，它的访问延迟已经和内存接近了，为什么还需要内存中的page cache呢?所以，目前Linux Kernel中对这一块最大的改进就是支持DAX(Direct Access)。一句话解释DAX，就是DAX bypass了page cache。无论读写都是直接操作PMEM上的数据。DAX需要在文件系统层面支持，如果要使用DAX，那么需要在mount文件系统时传入“-o dax”参数，比如：

1 /dev/pmem0 on /mnt type xfs (rw,relatime,seclabel,attr2,dax,inode64,noquota)

DAX极大地提高了文件系统在PMEM设备上的性能，但是还有一些问题没有解决，比如：1. 文件系统的metadata还是需要使用page cache或buffer cache。2. “-o dax”mount option是对整个文件系统的，不能做更细粒度的控制。3. 没有一个API来告诉应用访问的文件是不是可以DAX访问的。虽然DAX还有这些问题，但是目前DAX还是Linux Kernel中的主流使用方式。

PMEM用作NUMA node

既然PMEM就是memory，只是带宽和latency上差一点，那么自然会想到能不能就把PMEM当做memory用呢?答案当然是可以的。目前支持SRAT或者HMAT的硬件，都可以把PMEM识别为一个或多个NUMA node。Dave Hansen的这组patch，Allow persistent memory to be used like normal RAM，就是通过memory hotplug的方式把PMEM添加到Linux的buddy allocator里面。

新添加的PMEM会以一个或多个NUMA node的形式出现，Linux Kernel就可以分配PMEM上的memory，这样和使用一般DRAM没什么区别。目前看这组patch已经没有什么blocking issues，不出什么问题的话，很快就会合并进入内核主线。但是，到这里只是解决了第一步的问题，怎么把PMEM“用好”的问题还没有解决。比如，当内核分配内存时，如果从PMEM上分配了memory，并且这块内存上的数据是被经常访问的，那么由于物理特性上的差异，一般应>用都会体会到性能的下降。那么怎么更明智的使用PMEM就是一个亟待解决的问题。

吴峰光的一组patch，PMEM NUMA node and hotness accounting/migration，来尝试解决这个问题。这组patch主要提供了下面几个功能：1. 隔离DRAM和PMEM。为PMEM单独构造了一个zonelist，这样一般的内存分配是不会分配到PMEM上的。2. 跟踪内存的冷热。利用内核中已经有的idle page tracking功能(目前主线内核只支持系统全局的tracking)，在per process的粒度上跟踪内存的冷热。3. 利用现有的page reclaim，在reclaim时将冷内存迁移到PMEM上(只能迁移匿名页)。4. 利用一个userspace的daemon和idle page tracking，来将热内存(在PMEM上的)迁移到DRAM中。这组patch发到LKML以后，引来了很激烈的讨论。

主要集中在两个方面：

1. 为什么要单独构造一个zonelist把PMEM和DRAM分开?其实在这块，我们也遇到了相似的问题。我们在某些项目要求做到控制每个进程使用的DRAM和PMEM的比例(比如8：2)，但是目前的NUMA API做不到。目前的NUMA API只能控制从哪个node分配，但是不能控制比例，>比如mbind()，只能告诉进程这段VMA可以用哪些node，但是不能控制具体多少memory从哪个node来。要想做到更细粒度的控制，需要改造目前的NUMA API。而且目前memory hierarchy越来越复杂，比如device memory，这都是目前的NUMA API所不能很好解决的。

2. 能不能把冷热内存迁移通用化?冷热内存迁移这个方向是没有问题的，问题在于目前patch中的处理太过于PMEM specific了。内核中的NUMA balancing是把“热”内存迁移到最近的NUMA node来提高性能。但是却没有对“冷”内存的处理。所以能不能实现一种更通用的NUMA rebalancing?比如，在reclaim时候，不是直接reclaim内存，而是把内存迁移到一个远端的，或者空闲的，或者低速的NUMA node，类似于NUMA balancing所做的，只不过是往相反的方向。笔者的一组patch，Another Approach to Use PMEM as NUMA Node，就体现了这种思路。利用Kernel中>已经很成熟的memory reclaim路径把“冷”内存迁移到PMEM node中，NUMA Balancing访问到这个page的时候可以选择是否把这个页迁移回DRAM，相当于是一种比较粗粒度的“热”内存识别。

社区中还有一种更加激进的想法就是不区分PMEM和DRAM，在memory reclaim时候只管把“冷”内存迁移到最近的remote node，如果target node也有内存压力，那就在target node上做同样的迁移。但是这种方法有可能引入一个内存迁移“环”，导致内存在NUMA node中间不停地迁移，有可能引入unbounded time问题。而且一旦node增多，可能会迅速恶化问题。

在笔者看来，在内存回收方面还有一个更可能立竿见影的方案就是把PMEM用作swap设备或者swap文件。目前swap的最大问题就是传统磁盘的延迟问题，很容易造成系统无响应，这也是为什么有zswap这样的技术出现。PMEM的低延迟特性完全可以消除swap的延迟问题。在这个方面，我们也正在做一些探索和实验。

PMEM用作RAM(DRAM作为Cache)

这个标题看起来有点歧义，上面已经说了PMEM可以作为NUMA node使用，这不已经是作为RAM了吗?怎么这里还要说用作RAM?这就涉及到AEP的另一个用法了，那就是所谓的“memory mode”。当在memory mode时，DRAM>并不是和PMEM并列的，而是变成了PMEM透明的Cache，PMEM就成了DRAM。这时候PMEM和DRAM的关系就变成了DRAM和Cache的关系。而且，DRAM是一个direct mapped的Cache(这点很重要)。这时疑问就来了，这样不是更没有什么可做的?既不需要管理NUMA，也没有冷热内存的问题了，热的自然就被Cache了。是的，但是这会引入另外一个问题，就是Cache冲突的问题。上面已经提到，在这种情况下，DRAM是一个direct mapped的Cache，就是在同样索引下只有一个cache line命中，这样会带来比较严重的Cache冲突问题，从而降低Cache的命中率，带来性能问题。对于这个问题的详细解释，请参见这篇文章为了解决这个Cache冲突的问题，Dan Williams提出了这组patch，mm: Randomize free memory。这组patch的想法很简单，就是通过randomize free area的方式来降低Cache>冲突。目前这组patch已经合并入-mm tree，不出意外应该会在5.1时合并入内核主线。但是这种配置的问题就是不够灵活，需要在BIOS中配置，一旦配置不可在运行时更改。

NVDIMM专用文件系统

前面提到PMEM可以作为一个块设备部署文件系统，但是现在支持的文件系统，比如ext4，xfs等，在设计时更多的考虑了怎样针对磁盘优化。但是PMEM是性质完全不同的存储介质，虽然经过一些改造，这些传统的文件系统可以比较好的工作在PMEM上，但是还是会有很多不适合PMEM的地方，比如metadata还要经过page cache等。所以，NVDIMM专用文件系统就应用而生了。

NOVA

NOVA Filesystem就是专门为PMEM设计的文件系统。笔者对文件系统研究不深，而且对NOVA也没有很深入的研究，所以就不在这里班门弄斧了。感兴趣的读者可以参考NOVA的github link之前，NOVA曾发到LKML上，但是好像社区里的maintainer们没有时间仔细review一个新的文件系统，所以合入社区的努力暂时停止了，但是还在github上继续开发中。

ZUFS

ZUFS是来自于NetApp的一个项目，ZUFS的意思是Zero-copy User Filesystem。声称是实现了完全的zero-copy，甚至文件系统的metadata都是zero-copy的。ZUFS主要是为了PMEM设计，但是也可以支持传统的磁盘设备，相当于是FUSE的zero-copy版本，是对FUSE的性能的提升。目前作者正在尝试将ZUFS的kernel部分upstream，据他说RHEL已经同意将ZUFS作为一个module加入RHEL 8。