歡迎光臨
每天分享高質量文章

Linux Kernel中AEP的現狀和發展

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。

本文轉自核心月談

贊(0)

分享創造快樂