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

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

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

1.1 fork

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

1.2 KSM

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

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

不過這本身也引起了虛擬機(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的情況下，誰再寫merge過的page，則會(huì)引起寫時(shí)拷貝，比如如下代碼中的p[0]=100這句話。

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

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

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

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

CMA在內(nèi)核的配置選項(xiàng)中依賴于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)。

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

2.3 /proc/sys/vm/compact_memory

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

echo 1 >/proc/sys/vm/compact_memory

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

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

compact_memory前后，buddy的情況：

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

2.4 huge page

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

這說明透明巨頁是依賴于COMPACTION選項(xiàng)的。

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

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

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

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

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

$ ./a.out Hugetlb:Cannotallocatememory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

顯然該區(qū)域是THPeligible的，并且獲得了透明巨頁。內(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.

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

所以，透明巨頁在實(shí)際的工程中，又引入了一個(gè)半透明的因子，就是內(nèi)核可以只針對(duì)用戶通過madvise()暗示了需要巨頁的區(qū)間進(jìn)行透明巨頁分配，暗示的時(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

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

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

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

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

3.NUMABalancing引起的頁面遷移

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

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

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

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

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

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

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

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

這是我們剛開始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)然，我們也可以通過numactl--cpunodebind=2類似的命令來規(guī)避這個(gè)問題，比如：

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

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