宋寶華： ARM64 Linux內(nèi)核頁表的塊映射

內(nèi)核文檔 Documentation/arm64/memory.rst 描述了 ARM64 Linux 內(nèi)核空間的內(nèi)存映射情況，應(yīng)該是此方面最權(quán)威文檔。

以典型的 4K 頁和 48 位虛擬地址為例，整個(gè)內(nèi)核空間的虛擬地址分布如下：

從 ffff000000000000 到 ffff7fffffffffff 是一段針對(duì)物理地址的線性映射區(qū)，最大支持 128TB 的物理地址空間，這一段地址非常類似 ARM32 的 low memory 映射區(qū)。

我們看看這種情況下的頁表，我們既可以用最終的【20:12】對(duì)應(yīng)的 PTE 映射項(xiàng)，以 4K 為單位，進(jìn)行虛擬地址到物理地址的映射；又可以以【29:21】對(duì)應(yīng)的 PMD 映射項(xiàng)，以 2M 為單位，進(jìn)行虛擬地址到物理地址的映射。

對(duì)于用戶空間的虛擬地址而言，當(dāng)我們進(jìn)行的是 PMD 映射的時(shí)候，我們得到的是 Huge Page，ARM64 的 2MB 的 huge page，在虛擬和物理上都連續(xù)，它在實(shí)踐工程中的好處是，可以減小 TLB miss，因?yàn)?，如果進(jìn)行了 2MB 的映射，整個(gè) 2MB 不再需要 PTE，映射關(guān)系大為減小。

對(duì)于內(nèi)核空間而言，從 ffff000000000000 到 ffff7fffffffffff 的這段虛擬地址，如果與物理地址進(jìn)行的是一種 PMD 映射的話，顯然也可以達(dá)到同樣的效果。但是，這不意味著它們就是 Huge Page。眾所周知，內(nèi)核開機(jī)把物理地址往虛擬地址進(jìn)行線性映射，并不意味著這片內(nèi)存被內(nèi)核拿走了，它只是進(jìn)行了一種映射，以便日后調(diào)用 kmalloc()，get_free_pages()等 API 申請(qǐng)的內(nèi)存是直接已經(jīng)有虛實(shí)映射的。所以，即便內(nèi)核進(jìn)行的就是 PMD 映射，在內(nèi)存的分割上，還是可以以 4K 為單位的：

所以，即便我們?cè)趦?nèi)核空間進(jìn)行 PMD 映射，里面的每個(gè)藍(lán)色圓圈（一個(gè) 4K 頁），還是可以被單獨(dú)分配的，這種分配可以是 kmalloc、vmalloc，用戶態(tài)的 malloc 等。內(nèi)核態(tài)進(jìn)行的 PMD 映射，不意味著相關(guān)的 2MB 成為了 huge page，它純粹只是為了服務(wù)于當(dāng)內(nèi)核以線性映射的虛擬地址訪問該物理地址的時(shí)候（我們認(rèn)為內(nèi)核大多數(shù)時(shí)候是用這個(gè)線性映射的虛擬地址的），減小 TLB miss。

當(dāng)然，更牛逼的情況下，內(nèi)核應(yīng)該也可以直接用【38:30】位的 PUD 來進(jìn)行映射，這樣映射關(guān)系是 1GB 的，則整個(gè) 1GB 后面占 TLB 的時(shí)候，只需要占一個(gè)入口。

當(dāng)然，如果用戶態(tài)的虛實(shí)映射是這樣的，用戶實(shí)際得到了一個(gè) 1GB 的巨頁。但是對(duì)于內(nèi)核的線性映射區(qū)域而言，即便我們進(jìn)行了 1GB 的 PUD 映射，這 1G 內(nèi)部就可以進(jìn)一步切割為 4KB 頁或者 2MB 的巨頁。記住：內(nèi)核態(tài)的線性映射區(qū)的映射只是個(gè)映射關(guān)系，不是個(gè)分配關(guān)系。比如下面的 1GB 的內(nèi)核線性映射的 1GB 區(qū)域，仍然可以被 4K 分配走，或者被用戶以 huge page 以 2MB 為單位分配走：

我們需要一個(gè)真實(shí)的調(diào)試手段來驗(yàn)證我們的想法，這個(gè)調(diào)試手段就是 PTDUMP（Page Table Dump），相關(guān)的代碼在 ARM64 內(nèi)核的：

arch/arm64/mm/ptdump.c 和 ptdump_debugfs.c

我們把它們?nèi)窟x中，這樣我們可以得到一個(gè) debugfs 接口：

/sys/kernel/debug/kernel_page_tables

來獲知內(nèi)核態(tài)頁表的情況。

我用 qemu 啟動(dòng)了一個(gè) 4GB 內(nèi)存的 ARM64 虛擬機(jī)，可以看到前 1GB 的虛擬地址空間大多數(shù)是 PMD 和 PTE 映射，后面的 3GB，全是 PUD 映射：

我的內(nèi)核啟動(dòng)參數(shù)加了 rodata=0：

$ cat?/proc/cmdline?root=/dev/vda2 rw console=ttyAMA0  ip=dhcp rodata=0

原因是內(nèi)核在幾種情況下，是不會(huì)做這種 PMD 和 PUD 映射的，相關(guān)代碼見于：

rodata_full 在默認(rèn)情況下總是成立的，它對(duì)應(yīng)著內(nèi)核的一個(gè) Config 選項(xiàng) CONFIG_RODATA_FULL_DEFAULT_ENABLED， "Apply r/o permissions of VM areas also to their linear aliases"，這個(gè)選項(xiàng)提高了內(nèi)核的安全性，但是減小了內(nèi)核的性能。

我在內(nèi)核啟動(dòng)參數(shù)加的 rodata=0 實(shí)際上是讓 rodata_full 為 false。如果我把這個(gè) kernel 啟動(dòng)選項(xiàng)去掉，我得到的內(nèi)核頁表是完全不一樣,線性映射區(qū)也全部是 PTE 映射：

最后，值得一提的是，不僅線性映射區(qū)可以使用 PMD 映射，vmemmap 映射區(qū)也是在 4K 頁面情況下，默認(rèn)用 PMD 映射的：

字節(jié)跳動(dòng)的宋牧春童鞋發(fā)了一個(gè) patchset，企圖在用戶分得巨頁的情況下，刪除巨頁內(nèi)部的 4KB 的小 page 占用的 page struct 的內(nèi)存消耗，這個(gè) patchset 在圣誕節(jié)前目前發(fā)到了 V11：

https://lore.kernel.org/linux-mm/20201222142440.28930-1-songmuchun@bytedance.com/

在這個(gè) patchset 中，它就需要拆分 vmemmap 的 PMD 映射為 PTE 映射:

這個(gè) patchset 的原理建立在，當(dāng)內(nèi)核以 4KB 分頁的時(shí)候，每個(gè) page 需要 64 字節(jié)的 page struct。但是，當(dāng)用戶把它分配為巨頁的時(shí)候，時(shí)候，我們不再需要一個(gè)個(gè) 4KB 單獨(dú)用 page struct 描述，對(duì)于這種 compound page 的情況，我們應(yīng)該可以把后面的 page struct 的內(nèi)存直接釋放掉，因?yàn)榍闆r完全是雷同的，這樣可以剩下不少內(nèi)存。

看到牧春童鞋從一個(gè)青蔥少年成長為這方面的大牛，我真地替他高興和驕傲。這同時(shí)也激勵(lì)我必須保持奮斗姿態(tài)，2021 年要不停歇地學(xué)習(xí)進(jìn)步，爭取趕上牧春童鞋。牧春童鞋在“Linux 閱碼場”這里還有一些精彩的文章：

宋牧春：Linux 設(shè)備樹文件結(jié)構(gòu)與解析深度分析(1)

宋牧春：Linux 設(shè)備樹文件結(jié)構(gòu)與解析深度分析(2)

宋牧春：多圖詳解 Linux 內(nèi)存分配器 slub

宋牧春：Linux 內(nèi)核內(nèi)存 corruption 檢查利器 KASAN 實(shí)現(xiàn)原理

后面我們期待牧春專門寫一篇文章來深入描述他的 patchset。