內核文檔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/[email protected]/
在這個patchset中，它就需要拆分vmemmap的PMD映射爲PTE映射:
這個patchset的原理建立在，當內核以4KB分頁的時候，每個page需要64字節的page struct。但是，當用戶把它分配爲巨頁的時候，時候，我們不再需要一個個4KB單獨用page struct描述，對於這種compound page的情況，我們應該可以把後面的page struct的內存直接釋放掉，因爲情況完全是雷同的，這樣可以剩下不少內存。
看到牧春童鞋從一個青蔥少年成長爲這方面的大牛，我真地替他高興和驕傲。這同時也激勵我必須保持奮鬥姿態，2021年要不停歇地學習進步，爭取趕上牧春童鞋。牧春童鞋在“Linux閱碼場”這裏還有一些精彩的文章：
宋牧春：Linux內核內存corruption檢查利器KASAN實現原理
後面我們期待牧春專門寫一篇文章來深入描述他的patchset。
（END）
更多精彩，盡在"Linux閱碼場"，掃描下方二維碼關注
別忘了分享、點贊或者在看哦~