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/pmem0on/mnttypexfs(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。