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

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

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

1.1 fork

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

1.2 KSM

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

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

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

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

./a.out&./a.out

代碼：

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

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

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

我們可以看看pageshare的情況：

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

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

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

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

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

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

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

2.2 alloc_pages

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

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

2.3 /proc/sys/vm/compact_memory

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

echo 1 >/proc/sys/vm/compact_memory

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

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

compact_memory前后，buddy的情況：

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

2.4 huge page

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

這說(shuō)明透明巨頁(yè)是依賴(lài)于COMPACTION選項(xiàng)的。

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

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

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

比如下面的代碼我們想申請(qǐng)2MB的巨頁(yè)：

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

$ ./a.out Hugetlb:Cannotallocatememory

原因很簡(jiǎn)單，因?yàn)楝F(xiàn)在系統(tǒng)里面2MB的巨頁(yè)數(shù)量和free的數(shù)量都是0：

我們?nèi)绾巫屗暾?qǐng)成功呢？我們首先需要保證系統(tǒng)里面有一定數(shù)量的巨頁(yè)。這個(gè)時(shí)候我們可以寫(xiě)nr_hugepages得到巨頁(yè)：

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

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

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

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

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

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

透明巨頁(yè)聽(tīng)起來(lái)是比較牛逼的，因?yàn)樗恍枰阍趹?yīng)用程序里面通過(guò)MAP_HUGETLB來(lái)顯式地指定，但是實(shí)際的使用場(chǎng)景則未必這么牛逼。

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

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

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

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

運(yùn)行這個(gè)程序，并且得到它的pmap情況：

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

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

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

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

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

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

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

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

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

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

如果我們只對(duì)madvise的區(qū)域采用透明巨頁(yè)，則用戶(hù)的代碼可以這么寫(xiě)：

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

3.NUMABalancing引起的頁(yè)面遷移

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

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

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

這樣CPU24訪問(wèn)它的時(shí)候就會(huì)快很多。

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

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

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

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

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

但是30秒后，我們?cè)俅慰此腘UMA狀態(tài)，則發(fā)生了巨大的變化：

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

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

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

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