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

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

1.CoW導致的頁面遷移

1.1 fork

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

1.2 KSM

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

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

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

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

./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ā)生在進程內(nèi)部，也發(fā)生在進程之間。

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

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

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

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

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

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

2.2 alloc_pages

當內(nèi)核使能了COMPACTION，則Linux的底層buddy分配器會在alloc_pages()中嘗試進行內(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

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

echo 1 >/proc/sys/vm/compact_memory

將1寫入compact_memory文件，則內(nèi)核會對各個zone進行規(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選項的。

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

我們先來看看不透明的巨頁是怎么玩的？一般用戶程序可以這樣寫，在mmap里面會加上MAP_HUGETLB的Flag，當然這個巨頁也必須是提前預設好的，否則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頁。

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

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

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

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

使用透明巨頁的最激進的方法莫過于把enabled和defrag都設置為always：

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

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

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

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

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

我們進一步最終/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)存的進程是短命鬼，進行規(guī)整花了很久，而跑起來就釋放了這部分內(nèi)存，顯然是不值得的。類似《權力的游戲》中的夜王，花了那么多季進行內(nèi)存規(guī)整準備干夜王這個透明巨頁，結(jié)果夜王上來就被秒殺了，你說我花了多時間追劇冤不冤？

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

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

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

或者干脆把透明巨頁的功能關閉掉：

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

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

既然我都已經(jīng)這么寫代碼了，我還透明個什么鬼？所以，我寧可為了某種確定性，而去追求預留式的，非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自動均衡機制，會嘗試將內(nèi)存遷移到正在訪問它的CPU節(jié)點所在的NODE，如下圖中綠色的memory經(jīng)常被CPU24訪問，但是它位于NODE0的memory：

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

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

顯然NUMA_BALANCING也是依賴MIGRATION機制的：

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

我們開那么多線程的目的，無非是為了讓write_thread_start對應的線程，盡可能地不被分配到主線程所在的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秒的時候獲得的該進程的numastat，可以看出，這64MB內(nèi)存幾乎都在NODE3上面：

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

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

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

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

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