作者 | 宋寶華 責編 | 張文
頭圖 | CSDN 下載自視覺中國
內核文檔 Documentation/arm64/memory.rst 描述了 ARM64 Linux 內核空間的內存映射情況，應該是此方面最權威文檔。
以典型的 4K 頁和 48 位虛擬地址為例，整個內核空間的虛擬地址分布如下：
從 ffff000000000000 到 ffff7fffffffffff 是一段針對物理地址的線性映射區，最大支持 128TB 的物理地址空間，這一段地址非常類似 ARM32 的 low memory 映射區。
我們看看這種情況下的頁表，我們既可以用最終的【20:12】對應的 PTE 映射項，以 4K 為單位，進行虛擬地址到物理地址的映射；又可以以【29:21】對應的 PMD 映射項，以 2M 為單位，進行虛擬地址到物理地址的映射。
對於用戶空間的虛擬地址而言，當我們進行的是 PMD 映射的時候，我們得到的是 Huge Page，ARM64 的 2MB 的 huge page，在虛擬和物理上都連續，它在實踐工程中的好處是，可以減小 TLB miss。因為如果進行了 2MB 的映射，整個 2MB 不再需要 PTE，映射關係大為減小。
對於內核空間而言，從 ffff000000000000 到 ffff7fffffffffff 的這段虛擬地址，如果與物理地址進行的是一種 PMD 映射的話，顯然也可以達到同樣的效果。
但是，這不意味著它們就是 Huge Page。
眾所周知，內核開機把物理地址往虛擬地址進行線性映射，並不意味著這片內存被內核拿走了，它只是進行了一種映射，以便日後調用 kmalloc()，get_free_pages()等 API 申請的內存是直接已經有虛實映射的。所以，即便內核進行的就是 PMD 映射，在內存的分割上，還是可以以 4K 為單位的：
所以，即便我們在內核空間進行 PMD 映射，裡面的每個藍色圓圈（一個 4K頁），還是可以被單獨分配的，這種分配可以是 kmalloc、vmalloc，用戶態的 malloc 等。
內核態進行的 PMD 映射，不意味著相關的 2MB 成為了 huge page。
它純粹只是為了服務於當內核以線性映射的虛擬地址訪問該物理地址的時候（我們認為內核大多數時候是用這個線性映射的虛擬地址的），減小 TLB miss。
當然，更牛的情況下，內核應該也可以直接用【38:30】位的 PUD 來進行映射，這樣映射關係是 1GB 的，則整個 1GB 後面佔 TLB 的時候，只需要佔一個入口。
當然，如果用戶態的虛實映射是這樣的，用戶實際得到了一個 1GB 的巨頁。
但是對於內核的線性映射區域而言，即便我們進行了 1GB 的 PUD 映射，這 1G 內部就可以進一步切割為 4KB 頁或者 2MB 的巨頁。
記住：內核態的線性映射區的映射只是個映射關係，不是個分配關係。比如下面的 1GB 的內核線性映射的 1GB 區域，仍然可以被 4K 分配走，或者被用戶以 huge page 以 2MB 為單位分配走：
我們需要一個真實的調試手段來驗證我們的想法，這個調試手段就是 PTDUMP（Page Table Dump），相關的代碼在 ARM64 內核的：
arch/arm64/mm/ptdump.c和ptdump_debugfs.c
我們把它們全部選中，這樣我們可以得到一個 debugfs 接口：
/sys/kernel/debug/kernel_page_tables
來獲知內核態頁表的情況。
我用 qemu 啟動了一個 4GB 內存的 ARM64 虛擬機，可以看到前 1GB 的虛擬地址空間大多數是 PMD 和 PTE 映射，後面的 3GB，全是 PUD 映射：
我的內核啟動參數加了 rodata=0：
$ cat /proc/cmdline root=/dev/vda2 rw console=ttyAMA0 ip=dhcp rodata=0
原因是內核在幾種情況下，是不會做這種 PMD 和 PUD 映射的，相關代碼見於：
rodata_full 在默認情況下總是成立的，它對應著內核的一個 Config 選項 CONFIG_RODATA_FULL_DEFAULT_ENABLED， "Apply r/o permissions of VM areas also to their linear aliases"，這個選項提高了內核的安全性，但是減小了內核的性能。
我在內核啟動參數加的 rodata=0 實際上是讓 rodata_full 為 false。
如果我把這個 kernel 啟動選項去掉，我得到的內核頁表是完全不一樣,線性映射區也全部是 PTE 映射：
最後，值得一提的是，不僅線性映射區可以使用 PMD 映射，vmemmap 映射區也是在 4K 頁面情況下，默認用 PMD 映射的：
字節跳動的宋牧春童鞋發了一個 patchset，企圖在用戶分得巨頁的情況下，刪除巨頁內部的 4KB 的小 page 佔用的 page struct 的內存消耗，這個 patchset 在聖誕節前目前發到了 V11：
https://lore.kernel.org/linux-mm/20201222142440.28930-1-songmuchun@bytedance.com/
在這個 patchset 中，它就需要拆分 vmemmap 的 PMD 映射為 PTE 映射:
這個 patchset 的原理建立在，當內核以 4KB 分頁的時候，每個 page 需要 64 字節的 page struct。
但是，當用戶把它分配為巨頁的時候，我們不再需要一個個 4KB 單獨用 page struct 描述，對於這種 compound page 的情況，我們應該可以把後面的 page struct 的內存直接釋放掉，因為情況完全是雷同的，這樣可以省下不少內存。
看到牧春童鞋從一個青蔥少年成長為這方面的大牛，我真的替他高興和驕傲。這同時也激勵我必須保持奮鬥姿態，2021 年要不停歇地學習進步，爭取趕上牧春童鞋。
程式設計師如何避免陷入「內卷」、選擇什麼技術最有前景，中國開發者現狀與技術趨勢究竟是什麼樣？快來參與「2020中國開發者大調查」，更有豐富獎品送不停！