node
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 1
NVDIMM Enabling in SUSE Linux Enterprise Part 2
Persistent Memory Wikilinux
目前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”参数，好比：git
1 /dev/pmem0 on /mnt type xfs (rw,relatime,seclabel,attr2,dax,inode64,noquota)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中的主流使用方式。github
既然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(https://lore.kernel.org/linux-mm/1554955019-29472-1-git-send-email-yang.shi@linux.alibaba.com/)，就体现了这种思路。利用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能够做为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的命中率，带来性能问题。对于这个问题的详细解释，请参见这篇文章(http://www.nersc.gov/research-and-development/knl-cache-mode-performance-coe/)
为了解决这个Cache冲突的问题，Dan Williams提出了这组patch，mm: Randomize free memory。这组patch的想法很简单，就是经过randomize free area的方式来下降Cache>冲突。
目前这组patch已经合并入-mm tree，不出意外应该会在5.1时合并入内核主线。
可是这种配置的问题就是不够灵活，须要在BIOS中配置，一旦配置不可在运行时更改。app
前面提到PMEM能够做为一个块设备部署文件系统，可是如今支持的文件系统，好比ext4，xfs等，在设计时更多的考虑了怎样针对磁盘优化。可是PMEM是性质彻底不一样的存储介质，虽然通过一些改造，这些传统的文件
系统能够比较好的工做在PMEM上，可是仍是会有不少不适合PMEM的地方，好比metadata还要通过page cache等。因此，NVDIMM专用文件系统就应用而生了。dom
NOVA Filesystem就是专门为PMEM设计的文件系统。笔者对文件系统研究不深，并且对NOVA也没有很深刻的研究，因此就不在这里班门弄斧了。感兴趣的读者能够参考NOVA的github link(https://github.com/NVSL/linux-nova)
以前，NOVA曾发到LKML上，可是好像社区里的maintainer们没有时间仔细review一个新的文件系统，因此合入社区的努力暂时中止了，可是还在github上继续开发中。性能
ZUFS(https://github.com/NetApp/zufs-zuf/blob/zuf-upstream/Documentation/filesystems/zufs.txt)是来自于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。优化