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 1
NVDIMM Enabling in SUSE Linux Enterprise Part 2
Persistent 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(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用作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的命中率，帶來效能問題。對於這個問題的詳細解釋，請參見這篇文章(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中配置，一旦配置不可在執行時更改。

NVDIMM專用檔案系統

前面提到PMEM可以作為一個塊裝置部署檔案系統，但是現在支援的檔案系統，比如ext4，xfs等，在設計時更多的考慮了怎樣針對磁碟最佳化。但是PMEM是性質完全不同的儲存介質，雖然經過一些改造，這些傳統的檔案
系統可以比較好的工作在PMEM上，但是還是會有很多不適合PMEM的地方，比如metadata還要經過page cache等。所以，NVDIMM專用檔案系統就應用而生了。

NOVA

NOVA Filesystem就是專門為PMEM設計的檔案系統。筆者對檔案系統研究不深，而且對NOVA也沒有很深入的研究，所以就不在這裡班門弄斧了。感興趣的讀者可以參考NOVA的github link(https://github.com/NVSL/linux-nova)
之前，NOVA曾發到LKML上，但是好像社群裡的maintainer們沒有時間仔細review一個新的檔案系統，所以合入社群的努力暫時停止了，但是還在github上繼續開發中。

ZUFS

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。