AEP簡(jiǎn)介

AEP是Intel推出的一種新型的非易失Optane Memory設(shè)備，又被稱作Apache Pass，所以一般習(xí)慣稱作AEP。在這之前也有類似的設(shè)備稱作NVDIMM或PMEM，目前Linux創(chuàng)建的AEP設(shè)備節(jié)點(diǎn)也是叫做pmem（如/dev/pmem0），所以本文中NVDIMM或PMEM都指AEP。但是本文不是為了科普AEP，如果想了解AEP的一些基本知識(shí)，可以參考以下幾篇文章：NVDIMM Enabling in SUSE Linux Enterprise Part 1NVDIMM Enabling in SUSE Linux Enterprise Part 2Persistent Memory Wiki

DAX

目前Linux Kernel中主要把PMEM看成一個(gè)類似于磁盤的塊設(shè)備，所以可以在PMEM設(shè)備上創(chuàng)建文件系統(tǒng)，使它看起來和一般的磁盤沒什么區(qū)別。但是設(shè)備的具體物理屬性完全不一樣，比如讀寫的latency，PMEM可以達(dá)到和DRAM接近的程度，磁盤當(dāng)然是望塵莫及的。所以，這就帶來一個(gè)問題，眾所周知，一般在Linux上常見的文件系統(tǒng)，比如ext4，xfs等，都是給磁盤設(shè)計(jì)的，都用到了page cache來緩存磁盤上的數(shù)據(jù)來提高性能。但是，對(duì)于PMEM設(shè)備來說，它的訪問延遲已經(jīng)和內(nèi)存接近了，為什么還需要內(nèi)存中的page cache呢？所以，目前Linux Kernel中對(duì)這一塊最大的改進(jìn)就是支持DAX（Direct Access）。一句話解釋DAX，就是DAX bypass了page cache。無論讀寫都是直接操作PMEM上的數(shù)據(jù)。DAX需要在文件系統(tǒng)層面支持，如果要使用DAX，那么需要在mount文件系統(tǒng)時(shí)傳入“-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是對(duì)整個(gè)文件系統(tǒng)的，不能做更細(xì)粒度的控制。3. 沒有一個(gè)API來告訴應(yīng)用訪問的文件是不是可以DAX訪問的。雖然DAX還有這些問題，但是目前DAX還是Linux Kernel中的主流使用方式。

PMEM用作NUMA node

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

PMEM用作RAM（DRAM作為Cache）

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

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

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

NOVA

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

ZUFS

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