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

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

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

我們看看這種情況下的頁(yè)表，我們既可以用最終的【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頁(yè)），還是可以被單獨(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來(lái)進(jìn)行映射，這樣映射關(guān)系是1GB的，則整個(gè)1GB后面占TLB的時(shí)候，只需要占一個(gè)入口。

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

我們需要一個(gè)真實(shí)的調(diào)試手段來(lái)驗(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

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

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

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

$ cat/proc/cmdlineroot=/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)核頁(yè)表是完全不一樣,線性映射區(qū)也全部是PTE映射：

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

字節(jié)跳動(dòng)的宋牧春童鞋發(fā)了一個(gè)patchset，企圖在用戶分得巨頁(yè)的情況下，刪除巨頁(yè)內(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分頁(yè)的時(shí)候，每個(gè)page需要64字節(jié)的page struct。但是，當(dāng)用戶把它分配為巨頁(yè)的時(shí)候，時(shí)候，我們不再需要一個(gè)個(gè)4KB單獨(dú)用page struct描述，對(duì)于這種compound page的情況，我們應(yīng)該可以把后面的page struct的內(nèi)存直接釋放掉，因?yàn)榍闆r完全是雷同的，這樣可以剩下不少內(nèi)存。

責(zé)任編輯：xj

原文標(biāo)題：宋寶華： ARM64 Linux內(nèi)核頁(yè)表的塊映射

文章出處：【微信公眾號(hào)：Linuxer】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。