ARM64 Linux 内核页表的块映射

原标题：ARM64 Linux 内核页表的块映射

作者 | 宋宝华责编 | 张文

头图 | CSDN 下载自视觉中国

出品 | CSDN（ID：CSDNnews）

内核文档 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：

原因是内核在几种情况下，是不会做这种 PMD 和 PUD 映射的，相关代码见于：

rodata_full 在默认情况下总是成立的，它对应着内核的一个 Config 选项 CONFIG_RODATA_FULL_DEFAULT_ENABLED， “Apply r/o permissions of VM areas also to their linear aliases”， 这个选项提高了内核的安全性，但是减小了内核的性能。