1. 从一个看似基础的问题说起页表到底在忙什么如果你翻过几本讲内核的书大概率会看到一句话Linux通过页表实现虚拟内存到物理内存的映射。这句话每个字都认识但合在一起很多人是懵的。更常见的情况是你能背出四级页表的名字PGD、PUD、PMD、PTE也能说出页表项里有读、写、执行几个权限位可真让你解释为什么需要这么多层级、缺一不可或者让你基于一个实际的内核崩溃现场倒推出是哪一级页表出了问题很多人就卡住了。我在最开始学内核的时候也栽在这上面。先说一个我印象很深的案例有一台x86_64服务器跑的4.18内核业务进程在某个瞬间突然被SIGSEGV杀掉/var/log/messages里没有任何硬件报错dmesg里只有一条很普通的segfault at ... ip ... error 4。用gdb挂上去看用户的堆栈完全正常指令地址也是合理的代码段地址。后来排查了很久才发现问题出在一个驱动程序里它在ioctl路径中直接修改了用户态传入的buffer地址并且没有做access_ok校验也没有通过copy_from_user做拷贝而是直接拿用户地址去做内核态的memcpy。在特定布局下这个用户地址对应的页表项是一个只读映射硬件在页表遍历阶段就拦下了这次写入所以连一点数据都没污染进程直接被杀了。换句话说整个系统的稳定靠的就是页表权限位在硬件层面拦了一道。所以我想从页表到底在忙什么这个问题开始把整个机制拆开讲清楚。这篇文章既是给刚接触内核的人看的入门逻辑梳理也是给我这种工作中经常要和内存调优、问题排查打交道的人做一个完整的技术复盘。我要讲的是x86_64架构下Linux的页表实现从硬件行为到内核代码再到实际调试方法一次说透。2. 为什么CPU和操作系统联手搞出了层级页表2.1 没有页表的世界会怎样先做个思想实验。假设系统里只有物理内存程序直接使用物理地址访问内存即所谓的实模式。这当然能跑但会有几个致命问题第一程序A和程序B如何隔离如果A把数据写到物理地址1000B也往1000写俩进程就互相踩踏了。第二程序加载的地址必须提前知道链接器必须把代码里的每一个地址都安排成物理地址程序一旦编译就无法移动这叫重定位问题。第三物理内存总共就那么多程序想用超过物理内存大小的空间怎么办换入换出没有统一管理机制。页表的出现核心目的就是解决这三个问题隔离、重定位、按需换入换出。虚拟机内存的机制听起来抽象但本质上是让每个进程都以为自己拥有一整块连续、独立、从0到很大范围的地址空间而这块假地址到真地址的翻译工作由CPU的MMU内存管理单元配合操作系统维护的页表共同完成。应用程序根本不需要关心物理内存长什么样。2.2 分页的核心思想把地址空间切成格子分页的思想很朴素把虚拟地址空间和物理地址空间都切成固定大小的格子虚拟地址空间里的一个格子映射到物理地址空间里任意一个格子或者干脆不映射。映射关系存在一张表里CPU每次访问内存时用虚拟地址的索引部分去查表拿到物理地址的起始位置再加上偏移量得到最终物理地址。这个格子的大小在x86_64上默认是4KB所以一个虚拟地址可以被切成两段高20位是页号索引低12位是页内偏移。2的20次方就是1048576个页每个页需要一个页表项记录映射关系每个页表项8字节所以一张完整的单级页表需要8MB内存。假设系统里有100个进程光页表就要占800MB每访问一次内存都要来一次全表扫描性能也是灾难。2.3 多级结构的数学逻辑为什么是4级为了解决单级页表太浪费的问题操作系统引入了多级页表。这就好比你要在一本很厚的书里找内容与其从头一页一页翻单级线性查找不如先看目录找到章节一级索引再看节找到小节二级索引最终定位到具体页三级索引。目录本身只占很小空间而且如果你这一章根本不存在那连子目录都不需要建直接省掉一大片空间。x86_64架构的分页层级是4级从上到下依次是层级缩写全称管理地址宽度x86_64每级索引位数第1级PGDPage Global Directory47-39位9位第2级PUDPage Upper Directory38-30位9位第3级PMDPage Middle Directory29-21位9位第4级PTEPage Table Entry20-12位9位每个索引占9位是因为每级目录包含512个表项2^9 512每个表项8字节正好占一个4KB页。虚拟地址的布局就是前16位未使用x86_64当前只实现48位虚拟地址然后是9位PGD索引、9位PUD索引、9位PMD索引、9位PTE索引、最后12位页内偏移。CPU访问一次内存实际上要经历最多4次内存读取每次读一个页表项再加上TLB缓存帮忙才能拿到物理地址。多一次内存读取看似开销很大但换来的好处是一个进程即使虚拟地址空间再大真正使用的页表目录也不会全部创建。一个进程只访问了很少的内存页就只需要极少数的页目录项和页表项内存开销比单级8MB小得多。2.4 TLB多级查表的性能救星多级页表的代价是访问速度。原本一次访存搞定的事现在变成最多4次页表查询加1次真正访存那就是5次。但CPU设计者们早就想过这个问题方案就是TLBTranslation Lookaside Buffer一个地址翻译缓存。TLB里保存着最近用过的虚拟页号到物理页号的对应关系。一般情况下CPU在查页表之前会先去TLB里找命中就直接得到物理地址这个速度比查内存快好几个数量级极大弥补了多级页表带来的开销。但要注意一个坑如果进程频繁切换或者使用了大量不同地址的内存TLB命中率会下降性能就会掉回去。这也是为什么内核代码里会有很多TLB shootdown的处理逻辑——一个CPU改了页表需要通知其他CPU刷新TLB否则其他核心可能还在用旧的缓存地址轻则数据不一致重则直接崩溃。这类bug在写驱动时经常遇到尤其在使用vmalloc、mmap等涉及页表修改的接口时改完必须注意TLB的同步问题。真正解决问题要分清哪些是内核帮你处理的哪些需要你自己手动处理。3. 逐级拆解x86_64页表从PGD到PTE的每个标志位3.1 页目录和页表项的布局在x86_64的Linux实现中PGD、PUD、PMD、PTE这四级其实每一级都只是一个个64位的表项数组。每一级页表的基地址存放在CPU的CR3寄存器里。当进程切换时内核会更新CR3指向新进程的PGD基地址这样CPU的MMU自然就知道该用哪张页表了。换句话说页表就是操作系统在内存里建好的一张张表CPU只是按图索骥的执行者。每个页表项的低12位是标志位区域高52位是物理地址的高位部分。由于页表项本身只能给出页帧号页内偏移由虚拟地址末12位直接决定所以物理页必须是4KB对齐的。这个低位标志位高位物理地址的布局是整个分页机制的核心理解它之后就能自己解析很多内存问题了。3.2 常见的页表标志位及含义标志位名称含义与典型坑bit 0Present该页是否在内存中。为0就触发缺页异常属于按需换页的核心。如果这一位为0后面的物理地址无意义可以存内核自己的数据bit 1R/W可写标志。为0则只读。数据段、代码段通常只读堆栈页为可写。改写这里可以实现写时拷贝、保护只读数据bit 2U/S用户态还是内核态可访问。为0则只有内核态能访问这是用户态和内核态隔离的基石bit 3PWT/Page Write Through写透缓存控制。通常用不到驱动开发偶尔会设置bit 4PCD/Page Cache Disable禁用该页缓存。映射设备寄存器内存时经常用到避免CPU缓存干扰设备读写bit 5Accessed页面是否被访问过。硬件自动设置内核定期扫描可以统计热度用于内存回收bit 6Dirty页面是否被写入过。脏页标记对刷盘和swap很关键bit 7PAT页属性表扩展控制内存类型一般不用关心bit 8GlobalTLB全局页标志。内核常用的线性映射区经常打开避免TLB频繁失效bit 9-11软件可用位内核自定义用途比如记录该页是否被swap占用、是否mlock等我来举一个实际例子有一次排查系统负载飙升用perf去看内核热点发现大量时间花在do_page_fault里。原因是一个应用程序通过mmap映射了一个文件然后用指针逐个字节访问由于文件是按页加载的每次访问新页都会触发缺页异常。后来改成按页缓存读取系统负载立刻降下来了。这个案例说明缺页异常处理是有代价的每次缺页都要进入内核态、查找页表、分配物理页、建立映射、刷新TLB这一套动作比直接访存贵一到两个数量级。所以页表的设计不只是空间换时间它还在操作系统的各个层面产生连锁影响。3.3 大页HugePage多级目录的旁路既然多级页表是为了节省空间而设计的那它自然也有一个反向优化大页。如果我们已经知道某个区域的映射是连续的、巨大的我们就可以跳过中间的几级目录用一个更高级别的目录项直接指向一个2MB甚至1GB的物理页块。这类页表项称为HugePage。2MB大页由PMD直接指向2MB物理块跳过PTE这一级。1GB大页由PUD直接指向1GB物理块跳过PMD和PTE两级。大页的好处至少有四个减少了页表遍历级数降低TLB miss概率减少了页表占用的内存数量缺页次数显著减少一个2MB大页就相当512个普通页对数据库、JVM这种大量连续内存访问的场景性能提升客观存在。但大页不是没有代价。分配大页必须是连续的物理内存在长时间运行、内存碎片较多的系统上分配1GB大页可能会失败。而且大页的管理粒度大不适合需要精细内存隔离的场景。在实际生产里我一般建议数据库实例和JVM进程优先考虑透明大页THP或显式配置HugePages但要注意THP的khugepaged线程在后台做内存规整时可能造成偶发延迟抖动这在响应时间敏感的业务中是很常见的一类问题。我们后来是直接在数据库服务的启动脚本里加echo never /sys/kernel/mm/transparent_hugepage/enabled关闭了THP换成了显式的HugePages配置抖动问题才彻底消失。4. Linux内核如何使用和操纵页表4.1 每进程页表和内核的共享魔法每个进程都有自己的PGD但这不代表每个进程都要复制一份完整的内核页表。在x86_64 Linux中内核地址空间高位部分从0xffff888000000000开始对所有进程都是一样的。这个区域在内核初始化时被建立起来并被所有进程的PGD所引用。关键内存布局大致是这样地址范围用途映射类型0xffff888000000000 - 0xffffc87fffffffff直接物理映射区linear mapping通过phys_to_virt直接计算偏移固定0xffffc90000000000 - 0xffffe8ffffffffffvmalloc区动态映射区域每次调用vmalloc都会修改页表0xffffea0000000000 - 0xffffeaffffffffff内存热插拔、memmap区域管理struct page数组0xffffffff80000000 - 0xffffffff9fffffff内核文本、rodata、数据段编译期链接地址映射固定进程切换时内核需要做的页表切换其实就是切换PGD和刷新TLB。但因为内核空间共享TLB刷新时可以保留内核地址空间的Global页只刷新用户空间的条目这就是上面提到bit 8 Global标志存在的意义。内核里切换进程上下文时调用的switch_mm_irqs_off函数就是负责这一系列操作的。4.2 缺页异常页表不存在的补救机制CPU访问一个虚拟地址时如果页表查下去发现某个Present位为0就会触发一个缺页异常Page Fault。缺页异常的处理路径并不简单内核需要判断这个缺页是合理缺页还是非法访问。合理缺页包括三种情况缺页类型发生原因内核响应首次访问匿名页进程申请了内存但物理页还没分配分配一个物理页清零建立映射返回用户态文件映射页mmap映射的文件内容还没读入内存从文件系统读取对应页建立映射写时拷贝fork之后父子进程共享只读页有一方要写复制物理页修改页表为可写返回用户态非法访问则包括访问了未映射地址NULL、栈溢出等、越过了用户态权限限制、对只读页执行了写操作。这类缺页会走do_page_fault的bad_area分支最终向进程发送SIGSEGV或者触发内核panic。我之前排查过一个非常经典的段错误却定位不到代码的问题最后就是用gdb /proc/ /pagemap madvise的配合确认是用户态代码访问了一个已经madvise(DONTNEED)的内存区域内核在页表里找不到映射直接给了信号。这种问题不会崩溃但特别隐蔽页表知识不够的话很难定位到根因。缺页异常的完整路径在x86_64上大致是硬件保存错误码和出错地址CPU跳转到page_fault入口进入do_page_fault根据地址判断是用户态还是内核态再根据缺页原因分派给handle_mm_fault。handle_mm_fault会逐级检查并建立缺失的页表目录。如果PGD存在而PUD不存在就先创建PUD页如果PUD存在而PMD不存在就先创建PMD页逐级往下最后建立PTE。整个过程核心思路就是用到哪一层就建哪一层。了解这个路径对于优化内存密集型应用的缺页性能有直接帮助。比如JVM的启动阶段会有大量内存分配此时如果关闭THP并显式配置大页可以减少缺页次数明显缩短启动时间。4.3 fork时页表的变化写时拷贝的优美设计fork()在早期实现中是直接把父进程的全部页表内容拷贝一份给子进程每个映射的物理页也要复制这种拷贝全部做法在进程比较大的时候又慢又浪费内存。现在的Linux fork默认通过写时拷贝Copy-On-Write机制实现。流程简化版如下fork调用进入内核创建子进程的task_struct复制父进程的mm_struct。内核调用dup_mmap遍历父进程的VMA树为子进程复制同样的VMA。页表复制阶段通过copy_page_range逐级复制父进程的页表结构但关键点是在复制PTE时把父进程和子进程的PTE都标记为只读去掉R/W位并且在每个页面上都打上写时拷贝的标记实际上就是软位所在位置。两个进程中任何一个试图写入时CPU触发写保护缺页进入do_wp_page内核分配新的物理页把原页内容拷贝过去再修改当前进程的PTE为可写随后返回用户态重新执行刚才的写指令。这个机制的巧妙处在于fork过程中不需要复制物理页只需要复制页表结构物理内存的复制延迟到了真正发生写入的那一刻。我在实际项目中观察过一个吃了2GB内存的进程fork一个子进程后系统内存并没有马上增加2GB只是多了大概几十MB的页表开销——这就是COW的效果。但要注意如果子进程马上exec加载新程序那父进程的页表就完全浪费了如果子进程是长期跑着的workerCOW带来的缺页开销也不小。所以设计多进程架构时要结合业务特点决定是forkexec还是用线程不能只看启动快不快。4.4 页表的分配与释放路径页表本身也是内存也需要分配器来分配。这里涉及两个容易混淆的概念页表页面的分配和普通物理页的分配。在Linux里页表页面通常通过pgd_alloc、pud_alloc、pmd_alloc、pte_alloc等函数完成本质上是调用伙伴系统的alloc_pages接口分配一个4KB页面然后对页面清零填充目录项。为了加速多级分配内核还引入了pgtable_cache和quicklist等机制来缓存已释放的页表页面。清理路径则是反向的当一个进程退出或unmap区域时free_pgtables会调用pgd_free、pud_free、pmd_free、pte_free逐级释放页表页最终归还给伙伴系统。这里有个容易踩的低级问题如果某个驱动直接在中断上下文或者持锁状态下调用这些释放函数可能死锁或卡死因为页表的释放可能涉及睡眠操作。我见过一个网卡驱动在NAPI轮询回调里做了unmap和释放页表的操作结果系统频繁死锁最终是把页表释放的代码挪到了workqueue里异步执行才解决。所以只要涉及页表的操作一定要检查所在上下文的睡眠约束。5. 从页表视角看内核经典机制KASLR、direct mapping与页表隔离5.1 KASLR让攻击者猜不到内核地址内核地址空间布局随机化KASLR是一种缓解措施思路很简单每次启动时内核的文本段基址从一个随机位置加载而不是固定不变。这样可以避免攻击者利用固定的内核符号地址来做固定的攻击比如直接跳转到某个固定地址的gadget。KASLR在页表层面的效果就是内核在启动早期重建页表时会进行地址随机化偏置所有符号地址都随之变化。查看实际运行时内核基地址可以用dmesg | grep Kernel Offset或者在/proc/kallsyms里看到随机化后的地址。设置nokaslr参数可以关闭该功能但生产环境不建议。这里还涉及一个安全细节既然内核页表是共享给所有进程的如果某个漏洞允许用户态读取内核页表内容就可以推断出内核基址从而绕过KASLR。所以现代内核里对页表的读取做了严格限制/proc/self/pagemap等接口只开放给有CAP_SYS_ADMIN权限的进程降低信息泄露面。5.2 direct mapping为什么物理内存直接映射在固定偏移在x86_64 Linux中物理内存大部分被映射在一个固定的线性区域地址计算公式是virt page_offset_base phys_addr。page_offset_base起始地址一般是0xffff8880000000004.17内核后可以通过KASLR生产随机化的page_offset_base。只所以采用这种一个固定偏移直接算出虚拟地址的设计是因为最常见的操作是拿到struct page或物理地址需要立即访问对应内容。如果每个物理页都要动态建立页表那性能会非常差。direct mapping的巨大优势是转换简单内核只需把phys地址加上一个固定值就能得到一个可直接访问的虚拟地址不需要额外查找页表。但要注意direct mapping的映射属性通常是可写的所以这里一旦有内核写越界bug很可能直接污染相邻物理内存的其它页面。很多内存损坏类的问题最后dladdr或者scan memmap时发现就是写穿了direct mapping区域导致struct page被破坏system直接panic。这就引出一个最佳实践能不用direct mapping映射的敏感区域尽量用vmalloc或者ioremap建立独立映射虽然慢一点点但能形成天然的隔离避免内存踩踏扩散到整个物理内存。5.3 内核页表隔离KPTI的取舍再说一个这几年最典型的安全机制KPTIKernel Page Table Isolation。这个机制的出现直接原因是Meltdown漏洞用户态进程在预测执行时可以访问内核地址空间的数据而当时内核页表在所有进程里都直接映射了全部内核地址用户态代码可以绕过权限检查读取内核内存。KPTI的做法是把内核页表中与用户态相关的绝大部分条目切换出去只在系统调用和中断进入内核时临时加载完整的内核页表用户态运行时CR3指向的是一份裁减过的页表里面几乎没有内核敏感映射从而极大缩小了攻击面。代价是系统调用和中断的进出需要做一次CR3切换、TLB刷新导致系统调用开销明显上升。在4.15内核引入KPTI后很多人实测发现高并发小请求的系统调用密集场景性能下降可达5%~10%。而后来的性能优化又重新引入了PCIDProcess Context Identifier和PTI trampoline的设计让切换成本下降了不少。所以现在的内核虽然默认开启KPTI但实际生产影响已经比刚发布时小很多。如果你在排查系统调用密集业务变慢的问题可以查一下是否在旧内核上开启了KPTI并考虑升级内核到支持PCID优化后的版本。5.4 页表与内存回收的交互页表里有一个环节经常被忽略内存回收时如何高效找到某个物理页被哪些页表项引用了。内核维护着一个反向映射RMAP系统用来记录每个物理页对应的PTE链条。内核的rmap通过struct anon_vma和address_space的反向映射信息可以从struct page反查到所有映射它的虚拟地址。内存回收在决定回收一个页面前需要去扫描这些反向映射逐个清空或更新对应进程的PTE。这就是为什么看到某些页面被回收后访问它又触发缺页重新读盘的原因。如果反向映射信息损坏或缺失内存回收时页表清理不干净就可能出现半映射状态——物理页已经释放PTE还指向它下次访问得到一个错误数据。这类问题通常被归为内存损坏类疑难杂症排查起来极靠经验。6. 实战如何用工具看见页表6.1 /proc/self/pagemap查看虚拟页到物理页的映射Linux通过/proc/ /pagemap给用户态提供查看进程页表内容的接口。每个虚拟页对应一个64位条目用来记录该页是否在内存、物理页帧号等。不过要注意这个接口暴露的信息很敏感只有root或有CAP_SYS_ADMIN权限的进程才能读取而且不同内核版本的字段解析有细微差别。我常用的解析脚本大致是这样的#!/bin/bash # 以PID为例打印进程每个用户地址页的PFN和状态 pid$1 start$2 end$3 pagesize$(getconf PAGESIZE) for ((addrstart; addrend; addrpagesize)); do offset$((addr / pagesize * 8)) # 读取64位条目 entry$(dd if/proc/$pid/pagemap bs8 skip$((addr / pagesize)) count1 2/dev/null | od -An -tx8) present$(( (0x$(echo $entry | tr -d ) 63) 1 )) pfn$(( (0x$(echo $entry | tr -d ) 0x7fffffffffffff) )) if [ $present -eq 1 ]; then echo addr0x$addr pfn0x$pfn present1 fi done但每次调dd和od太慢了实际场景我一般直接用C写一个小工具或者直接用python读取mmap后的pagemap节点。另外检查整个地址空间是否有未映射洞时也可以读/proc/ /maps先拿到VMA范围再配合pagemap做交叉验证。6.2 内核crash dump里的页表解析当系统panic时如果配置了kdump我们会得到一个vmcore文件。在redhat系或ubuntu系上都常用crash工具来分析vmcore。crash的常用页表相关命令包括命令作用vtop解析一个虚拟地址输出对应的PGD/PUD/PMD/PTE条目和物理地址vm显示进程的VMA列表和页表概要ptob / btob在物理地址和虚拟地址间转换search -p在内存中搜索一个物理地址对应的内容我在处理一个内存损坏类问题时就靠crash的vtop确认了某个内核结构体所在的物理页被另一个模块错误映射写坏。先拿到损坏地址的虚拟地址然后vtop看到其对应的物理页再search -p这个物理页的所有虚拟映射发现另一个驱动也在引用同一物理页且允许写瞬间就暴露了问题。6.3 实测手工遍历一次页表在Linux内核模块里也可以直接遍历一个进程的页表。这个操作在日常排障中很有用比如判断某个虚拟地址是否真的映射了、PTE的权限位是什么。以下是一个极简的内核态遍历示例static void dump_pte(struct mm_struct *mm, unsigned long addr) { pgd_t *pgd; p4d_t *p4d; pud_t *pud; pmd_t *pmd; pte_t *pte; if (!mm) return; pgd pgd_offset(mm, addr); if (pgd_none(*pgd) || pgd_bad(*pgd)) goto out; p4d p4d_offset(pgd, addr); if (p4d_none(*p4d) || p4d_bad(*p4d)) goto out; pud pud_offset(p4d, addr); if (pud_none(*pud) || pud_bad(*pud)) goto out; pmd pmd_offset(pud, addr); if (pmd_none(*pmd) || pmd_bad(*pmd)) goto out; pte pte_offset_kernel(pmd, addr); if (pte_present(*pte)) { pr_info(addr %lx - phys %lx, flags %lx\n, addr, (unsigned long)pte_pfn(*pte) PAGE_SHIFT, (unsigned long)pte_val(*pte) 0xfff); } out: return; }这个代码虽然简单但踩过坑的人知道pgd_bad、p4d_bad、pud_bad、pmd_bad这几个宏在检查页表项时不同架构下的实现可能不同有的会检查目录项里保留位是否被意外置位。遍历页表时如果没做这类检查直接访问下一级指针遇到损坏的情况就会二次崩溃。我自己就在调试一个内存踩踏问题时因为漏了pmd_bad检查结果在遍历页表时又触发了一个page fault整个调试过程直接雪上加霜。后来养成习惯任何页表遍历代码都按判断存在-判断是否bad-再下一层的顺序写。6.4 页表调试中的三个常见误判第一把/proc/meminfo里的PageTables当成实际页表占用内存这个数字确实表示所有进程页表页面的总量但它不包括各级目录里的复用共享页也不包括页表缓存的残余所以只是近似值。第二认为虚拟地址连续等于物理地址连续绝大多数情况下虚拟连续而物理碎片化只有在直接映射区里才有简单的线性关系。第三把用户态看到的mmap内存都理解为匿名页实际上可能映射的是文件页或设备内存这类页的PTE行为和普通匿名页完全不同页表遍历时注意区分。7. 几个经典面试题与自测清单7.1 多级页表为什么能省内存这个题的本质是看你能不能理解按需分配四个字。单级页表必须一次性分配全部1048576个页表项多级页表只在进程实际使用到某个区域时才建立对应的中间目录和末级页表未使用的高位目录项直接留空。一个只用了很少内存的进程它的PGD和PUD只有几个非空项PMD和PTE也少得可怜整体开销远小于固定8MB的单级方案。7.2 为什么fork之后父进程和子进程的页表都是只读这考查的是写时拷贝机制。fork时如果直接把页表复制成可写父子进程共用同一物理页某一方写入就会互相干扰。所以必须把PTE的写权限位清掉让任意一方在第一次写时触发写保护缺页再由内核分配独立副本。这个机制就是延迟复制物理内存的体现。7.3 缺页异常的处理流程是怎样的缺页异常流程可以口述为硬件将出错地址写入CR2并触发异常内核保存现场后进入do_page_fault检查地址合法性是否在进程的VMA范围内是否有对应权限如果属于合理缺页就分配物理页或读取文件页并建立页表如果是非法访问就发送信号或panic。注意区分major fault需要从磁盘读页和minor fault页已在内存中只需要建立映射前者更慢。7.4 为什么内核空间地址对所有进程是一样的因为内核页表的含义是系统的全局内存视图所有进程共享同样的内核映射这样进程切换时不需要重新建立内核地址空间的页表只需要切换用户空间的页表。这种设计极大简化了系统调用和中断处理也是Linux能高效支持多进程的基础之一。7.5 自测清单能画出x86_64下虚拟地址的层级划分吗能解释一个4KB页的PTE里高52位和低12位各自的含义吗知道如何手动解析一次缺页异常的error code吗能区分用户态缺页、内核态缺页、以及写保护缺页的处理路径差异吗知道为什么修改页表后需要TLB shootdown吗能说出linear mapping、vmalloc区、kernel text区各自的特点和典型用途吗如果这些问题能脱口而出说明你对Linux内核页表的理解已经超过大部分运维工程师达到可以写内核模块或排查内存类问题的程度。8. 我踩过的页表相关的三个大坑说完了机制补几个我自己实际踩过的坑希望能帮别人少走弯路。第一个坑是在驱动里修改用户态缓冲区时没有用copy_from_user而是直接用内核指针写用户地址。在最开始提到的那个案例里我们虽然最终用SIGSEGV定位出了问题但排查过程非常痛苦业务侧以为是驱动返回了错误数据驱动侧以为业务侧传了非法指针。最后是通过在驱动入口临时加了一段遍历页表的调试代码发现目标用户地址对应的PTE只读才确认是权限问题。从那以后我给团队定了一个铁律任何涉及用户态地址的内核操作一律走copy_from_user/copy_to_user或get_user_pages处理绝不对用户指针做裸访问。第二个坑是修改页表后忘记刷TLB。当时是给一个模块分配了一段连续的虚拟地址映射到物理页后改动了下级页表但没调用flush_tlb_kernel_range结果第一次访问时CPU用的是旧TLB缓存直接映射到了错误的物理地址数据全乱了。这种bug的诡异之处在于它不是必现的只有TLB缓存未命中时才能看到正确结果线上系统一压测就出乱子。所以只要改了内核页表务必根据改动范围调用对应的flush_tlb_all或flush_tlb_kernel_range。第三个坑是误解了什么情况算页表泄漏。曾经遇到一个长期运行的内存缓慢增长的进程用pagemap看到进程的VMA区越来越多但业务逻辑上根本没有分配那么多内存。最后发现是一个第三方库在每次调用时都mmap一小段匿名内存但从不munmap导致内核里每次都新建VMA和页表不仅内存增长进程的页表占用量也一直涨。这类问题的根因不是内核页表机制本身而在于用户态内存管理不规范但排查时如果不先排除页表层面是否存在合理映射很容易误判为内核bug。9. 学习路径建议从看懂页表到会调页表最后聊点学习路径。页表内容在操作系统课程里属于看似简单实则复杂的重点我的经验是分三步走。第一步先搞懂硬件行为。用qemu模拟器跑一个最小系统或者用gdb的qemu模式调试内核在do_page_fault入口打断点单步跟踪一次缺页的完整处理过程观察CR2寄存器的值如何变化。这一步核心是把硬件触发-内核处理-返回用户态的链路走通。第二步精读Linux源码中几个核心文件arch/x86/mm/fault.c、mm/memory.c、mm/mmap.c。不需要逐行看只关注do_page_fault、handle_mm_fault、copy_page_range、unmap_page_range这四个函数的入口和主流程。建议一边看源码一边画流程图把页表的建立、复制、清理三件事的代码路径都画出来基本就掌握60%了。第三步实践驱动。写一个小内核模块调用remap_pfn_range或者io_remap_pfn_range映射一段物理内存到用户态再用用户态程序读取/写入这段地址观察页表前后变化。或者写一个统计每个进程页表占用数量的模块打印出PGD/PUD/PMD/PTE各级页面的数量。这种实践比纯看书有效得多。在工具链上我建议至少会使用qemu、gdb、crash、/proc/self/pagemap这四样工具必要时再配合systemtap或bpftrace跟踪内核函数比如用bpftrace统计缺页异常的类型和次数。当年我是用一个bpftrace一行命令统计每个进程的缺页次数很快定位出一个频繁触发缺页的进程发现它每次读文件都走mmap而不用read导致缺页开销巨大——这类问题放在今天完全可以用perf和bpftrace快速验证。如果你也想深入研究建议从这两个工具开始上手搭配本篇文章里的知识点基本可以独立排查各种内存类问题了。
1. 从一个看似基础的问题说起页表到底在忙什么如果你翻过几本讲内核的书大概率会看到一句话Linux通过页表实现虚拟内存到物理内存的映射。这句话每个字都认识但合在一起很多人是懵的。更常见的情况是你能背出四级页表的名字PGD、PUD、PMD、PTE也能说出页表项里有读、写、执行几个权限位可真让你解释为什么需要这么多层级、缺一不可或者让你基于一个实际的内核崩溃现场倒推出是哪一级页表出了问题很多人就卡住了。我在最开始学内核的时候也栽在这上面。先说一个我印象很深的案例有一台x86_64服务器跑的4.18内核业务进程在某个瞬间突然被SIGSEGV杀掉/var/log/messages里没有任何硬件报错dmesg里只有一条很普通的segfault at ... ip ... error 4。用gdb挂上去看用户的堆栈完全正常指令地址也是合理的代码段地址。后来排查了很久才发现问题出在一个驱动程序里它在ioctl路径中直接修改了用户态传入的buffer地址并且没有做access_ok校验也没有通过copy_from_user做拷贝而是直接拿用户地址去做内核态的memcpy。在特定布局下这个用户地址对应的页表项是一个只读映射硬件在页表遍历阶段就拦下了这次写入所以连一点数据都没污染进程直接被杀了。换句话说整个系统的稳定靠的就是页表权限位在硬件层面拦了一道。所以我想从页表到底在忙什么这个问题开始把整个机制拆开讲清楚。这篇文章既是给刚接触内核的人看的入门逻辑梳理也是给我这种工作中经常要和内存调优、问题排查打交道的人做一个完整的技术复盘。我要讲的是x86_64架构下Linux的页表实现从硬件行为到内核代码再到实际调试方法一次说透。2. 为什么CPU和操作系统联手搞出了层级页表2.1 没有页表的世界会怎样先做个思想实验。假设系统里只有物理内存程序直接使用物理地址访问内存即所谓的实模式。这当然能跑但会有几个致命问题第一程序A和程序B如何隔离如果A把数据写到物理地址1000B也往1000写俩进程就互相踩踏了。第二程序加载的地址必须提前知道链接器必须把代码里的每一个地址都安排成物理地址程序一旦编译就无法移动这叫重定位问题。第三物理内存总共就那么多程序想用超过物理内存大小的空间怎么办换入换出没有统一管理机制。页表的出现核心目的就是解决这三个问题隔离、重定位、按需换入换出。虚拟机内存的机制听起来抽象但本质上是让每个进程都以为自己拥有一整块连续、独立、从0到很大范围的地址空间而这块假地址到真地址的翻译工作由CPU的MMU内存管理单元配合操作系统维护的页表共同完成。应用程序根本不需要关心物理内存长什么样。2.2 分页的核心思想把地址空间切成格子分页的思想很朴素把虚拟地址空间和物理地址空间都切成固定大小的格子虚拟地址空间里的一个格子映射到物理地址空间里任意一个格子或者干脆不映射。映射关系存在一张表里CPU每次访问内存时用虚拟地址的索引部分去查表拿到物理地址的起始位置再加上偏移量得到最终物理地址。这个格子的大小在x86_64上默认是4KB所以一个虚拟地址可以被切成两段高20位是页号索引低12位是页内偏移。2的20次方就是1048576个页每个页需要一个页表项记录映射关系每个页表项8字节所以一张完整的单级页表需要8MB内存。假设系统里有100个进程光页表就要占800MB每访问一次内存都要来一次全表扫描性能也是灾难。2.3 多级结构的数学逻辑为什么是4级为了解决单级页表太浪费的问题操作系统引入了多级页表。这就好比你要在一本很厚的书里找内容与其从头一页一页翻单级线性查找不如先看目录找到章节一级索引再看节找到小节二级索引最终定位到具体页三级索引。目录本身只占很小空间而且如果你这一章根本不存在那连子目录都不需要建直接省掉一大片空间。x86_64架构的分页层级是4级从上到下依次是层级缩写全称管理地址宽度x86_64每级索引位数第1级PGDPage Global Directory47-39位9位第2级PUDPage Upper Directory38-30位9位第3级PMDPage Middle Directory29-21位9位第4级PTEPage Table Entry20-12位9位每个索引占9位是因为每级目录包含512个表项2^9 512每个表项8字节正好占一个4KB页。虚拟地址的布局就是前16位未使用x86_64当前只实现48位虚拟地址然后是9位PGD索引、9位PUD索引、9位PMD索引、9位PTE索引、最后12位页内偏移。CPU访问一次内存实际上要经历最多4次内存读取每次读一个页表项再加上TLB缓存帮忙才能拿到物理地址。多一次内存读取看似开销很大但换来的好处是一个进程即使虚拟地址空间再大真正使用的页表目录也不会全部创建。一个进程只访问了很少的内存页就只需要极少数的页目录项和页表项内存开销比单级8MB小得多。2.4 TLB多级查表的性能救星多级页表的代价是访问速度。原本一次访存搞定的事现在变成最多4次页表查询加1次真正访存那就是5次。但CPU设计者们早就想过这个问题方案就是TLBTranslation Lookaside Buffer一个地址翻译缓存。TLB里保存着最近用过的虚拟页号到物理页号的对应关系。一般情况下CPU在查页表之前会先去TLB里找命中就直接得到物理地址这个速度比查内存快好几个数量级极大弥补了多级页表带来的开销。但要注意一个坑如果进程频繁切换或者使用了大量不同地址的内存TLB命中率会下降性能就会掉回去。这也是为什么内核代码里会有很多TLB shootdown的处理逻辑——一个CPU改了页表需要通知其他CPU刷新TLB否则其他核心可能还在用旧的缓存地址轻则数据不一致重则直接崩溃。这类bug在写驱动时经常遇到尤其在使用vmalloc、mmap等涉及页表修改的接口时改完必须注意TLB的同步问题。真正解决问题要分清哪些是内核帮你处理的哪些需要你自己手动处理。3. 逐级拆解x86_64页表从PGD到PTE的每个标志位3.1 页目录和页表项的布局在x86_64的Linux实现中PGD、PUD、PMD、PTE这四级其实每一级都只是一个个64位的表项数组。每一级页表的基地址存放在CPU的CR3寄存器里。当进程切换时内核会更新CR3指向新进程的PGD基地址这样CPU的MMU自然就知道该用哪张页表了。换句话说页表就是操作系统在内存里建好的一张张表CPU只是按图索骥的执行者。每个页表项的低12位是标志位区域高52位是物理地址的高位部分。由于页表项本身只能给出页帧号页内偏移由虚拟地址末12位直接决定所以物理页必须是4KB对齐的。这个低位标志位高位物理地址的布局是整个分页机制的核心理解它之后就能自己解析很多内存问题了。3.2 常见的页表标志位及含义标志位名称含义与典型坑bit 0Present该页是否在内存中。为0就触发缺页异常属于按需换页的核心。如果这一位为0后面的物理地址无意义可以存内核自己的数据bit 1R/W可写标志。为0则只读。数据段、代码段通常只读堆栈页为可写。改写这里可以实现写时拷贝、保护只读数据bit 2U/S用户态还是内核态可访问。为0则只有内核态能访问这是用户态和内核态隔离的基石bit 3PWT/Page Write Through写透缓存控制。通常用不到驱动开发偶尔会设置bit 4PCD/Page Cache Disable禁用该页缓存。映射设备寄存器内存时经常用到避免CPU缓存干扰设备读写bit 5Accessed页面是否被访问过。硬件自动设置内核定期扫描可以统计热度用于内存回收bit 6Dirty页面是否被写入过。脏页标记对刷盘和swap很关键bit 7PAT页属性表扩展控制内存类型一般不用关心bit 8GlobalTLB全局页标志。内核常用的线性映射区经常打开避免TLB频繁失效bit 9-11软件可用位内核自定义用途比如记录该页是否被swap占用、是否mlock等我来举一个实际例子有一次排查系统负载飙升用perf去看内核热点发现大量时间花在do_page_fault里。原因是一个应用程序通过mmap映射了一个文件然后用指针逐个字节访问由于文件是按页加载的每次访问新页都会触发缺页异常。后来改成按页缓存读取系统负载立刻降下来了。这个案例说明缺页异常处理是有代价的每次缺页都要进入内核态、查找页表、分配物理页、建立映射、刷新TLB这一套动作比直接访存贵一到两个数量级。所以页表的设计不只是空间换时间它还在操作系统的各个层面产生连锁影响。3.3 大页HugePage多级目录的旁路既然多级页表是为了节省空间而设计的那它自然也有一个反向优化大页。如果我们已经知道某个区域的映射是连续的、巨大的我们就可以跳过中间的几级目录用一个更高级别的目录项直接指向一个2MB甚至1GB的物理页块。这类页表项称为HugePage。2MB大页由PMD直接指向2MB物理块跳过PTE这一级。1GB大页由PUD直接指向1GB物理块跳过PMD和PTE两级。大页的好处至少有四个减少了页表遍历级数降低TLB miss概率减少了页表占用的内存数量缺页次数显著减少一个2MB大页就相当512个普通页对数据库、JVM这种大量连续内存访问的场景性能提升客观存在。但大页不是没有代价。分配大页必须是连续的物理内存在长时间运行、内存碎片较多的系统上分配1GB大页可能会失败。而且大页的管理粒度大不适合需要精细内存隔离的场景。在实际生产里我一般建议数据库实例和JVM进程优先考虑透明大页THP或显式配置HugePages但要注意THP的khugepaged线程在后台做内存规整时可能造成偶发延迟抖动这在响应时间敏感的业务中是很常见的一类问题。我们后来是直接在数据库服务的启动脚本里加echo never /sys/kernel/mm/transparent_hugepage/enabled关闭了THP换成了显式的HugePages配置抖动问题才彻底消失。4. Linux内核如何使用和操纵页表4.1 每进程页表和内核的共享魔法每个进程都有自己的PGD但这不代表每个进程都要复制一份完整的内核页表。在x86_64 Linux中内核地址空间高位部分从0xffff888000000000开始对所有进程都是一样的。这个区域在内核初始化时被建立起来并被所有进程的PGD所引用。关键内存布局大致是这样地址范围用途映射类型0xffff888000000000 - 0xffffc87fffffffff直接物理映射区linear mapping通过phys_to_virt直接计算偏移固定0xffffc90000000000 - 0xffffe8ffffffffffvmalloc区动态映射区域每次调用vmalloc都会修改页表0xffffea0000000000 - 0xffffeaffffffffff内存热插拔、memmap区域管理struct page数组0xffffffff80000000 - 0xffffffff9fffffff内核文本、rodata、数据段编译期链接地址映射固定进程切换时内核需要做的页表切换其实就是切换PGD和刷新TLB。但因为内核空间共享TLB刷新时可以保留内核地址空间的Global页只刷新用户空间的条目这就是上面提到bit 8 Global标志存在的意义。内核里切换进程上下文时调用的switch_mm_irqs_off函数就是负责这一系列操作的。4.2 缺页异常页表不存在的补救机制CPU访问一个虚拟地址时如果页表查下去发现某个Present位为0就会触发一个缺页异常Page Fault。缺页异常的处理路径并不简单内核需要判断这个缺页是合理缺页还是非法访问。合理缺页包括三种情况缺页类型发生原因内核响应首次访问匿名页进程申请了内存但物理页还没分配分配一个物理页清零建立映射返回用户态文件映射页mmap映射的文件内容还没读入内存从文件系统读取对应页建立映射写时拷贝fork之后父子进程共享只读页有一方要写复制物理页修改页表为可写返回用户态非法访问则包括访问了未映射地址NULL、栈溢出等、越过了用户态权限限制、对只读页执行了写操作。这类缺页会走do_page_fault的bad_area分支最终向进程发送SIGSEGV或者触发内核panic。我之前排查过一个非常经典的段错误却定位不到代码的问题最后就是用gdb /proc/ /pagemap madvise的配合确认是用户态代码访问了一个已经madvise(DONTNEED)的内存区域内核在页表里找不到映射直接给了信号。这种问题不会崩溃但特别隐蔽页表知识不够的话很难定位到根因。缺页异常的完整路径在x86_64上大致是硬件保存错误码和出错地址CPU跳转到page_fault入口进入do_page_fault根据地址判断是用户态还是内核态再根据缺页原因分派给handle_mm_fault。handle_mm_fault会逐级检查并建立缺失的页表目录。如果PGD存在而PUD不存在就先创建PUD页如果PUD存在而PMD不存在就先创建PMD页逐级往下最后建立PTE。整个过程核心思路就是用到哪一层就建哪一层。了解这个路径对于优化内存密集型应用的缺页性能有直接帮助。比如JVM的启动阶段会有大量内存分配此时如果关闭THP并显式配置大页可以减少缺页次数明显缩短启动时间。4.3 fork时页表的变化写时拷贝的优美设计fork()在早期实现中是直接把父进程的全部页表内容拷贝一份给子进程每个映射的物理页也要复制这种拷贝全部做法在进程比较大的时候又慢又浪费内存。现在的Linux fork默认通过写时拷贝Copy-On-Write机制实现。流程简化版如下fork调用进入内核创建子进程的task_struct复制父进程的mm_struct。内核调用dup_mmap遍历父进程的VMA树为子进程复制同样的VMA。页表复制阶段通过copy_page_range逐级复制父进程的页表结构但关键点是在复制PTE时把父进程和子进程的PTE都标记为只读去掉R/W位并且在每个页面上都打上写时拷贝的标记实际上就是软位所在位置。两个进程中任何一个试图写入时CPU触发写保护缺页进入do_wp_page内核分配新的物理页把原页内容拷贝过去再修改当前进程的PTE为可写随后返回用户态重新执行刚才的写指令。这个机制的巧妙处在于fork过程中不需要复制物理页只需要复制页表结构物理内存的复制延迟到了真正发生写入的那一刻。我在实际项目中观察过一个吃了2GB内存的进程fork一个子进程后系统内存并没有马上增加2GB只是多了大概几十MB的页表开销——这就是COW的效果。但要注意如果子进程马上exec加载新程序那父进程的页表就完全浪费了如果子进程是长期跑着的workerCOW带来的缺页开销也不小。所以设计多进程架构时要结合业务特点决定是forkexec还是用线程不能只看启动快不快。4.4 页表的分配与释放路径页表本身也是内存也需要分配器来分配。这里涉及两个容易混淆的概念页表页面的分配和普通物理页的分配。在Linux里页表页面通常通过pgd_alloc、pud_alloc、pmd_alloc、pte_alloc等函数完成本质上是调用伙伴系统的alloc_pages接口分配一个4KB页面然后对页面清零填充目录项。为了加速多级分配内核还引入了pgtable_cache和quicklist等机制来缓存已释放的页表页面。清理路径则是反向的当一个进程退出或unmap区域时free_pgtables会调用pgd_free、pud_free、pmd_free、pte_free逐级释放页表页最终归还给伙伴系统。这里有个容易踩的低级问题如果某个驱动直接在中断上下文或者持锁状态下调用这些释放函数可能死锁或卡死因为页表的释放可能涉及睡眠操作。我见过一个网卡驱动在NAPI轮询回调里做了unmap和释放页表的操作结果系统频繁死锁最终是把页表释放的代码挪到了workqueue里异步执行才解决。所以只要涉及页表的操作一定要检查所在上下文的睡眠约束。5. 从页表视角看内核经典机制KASLR、direct mapping与页表隔离5.1 KASLR让攻击者猜不到内核地址内核地址空间布局随机化KASLR是一种缓解措施思路很简单每次启动时内核的文本段基址从一个随机位置加载而不是固定不变。这样可以避免攻击者利用固定的内核符号地址来做固定的攻击比如直接跳转到某个固定地址的gadget。KASLR在页表层面的效果就是内核在启动早期重建页表时会进行地址随机化偏置所有符号地址都随之变化。查看实际运行时内核基地址可以用dmesg | grep Kernel Offset或者在/proc/kallsyms里看到随机化后的地址。设置nokaslr参数可以关闭该功能但生产环境不建议。这里还涉及一个安全细节既然内核页表是共享给所有进程的如果某个漏洞允许用户态读取内核页表内容就可以推断出内核基址从而绕过KASLR。所以现代内核里对页表的读取做了严格限制/proc/self/pagemap等接口只开放给有CAP_SYS_ADMIN权限的进程降低信息泄露面。5.2 direct mapping为什么物理内存直接映射在固定偏移在x86_64 Linux中物理内存大部分被映射在一个固定的线性区域地址计算公式是virt page_offset_base phys_addr。page_offset_base起始地址一般是0xffff8880000000004.17内核后可以通过KASLR生产随机化的page_offset_base。只所以采用这种一个固定偏移直接算出虚拟地址的设计是因为最常见的操作是拿到struct page或物理地址需要立即访问对应内容。如果每个物理页都要动态建立页表那性能会非常差。direct mapping的巨大优势是转换简单内核只需把phys地址加上一个固定值就能得到一个可直接访问的虚拟地址不需要额外查找页表。但要注意direct mapping的映射属性通常是可写的所以这里一旦有内核写越界bug很可能直接污染相邻物理内存的其它页面。很多内存损坏类的问题最后dladdr或者scan memmap时发现就是写穿了direct mapping区域导致struct page被破坏system直接panic。这就引出一个最佳实践能不用direct mapping映射的敏感区域尽量用vmalloc或者ioremap建立独立映射虽然慢一点点但能形成天然的隔离避免内存踩踏扩散到整个物理内存。5.3 内核页表隔离KPTI的取舍再说一个这几年最典型的安全机制KPTIKernel Page Table Isolation。这个机制的出现直接原因是Meltdown漏洞用户态进程在预测执行时可以访问内核地址空间的数据而当时内核页表在所有进程里都直接映射了全部内核地址用户态代码可以绕过权限检查读取内核内存。KPTI的做法是把内核页表中与用户态相关的绝大部分条目切换出去只在系统调用和中断进入内核时临时加载完整的内核页表用户态运行时CR3指向的是一份裁减过的页表里面几乎没有内核敏感映射从而极大缩小了攻击面。代价是系统调用和中断的进出需要做一次CR3切换、TLB刷新导致系统调用开销明显上升。在4.15内核引入KPTI后很多人实测发现高并发小请求的系统调用密集场景性能下降可达5%~10%。而后来的性能优化又重新引入了PCIDProcess Context Identifier和PTI trampoline的设计让切换成本下降了不少。所以现在的内核虽然默认开启KPTI但实际生产影响已经比刚发布时小很多。如果你在排查系统调用密集业务变慢的问题可以查一下是否在旧内核上开启了KPTI并考虑升级内核到支持PCID优化后的版本。5.4 页表与内存回收的交互页表里有一个环节经常被忽略内存回收时如何高效找到某个物理页被哪些页表项引用了。内核维护着一个反向映射RMAP系统用来记录每个物理页对应的PTE链条。内核的rmap通过struct anon_vma和address_space的反向映射信息可以从struct page反查到所有映射它的虚拟地址。内存回收在决定回收一个页面前需要去扫描这些反向映射逐个清空或更新对应进程的PTE。这就是为什么看到某些页面被回收后访问它又触发缺页重新读盘的原因。如果反向映射信息损坏或缺失内存回收时页表清理不干净就可能出现半映射状态——物理页已经释放PTE还指向它下次访问得到一个错误数据。这类问题通常被归为内存损坏类疑难杂症排查起来极靠经验。6. 实战如何用工具看见页表6.1 /proc/self/pagemap查看虚拟页到物理页的映射Linux通过/proc/ /pagemap给用户态提供查看进程页表内容的接口。每个虚拟页对应一个64位条目用来记录该页是否在内存、物理页帧号等。不过要注意这个接口暴露的信息很敏感只有root或有CAP_SYS_ADMIN权限的进程才能读取而且不同内核版本的字段解析有细微差别。我常用的解析脚本大致是这样的#!/bin/bash # 以PID为例打印进程每个用户地址页的PFN和状态 pid$1 start$2 end$3 pagesize$(getconf PAGESIZE) for ((addrstart; addrend; addrpagesize)); do offset$((addr / pagesize * 8)) # 读取64位条目 entry$(dd if/proc/$pid/pagemap bs8 skip$((addr / pagesize)) count1 2/dev/null | od -An -tx8) present$(( (0x$(echo $entry | tr -d ) 63) 1 )) pfn$(( (0x$(echo $entry | tr -d ) 0x7fffffffffffff) )) if [ $present -eq 1 ]; then echo addr0x$addr pfn0x$pfn present1 fi done但每次调dd和od太慢了实际场景我一般直接用C写一个小工具或者直接用python读取mmap后的pagemap节点。另外检查整个地址空间是否有未映射洞时也可以读/proc/ /maps先拿到VMA范围再配合pagemap做交叉验证。6.2 内核crash dump里的页表解析当系统panic时如果配置了kdump我们会得到一个vmcore文件。在redhat系或ubuntu系上都常用crash工具来分析vmcore。crash的常用页表相关命令包括命令作用vtop解析一个虚拟地址输出对应的PGD/PUD/PMD/PTE条目和物理地址vm显示进程的VMA列表和页表概要ptob / btob在物理地址和虚拟地址间转换search -p在内存中搜索一个物理地址对应的内容我在处理一个内存损坏类问题时就靠crash的vtop确认了某个内核结构体所在的物理页被另一个模块错误映射写坏。先拿到损坏地址的虚拟地址然后vtop看到其对应的物理页再search -p这个物理页的所有虚拟映射发现另一个驱动也在引用同一物理页且允许写瞬间就暴露了问题。6.3 实测手工遍历一次页表在Linux内核模块里也可以直接遍历一个进程的页表。这个操作在日常排障中很有用比如判断某个虚拟地址是否真的映射了、PTE的权限位是什么。以下是一个极简的内核态遍历示例static void dump_pte(struct mm_struct *mm, unsigned long addr) { pgd_t *pgd; p4d_t *p4d; pud_t *pud; pmd_t *pmd; pte_t *pte; if (!mm) return; pgd pgd_offset(mm, addr); if (pgd_none(*pgd) || pgd_bad(*pgd)) goto out; p4d p4d_offset(pgd, addr); if (p4d_none(*p4d) || p4d_bad(*p4d)) goto out; pud pud_offset(p4d, addr); if (pud_none(*pud) || pud_bad(*pud)) goto out; pmd pmd_offset(pud, addr); if (pmd_none(*pmd) || pmd_bad(*pmd)) goto out; pte pte_offset_kernel(pmd, addr); if (pte_present(*pte)) { pr_info(addr %lx - phys %lx, flags %lx\n, addr, (unsigned long)pte_pfn(*pte) PAGE_SHIFT, (unsigned long)pte_val(*pte) 0xfff); } out: return; }这个代码虽然简单但踩过坑的人知道pgd_bad、p4d_bad、pud_bad、pmd_bad这几个宏在检查页表项时不同架构下的实现可能不同有的会检查目录项里保留位是否被意外置位。遍历页表时如果没做这类检查直接访问下一级指针遇到损坏的情况就会二次崩溃。我自己就在调试一个内存踩踏问题时因为漏了pmd_bad检查结果在遍历页表时又触发了一个page fault整个调试过程直接雪上加霜。后来养成习惯任何页表遍历代码都按判断存在-判断是否bad-再下一层的顺序写。6.4 页表调试中的三个常见误判第一把/proc/meminfo里的PageTables当成实际页表占用内存这个数字确实表示所有进程页表页面的总量但它不包括各级目录里的复用共享页也不包括页表缓存的残余所以只是近似值。第二认为虚拟地址连续等于物理地址连续绝大多数情况下虚拟连续而物理碎片化只有在直接映射区里才有简单的线性关系。第三把用户态看到的mmap内存都理解为匿名页实际上可能映射的是文件页或设备内存这类页的PTE行为和普通匿名页完全不同页表遍历时注意区分。7. 几个经典面试题与自测清单7.1 多级页表为什么能省内存这个题的本质是看你能不能理解按需分配四个字。单级页表必须一次性分配全部1048576个页表项多级页表只在进程实际使用到某个区域时才建立对应的中间目录和末级页表未使用的高位目录项直接留空。一个只用了很少内存的进程它的PGD和PUD只有几个非空项PMD和PTE也少得可怜整体开销远小于固定8MB的单级方案。7.2 为什么fork之后父进程和子进程的页表都是只读这考查的是写时拷贝机制。fork时如果直接把页表复制成可写父子进程共用同一物理页某一方写入就会互相干扰。所以必须把PTE的写权限位清掉让任意一方在第一次写时触发写保护缺页再由内核分配独立副本。这个机制就是延迟复制物理内存的体现。7.3 缺页异常的处理流程是怎样的缺页异常流程可以口述为硬件将出错地址写入CR2并触发异常内核保存现场后进入do_page_fault检查地址合法性是否在进程的VMA范围内是否有对应权限如果属于合理缺页就分配物理页或读取文件页并建立页表如果是非法访问就发送信号或panic。注意区分major fault需要从磁盘读页和minor fault页已在内存中只需要建立映射前者更慢。7.4 为什么内核空间地址对所有进程是一样的因为内核页表的含义是系统的全局内存视图所有进程共享同样的内核映射这样进程切换时不需要重新建立内核地址空间的页表只需要切换用户空间的页表。这种设计极大简化了系统调用和中断处理也是Linux能高效支持多进程的基础之一。7.5 自测清单能画出x86_64下虚拟地址的层级划分吗能解释一个4KB页的PTE里高52位和低12位各自的含义吗知道如何手动解析一次缺页异常的error code吗能区分用户态缺页、内核态缺页、以及写保护缺页的处理路径差异吗知道为什么修改页表后需要TLB shootdown吗能说出linear mapping、vmalloc区、kernel text区各自的特点和典型用途吗如果这些问题能脱口而出说明你对Linux内核页表的理解已经超过大部分运维工程师达到可以写内核模块或排查内存类问题的程度。8. 我踩过的页表相关的三个大坑说完了机制补几个我自己实际踩过的坑希望能帮别人少走弯路。第一个坑是在驱动里修改用户态缓冲区时没有用copy_from_user而是直接用内核指针写用户地址。在最开始提到的那个案例里我们虽然最终用SIGSEGV定位出了问题但排查过程非常痛苦业务侧以为是驱动返回了错误数据驱动侧以为业务侧传了非法指针。最后是通过在驱动入口临时加了一段遍历页表的调试代码发现目标用户地址对应的PTE只读才确认是权限问题。从那以后我给团队定了一个铁律任何涉及用户态地址的内核操作一律走copy_from_user/copy_to_user或get_user_pages处理绝不对用户指针做裸访问。第二个坑是修改页表后忘记刷TLB。当时是给一个模块分配了一段连续的虚拟地址映射到物理页后改动了下级页表但没调用flush_tlb_kernel_range结果第一次访问时CPU用的是旧TLB缓存直接映射到了错误的物理地址数据全乱了。这种bug的诡异之处在于它不是必现的只有TLB缓存未命中时才能看到正确结果线上系统一压测就出乱子。所以只要改了内核页表务必根据改动范围调用对应的flush_tlb_all或flush_tlb_kernel_range。第三个坑是误解了什么情况算页表泄漏。曾经遇到一个长期运行的内存缓慢增长的进程用pagemap看到进程的VMA区越来越多但业务逻辑上根本没有分配那么多内存。最后发现是一个第三方库在每次调用时都mmap一小段匿名内存但从不munmap导致内核里每次都新建VMA和页表不仅内存增长进程的页表占用量也一直涨。这类问题的根因不是内核页表机制本身而在于用户态内存管理不规范但排查时如果不先排除页表层面是否存在合理映射很容易误判为内核bug。9. 学习路径建议从看懂页表到会调页表最后聊点学习路径。页表内容在操作系统课程里属于看似简单实则复杂的重点我的经验是分三步走。第一步先搞懂硬件行为。用qemu模拟器跑一个最小系统或者用gdb的qemu模式调试内核在do_page_fault入口打断点单步跟踪一次缺页的完整处理过程观察CR2寄存器的值如何变化。这一步核心是把硬件触发-内核处理-返回用户态的链路走通。第二步精读Linux源码中几个核心文件arch/x86/mm/fault.c、mm/memory.c、mm/mmap.c。不需要逐行看只关注do_page_fault、handle_mm_fault、copy_page_range、unmap_page_range这四个函数的入口和主流程。建议一边看源码一边画流程图把页表的建立、复制、清理三件事的代码路径都画出来基本就掌握60%了。第三步实践驱动。写一个小内核模块调用remap_pfn_range或者io_remap_pfn_range映射一段物理内存到用户态再用用户态程序读取/写入这段地址观察页表前后变化。或者写一个统计每个进程页表占用数量的模块打印出PGD/PUD/PMD/PTE各级页面的数量。这种实践比纯看书有效得多。在工具链上我建议至少会使用qemu、gdb、crash、/proc/self/pagemap这四样工具必要时再配合systemtap或bpftrace跟踪内核函数比如用bpftrace统计缺页异常的类型和次数。当年我是用一个bpftrace一行命令统计每个进程的缺页次数很快定位出一个频繁触发缺页的进程发现它每次读文件都走mmap而不用read导致缺页开销巨大——这类问题放在今天完全可以用perf和bpftrace快速验证。如果你也想深入研究建议从这两个工具开始上手搭配本篇文章里的知识点基本可以独立排查各种内存类问题了。
