AEP簡介

AEP是Intel推出的一種新型的非易失Optane Memory設(shè)備，又被稱作Apache Pass，所以一般習慣稱作AEP。在這之前也有類似的設(shè)備稱作NVDIMM或PMEM，目前Linux創(chuàng)建的AEP設(shè)備節(jié)點也是叫做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看成一個類似于磁盤的塊設(shè)備，所以可以在PMEM設(shè)備上創(chuàng)建文件系統(tǒng)，使它看起來和一般的磁盤沒什么區(qū)別。但是設(shè)備的具體物理屬性完全不一樣，比如讀寫的latency，PMEM可以達到和DRAM接近的程度，磁盤當然是望塵莫及的。所以，這就帶來一個問題，眾所周知，一般在Linux上常見的文件系統(tǒng)，比如ext4，xfs等，都是給磁盤設(shè)計的，都用到了page cache來緩存磁盤上的數(shù)據(jù)來提高性能。但是，對于PMEM設(shè)備來說，它的訪問延遲已經(jīng)和內(nèi)存接近了，為什么還需要內(nèi)存中的page cache呢？所以，目前Linux Kernel中對這一塊最大的改進就是支持DAX（Direct Access）。一句話解釋DAX，就是DAX bypass了page cache。無論讀寫都是直接操作PMEM上的數(shù)據(jù)。DAX需要在文件系統(tǒng)層面支持，如果要使用DAX，那么需要在mount文件系統(tǒng)時傳入“-o dax”參數(shù)，比如：

1/dev/pmem0on/mnttypexfs(rw,relatime,seclabel,attr2,dax,inode64,noquota)

DAX極大地提高了文件系統(tǒng)在PMEM設(shè)備上的性能，但是還有一些問題沒有解決，比如：1. 文件系統(tǒng)的metadata還是需要使用page cache或buffer cache。2. “-o dax”mount option是對整個文件系統(tǒng)的，不能做更細粒度的控制。3. 沒有一個API來告訴應(yīng)用訪問的文件是不是可以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的形式出現(xiàn)，Linux Kernel就可以分配PMEM上的memory，這樣和使用一般DRAM沒什么區(qū)別。目前看這組patch已經(jīng)沒有什么blocking issues，不出什么問題的話，很快就會合并進入內(nèi)核主線。但是，到這里只是解決了第一步的問題，怎么把PMEM“用好”的問題還沒有解決。比如，當內(nèi)核分配內(nèi)存時，如果從PMEM上分配了memory，并且這塊內(nèi)存上的數(shù)據(jù)是被經(jīng)常訪問的，那么由于物理特性上的差異，一般應(yīng)>用都會體會到性能的下降。那么怎么更明智的使用PMEM就是一個亟待解決的問題。
吳峰光的一組patch，PMEM NUMA node and hotness accounting/migration，來嘗試解決這個問題。這組patch主要提供了下面幾個功能：1. 隔離DRAM和PMEM。為PMEM單獨構(gòu)造了一個zonelist，這樣一般的內(nèi)存分配是不會分配到PMEM上的。2. 跟蹤內(nèi)存的冷熱。利用內(nèi)核中已經(jīng)有的idle page tracking功能（目前主線內(nèi)核只支持系統(tǒng)全局的tracking），在per process的粒度上跟蹤內(nèi)存的冷熱。3. 利用現(xiàn)有的page reclaim，在reclaim時將冷內(nèi)存遷移到PMEM上（只能遷移匿名頁）。4. 利用一個userspace的daemon和idle page tracking，來將熱內(nèi)存（在PMEM上的）遷移到DRAM中。這組patch發(fā)到LKML以后，引來了很激烈的討論。
主要集中在兩個方面：
1. 為什么要單獨構(gòu)造一個zonelist把PMEM和DRAM分開？其實在這塊，我們也遇到了相似的問題。我們在某些項目要求做到控制每個進程使用的DRAM和PMEM的比例（比如8：2），但是目前的NUMA API做不到。目前的NUMA API只能控制從哪個node分配，但是不能控制比例，>比如mbind()，只能告訴進程這段VMA可以用哪些node，但是不能控制具體多少memory從哪個node來。要想做到更細粒度的控制，需要改造目前的NUMA API。而且目前memory hierarchy越來越復(fù)雜，比如device memory，這都是目前的NUMA API所不能很好解決的。
2. 能不能把冷熱內(nèi)存遷移通用化？冷熱內(nèi)存遷移這個方向是沒有問題的，問題在于目前patch中的處理太過于PMEM specific了。內(nèi)核中的NUMA balancing是把“熱”內(nèi)存遷移到最近的NUMA node來提高性能。但是卻沒有對“冷”內(nèi)存的處理。所以能不能實現(xiàn)一種更通用的NUMA rebalancing？比如，在reclaim時候，不是直接reclaim內(nèi)存，而是把內(nèi)存遷移到一個遠端的，或者空閑的，或者低速的NUMA node，類似于NUMA balancing所做的，只不過是往相反的方向。筆者的一組patch，Another Approach to Use PMEM as NUMA Node，就體現(xiàn)了這種思路。利用Kernel中>已經(jīng)很成熟的memory reclaim路徑把“冷”內(nèi)存遷移到PMEM node中，NUMA Balancing訪問到這個page的時候可以選擇是否把這個頁遷移回DRAM，相當于是一種比較粗粒度的“熱”內(nèi)存識別。
社區(qū)中還有一種更加激進的想法就是不區(qū)分PMEM和DRAM，在memory reclaim時候只管把“冷”內(nèi)存遷移到最近的remote node，如果target node也有內(nèi)存壓力，那就在target node上做同樣的遷移。但是這種方法有可能引入一個內(nèi)存遷移“環(huán)”，導(dǎo)致內(nèi)存在NUMA node中間不停地遷移，有可能引入unbounded time問題。而且一旦node增多，可能會迅速惡化問題。
在筆者看來，在內(nèi)存回收方面還有一個更可能立竿見影的方案就是把PMEM用作swap設(shè)備或者swap文件。目前swap的最大問題就是傳統(tǒng)磁盤的延遲問題，很容易造成系統(tǒng)無響應(yīng)，這也是為什么有zswap這樣的技術(shù)出現(xiàn)。PMEM的低延遲特性完全可以消除swap的延遲問題。在這個方面，我們也正在做一些探索和實驗。

PMEM用作RAM（DRAM作為Cache）

這個標題看起來有點歧義，上面已經(jīng)說了PMEM可以作為NUMA node使用，這不已經(jīng)是作為RAM了嗎？怎么這里還要說用作RAM？這就涉及到AEP的另一個用法了，那就是所謂的“memory mode”。當在memory mode時，DRAM>并不是和PMEM并列的，而是變成了PMEM透明的Cache，PMEM就成了DRAM。這時候PMEM和DRAM的關(guān)系就變成了DRAM和Cache的關(guān)系。而且，DRAM是一個direct mapped的Cache（這點很重要）。這時疑問就來了，這樣不是更沒有什么可做的？既不需要管理NUMA，也沒有冷熱內(nèi)存的問題了，熱的自然就被Cache了。是的，但是這會引入另外一個問題，就是Cache沖突的問題。上面已經(jīng)提到，在這種情況下，DRAM是一個direct mapped的Cache，就是在同樣索引下只有一個cache line命中，這樣會帶來比較嚴重的Cache沖突問題，從而降低Cache的命中率，帶來性能問題。對于這個問題的詳細解釋，請參見這篇文章為了解決這個Cache沖突的問題，Dan Williams提出了這組patch，mm: Randomize free memory。這組patch的想法很簡單，就是通過randomize free area的方式來降低Cache>沖突。目前這組patch已經(jīng)合并入-mm tree，不出意外應(yīng)該會在5.1時合并入內(nèi)核主線。但是這種配置的問題就是不夠靈活，需要在BIOS中配置，一旦配置不可在運行時更改。

NVDIMM專用文件系統(tǒng)

前面提到PMEM可以作為一個塊設(shè)備部署文件系統(tǒng)，但是現(xiàn)在支持的文件系統(tǒng)，比如ext4，xfs等，在設(shè)計時更多的考慮了怎樣針對磁盤優(yōu)化。但是PMEM是性質(zhì)完全不同的存儲介質(zhì)，雖然經(jīng)過一些改造，這些傳統(tǒng)的文件系統(tǒng)可以比較好的工作在PMEM上，但是還是會有很多不適合PMEM的地方，比如metadata還要經(jīng)過page cache等。所以，NVDIMM專用文件系統(tǒng)就應(yīng)用而生了。

NOVA

NOVA Filesystem就是專門為PMEM設(shè)計的文件系統(tǒng)。筆者對文件系統(tǒng)研究不深，而且對NOVA也沒有很深入的研究，所以就不在這里班門弄斧了。感興趣的讀者可以參考NOVA的github link之前，NOVA曾發(fā)到LKML上，但是好像社區(qū)里的maintainer們沒有時間仔細review一個新的文件系統(tǒng)，所以合入社區(qū)的努力暫時停止了，但是還在github上繼續(xù)開發(fā)中。

ZUFS

ZUFS是來自于NetApp的一個項目，ZUFS的意思是Zero-copy User Filesystem。聲稱是實現(xiàn)了完全的zero-copy，甚至文件系統(tǒng)的metadata都是zero-copy的。ZUFS主要是為了PMEM設(shè)計，但是也可以支持傳統(tǒng)的磁盤設(shè)備，相當于是FUSE的zero-copy版本，是對FUSE的性能的提升。目前作者正在嘗試將ZUFS的kernel部分upstream，據(jù)他說RHEL已經(jīng)同意將ZUFS作為一個module加入RHEL 8。