論Linux的頁遷移（Page Migration）

對于用戶空間的應(yīng)用程序，我們通常根本不關(guān)心page的物理存放位置，因為我們用的是虛擬地址。所以，只要虛擬地址不變，哪怕這個頁在物理上從DDR的這里飛到DDR的那里，用戶都基本不感知。那么，為什么要寫一篇論述頁遷移的文章呢？

我認(rèn)為有2種場景下，你會關(guān)注這個Page遷移的問題：一個是在Linux里面寫實時程序，尤其是Linux的RT補(bǔ)丁打上后的情況，你希望你的應(yīng)用有一個確定的時延，不希望跑著跑著你的Page正在換位置而導(dǎo)致的延遲；再一個場景就是在用戶空間做DMA的場景，尤其是SVA（SharedVirtual Addressing），設(shè)備和CPU共享頁表，設(shè)備共享進(jìn)程的虛擬地址空間的場景，如果你DMA的page跑來跑去，勢必導(dǎo)致設(shè)備DMA的暫停，設(shè)備的傳輸性能出現(xiàn)嚴(yán)重抖動。這種場景下，設(shè)備的IOMMU和CPU的MMU會共享Page table：

1.CoW導(dǎo)致的頁面遷移

1.1 fork

典型的CoW（寫時拷貝）與fork()相關(guān)，當(dāng)父子兄弟進(jìn)程共享一部分page，而這些page本身又應(yīng)該是具備獨占屬性的時候，這樣的page會被標(biāo)注為只讀的，并在某進(jìn)程進(jìn)行寫動作的時候，產(chǎn)生page fault，其后內(nèi)核為其申請新的page。比如下面的代碼中，把10寫成20的進(jìn)程，在寫的過程中，會得到一頁新的內(nèi)存，data原本的虛擬地址會指向新的物理地址，從而發(fā)生page的migration。

1.2 KSM

其他的CoW的場景有KSM（Kernel same-page merging）。KSM會掃描多個進(jìn)程的內(nèi)存，如果發(fā)現(xiàn)有page的內(nèi)容是一模一樣的，則會將其merge為一個page，并將其標(biāo)注為寫保護(hù)的。之后對這個page執(zhí)行CoW，誰寫誰得到新的拷貝。比如，你在用qemu啟動一個虛擬機(jī)的時候，使用mem-merge=on，就可以促使多個VM共享許多page，從而有利于實現(xiàn)“超賣”。

sudo /x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1G -machinemem-merge=on

不過這本身也引起了虛擬機(jī)的一些安全漏洞，可被side-channel攻擊。

比如，把下面的代碼編譯為a.out，并且啟動兩份a.out進(jìn)程

./a.out&./a.out

代碼：

我們看到這2個a.out的內(nèi)存消耗情況如下：

但是，如果我們把中間的if0改為if 1，也就是暗示mmap()的這1MB內(nèi)存可能要merge，則耗費內(nèi)存的情況發(fā)生顯著變化：

耗費的內(nèi)存大大減小了。

我們可以看看pageshare的情況：

Merge發(fā)生在進(jìn)程內(nèi)部，也發(fā)生在進(jìn)程之間。

當(dāng)然，如果在page已經(jīng)被merge的情況下，誰再寫merge過的page，則會引起寫時拷貝，比如如下代碼中的p[0]=100這句話。

2.內(nèi)存規(guī)整導(dǎo)致的頁面遷移

2.1 CMA引起的內(nèi)存遷移

CMA (TheContiguousMemory Allocator)可運行作為dma_alloc_coherent()的后端，它的好處在于，CMA區(qū)域的空閑部分，可以被應(yīng)用程序拿來申請MOVABLE的page。如下圖中的一個CMA區(qū)域的紅色部分已經(jīng)被設(shè)備驅(qū)動通過dma_alloc_coherent()拿走，但是藍(lán)色部分目前被用戶進(jìn)程通過malloc()等形式拿走。

一旦設(shè)備驅(qū)動繼續(xù)通過dma_alloc_coherent()申請更多的內(nèi)存，則內(nèi)核必須從別的非CMA區(qū)域里面申請一些page，然后把藍(lán)色的區(qū)域往新申請的page移走。用戶進(jìn)程占有的藍(lán)色page發(fā)現(xiàn)了遷移。

CMA在內(nèi)核的配置選項中依賴于MMU，且會自動使能MIGRATION（Pagemigration）和MEMORY_ISOLATION：

2.2 alloc_pages

當(dāng)內(nèi)核使能了COMPACTION，則Linux的底層buddy分配器會在alloc_pages()中嘗試進(jìn)行內(nèi)存遷移以得到連續(xù)的大內(nèi)存。COMPACTION這個選項也會使能CMA一節(jié)提及的MIGRATION選項。

從代碼的順序上來看，alloc_pages()分配order比較高的連續(xù)內(nèi)存的時候，是優(yōu)先考慮COMPACTION，再次考慮RECLAIM的。

2.3 /proc/sys/vm/compact_memory

當(dāng)然，上面alloc_pages所提及的compaction也可以被用戶手動的觸發(fā)，觸發(fā)方式：

echo 1 >/proc/sys/vm/compact_memory

將1寫入compact_memory文件，則內(nèi)核會對各個zone進(jìn)行規(guī)整，以便能夠盡可能地提供連續(xù)內(nèi)存塊。

我的Ubuntu已經(jīng)運行了一段時間，內(nèi)存稍微有些碎片化了，我們來對比下手動執(zhí)行

compact_memory前后，buddy的情況：

可以清晰地看出來，執(zhí)行compact_memory后，DMA32 ZONE和NORMAL ZONE里面，order比較大的連續(xù)page數(shù)量都明顯增大了。

2.4 huge page

再次展開內(nèi)核的COMPACTION選型，你會發(fā)現(xiàn)COMPACTION會被透明巨頁自動選中：

這說明透明巨頁是依賴于COMPACTION選項的。

所謂透明巨頁，無非就是應(yīng)用程序在運行的時候，神不知鬼不覺地偷偷地就使用到了Hugepage的功能，這個過程對用戶是透明的。與透明對應(yīng)的無非就是不透明的巨頁，這種方式下，應(yīng)用程序需要顯示地告訴內(nèi)核我需要使用巨頁。

我們先來看看不透明的巨頁是怎么玩的？一般用戶程序可以這樣寫，在mmap里面會加上MAP_HUGETLB的Flag，當(dāng)然這個巨頁也必須是提前預(yù)設(shè)好的，否則mmap就會失敗。

ptr_ = mmap(NULL, memory_size_, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);

比如下面的代碼我們想申請2MB的巨頁：

程序執(zhí)行的時候會返回錯誤，打印如下：

$ ./a.out Hugetlb:Cannotallocatememory

原因很簡單，因為現(xiàn)在系統(tǒng)里面2MB的巨頁數(shù)量和free的數(shù)量都是0：

我們?nèi)绾巫屗暾埑晒δ兀课覀兪紫刃枰ＷC系統(tǒng)里面有一定數(shù)量的巨頁。這個時候我們可以寫nr_hugepages得到巨頁：

我們現(xiàn)在讓系統(tǒng)得到了10個大小為2048K的巨頁。

現(xiàn)在來重新運行a.out，就不在出錯了，而且系統(tǒng)里面巨頁的數(shù)量發(fā)生了變化：

Free的數(shù)量從10頁變成了9頁。

聰明的童鞋應(yīng)該想到了，當(dāng)我們嘗試預(yù)留巨頁的時候，它最終還是要走到buddy，假設(shè)系統(tǒng)里面沒有連續(xù)的大內(nèi)存，系統(tǒng)是否會進(jìn)行內(nèi)存遷移以幫忙規(guī)整出來巨頁呢？這顯然符合前面說的alloc_pages()的邏輯。從alloc_buddy_huge_page()函數(shù)的實現(xiàn)也可以看出這一點：

另外，這種巨頁的特點是“預(yù)留式”的，不會free給系統(tǒng)，也不會被swap。因此可有效防止用戶態(tài)DMA的性能抖動。對于DPDK這樣的場景，人們喜歡這種巨頁分配，減少了頁面的數(shù)量和TLB的miss，縮短了虛擬地址到物理地址的重定位的轉(zhuǎn)換時間，因此提高了性能。

當(dāng)然，我們在運行時通過寫nr_hugepages的方法設(shè)置巨頁，這種方法未必一定能夠成功。所以，工程中也可以考慮通過內(nèi)核啟動的bootargs來設(shè)置巨頁，這樣Linux開機(jī)的過程中，就可以直接從bootmem里面分配巨頁，而不必在運行時通過order較高的alloc_pages()來獲取。這個在內(nèi)核文檔的kernel-parameters.txt說的比較清楚，你可以在bootargs里面設(shè)置各種不同hugepagesize有多少個頁數(shù)：

透明巨頁聽起來是比較牛逼的，因為它不需要你在應(yīng)用程序里面通過MAP_HUGETLB來顯式地指定，但是實際的使用場景則未必這么牛逼。

使用透明巨頁的最激進(jìn)的方法莫過于把enabled和defrag都設(shè)置為always：

echo always >/sys/kernel/mm/transparent_hugepage/enabledechoalways>/sys/kernel/mm/transparent_hugepage/defrag

enabled寫入always暗示對所有的區(qū)域都盡可能使用透明巨頁，defrag寫入always暗示內(nèi)核會激進(jìn)地在用戶申請內(nèi)存的時候進(jìn)行內(nèi)存回收（RECLAIM）和規(guī)整（COMPACTION）來獲得THP（透明巨頁）。

我們來前面的例子代碼稍微進(jìn)行更改，mmap16MB內(nèi)存，并且去掉MAP_HUGETLB：

運行這個程序，并且得到它的pmap情況：

我們發(fā)現(xiàn)從00007f46b0744000開始，有16MB的anon內(nèi)存區(qū)域，顯然對應(yīng)著我們代碼里面的mmap(16*1024*1024)的區(qū)域。

我們進(jìn)一步最終/proc/15371/smaps，可以得到該區(qū)域的內(nèi)存分布情況：

顯然該區(qū)域是THPeligible的，并且獲得了透明巨頁。內(nèi)核文檔filesystems/proc.rst對THPeligible的描述如下：

"THPeligible" indicates whether the mapping is eligible for allocating THP pages - 1 if true, 0 otherwise. It just shows the current status.

透明巨頁的生成，顯然會涉及到前面的內(nèi)存COMPACTION過程。透明巨頁在實際的用戶場景里面，可能反而因為內(nèi)存的RECLAIM和COMPACTION而降低了性能，比如有些VMA區(qū)域的壽命很短申請完使用后很快釋放，或者某些使用大內(nèi)存的進(jìn)程是短命鬼，進(jìn)行規(guī)整花了很久，而跑起來就釋放了這部分內(nèi)存，顯然是不值得的。類似《權(quán)力的游戲》中的夜王，花了那么多季進(jìn)行內(nèi)存規(guī)整準(zhǔn)備干夜王這個透明巨頁，結(jié)果夜王上來就被秒殺了，你說我花了多時間追劇冤不冤？

所以，透明巨頁在實際的工程中，又引入了一個半透明的因子，就是內(nèi)核可以只針對用戶通過madvise()暗示了需要巨頁的區(qū)間進(jìn)行透明巨頁分配，暗示的時候使用的參數(shù)是MADV_HUGEPAGE：

所以，默認(rèn)情況下，許多系統(tǒng)會把enabled和defrag都設(shè)置為madvise：

echo madvise >/sys/kernel/mm/transparent_hugepage/enabledechomadvise>/sys/kernel/mm/transparent_hugepage/defrag

或者干脆把透明巨頁的功能關(guān)閉掉：

echo never >/sys/kernel/mm/transparent_hugepage/enabledechonever>/sys/kernel/mm/transparent_hugepage/defrag

如果我們只對madvise的區(qū)域采用透明巨頁，則用戶的代碼可以這么寫：

既然我都已經(jīng)這么寫代碼了，我還透明個什么鬼？所以，我寧可為了某種確定性，而去追求預(yù)留式的，非swap的巨頁了。

3.NUMABalancing引起的頁面遷移

在一個典型的NUMA系統(tǒng)中，存在多個NODE，很可能每個NODE都有CPU和Memory，NODE和NODE之間通過某種總線再互聯(lián)。下面中的NUMA系統(tǒng)有4個NODE，每個NODE有24個CPU和1個內(nèi)存，NODE之間通過紅線互聯(lián)：

在這樣的系統(tǒng)中，通常CPU訪問本地NODE節(jié)點的memory會比較快，而跨NODE訪問memory則會慢很多（紅色總線慢）。所以Linux的NUMA自動均衡機(jī)制，會嘗試將內(nèi)存遷移到正在訪問它的CPU節(jié)點所在的NODE，如下圖中綠色的memory經(jīng)常被CPU24訪問，但是它位于NODE0的memory：

則Linux內(nèi)核可能會將綠色內(nèi)存遷移到CPU24所在的本地memory：

這樣CPU24訪問它的時候就會快很多。

顯然NUMA_BALANCING也是依賴MIGRATION機(jī)制的：

下面我們來寫個多線程的程序，這個程序里面有28個線程（一個主線程，26個dummy線程執(zhí)行死循環(huán)，以及一個寫內(nèi)存的線程）：

我們開那么多線程的目的，無非是為了讓write_thread_start對應(yīng)的線程，盡可能地不被分配到主線程所在的NUMA節(jié)點。

這個程序的主線程最開始寫了64MB申請的內(nèi)存，30秒后，通過write_done=1來暗示write_thread_start()線程你可以開始寫了，write_thread_start()則會把這64MB也寫一遍，如果主線程和write_thread_start()線程不在一個NODE節(jié)點的話，內(nèi)存遷移就有可能發(fā)生。

這是我們剛開始2秒的時候獲得的該進(jìn)程的numastat，可以看出，這64MB內(nèi)存幾乎都在NODE3上面：

但是30秒后，我們再次看它的NUMA狀態(tài)，則發(fā)生了巨大的變化：

64MB內(nèi)存跑到NODE1上面去了。由此我們可以推斷，write_thread_start()線程應(yīng)該是在NODE1上面跑，從而引起了這個遷移的發(fā)生。

當(dāng)然，我們也可以通過numactl--cpunodebind=2類似的命令來規(guī)避這個問題，比如：

# numactl --cpunodebind=2 ./a.out

NUMA Balancing的原理是通過把進(jìn)程的內(nèi)存一部分一部分地周期性地進(jìn)行unmap（比如每次256MB），在頁表里面把掃描的部分的PTE設(shè)置為 “no access permission” ，以在其后訪問它的時候，強(qiáng)制產(chǎn)生pagefault，進(jìn)而探測page fault發(fā)生在本地NODE還是遠(yuǎn)端NODE，來獲知CPU和memory是否較遠(yuǎn)的。這說明，哪怕沒有真實的遷移發(fā)生，NUMA balancing也會導(dǎo)致進(jìn)程的內(nèi)存訪問出現(xiàn)Page fault。