1. 内存碎片问题分页要解决的核心矛盾很多人学操作系统第一眼看到“分页存储管理”这六个字脑子里浮现的往往是页表、页框、逻辑地址、物理地址这一堆名词。但如果你只是把知识点背下来做几道换算题很快就会忘干净。我当年在一门系统编程课上做某个内存管理模拟项目X时同样陷入过“能做题但不知道在干什么”的尴尬状态。直到我真正用代码去模拟内存分配才意识到分页存储管理本质上回答的是一个极其朴素的问题为什么一块完整的内存用着用着就剩下一堆分散到没法用的小碎片在分页之前操作系统主流用的是连续分配方案。固定分区简单粗暴但区划死了放不下大作业浪费严重。动态分区稍微灵活一点可以按需切分但运行一段时间后内存里到处是形状各异的空闲块有的只有几百字节新来的进程却需要几MB连续区域于是匹配不上这就产生了外部碎片。就算你用一个空闲链表把这些碎片串起来也不能拿来分配。想让它们合并就得做紧凑把整个内存内容搬来搬去那代价太高了。你可以把连续分配想象成在一个书架上放一排挨着的书。每来一本新书都要找一个连续的空位置整本放下。时间久了书架上的空隙变得七零八落每一段都放不下一整本厚书可是你把所有空隙面积加起来可能放得下三本厚书。这就是碎片化的典型表现。分页思想的精髓是干脆不要求书必须连续摆放。把书架拆成等大的格子把书拆成等大的页每页放进任意一个空格子。这样再零碎的空间只要格子足够大就能被利用起来。存储管理中的对应做法是把物理内存切成固定大小的块叫做页框或物理块大小通常是4KB把进程的逻辑地址空间也切成同样大小的块叫做页或逻辑页。进程的任意一页可以放进任意一个页框不需要连续。这样一来外部碎片彻底消失不像动态分区那样东拼西凑也凑不齐一个大进程。2. 地址拆分的数学基础与转换链路抄起一张逻辑地址怎么把它变成物理地址这是分页存储管理真正动手的第一个关口。假设页大小是4KB也就是2的12次方字节。那么一个逻辑地址比如0x3A5F换成十进制是14943。拆分的规则很简单逻辑地址除以页大小商是页号余数是页内偏移。14943除以4096商是3余量是2655换算成十六进制是0x0A5F。所以这个地址的页号是3页内偏移是0xA5F。等等这里有个细节值得琢磨为什么页大小要是2的整数次幂如果页大小是1000字节你当然也能拆地址只是除法运算代价高。但页大小取2的幂后地址拆分的本质变成了位运算。一个32位地址低12位天然就是页内偏移高20位天然就是页号不需要除法和取模硬件直接截断就完成拆分。这也是为什么你不可能看到哪个真实系统用奇怪的页大小基本都是4KB、8KB、16KB这类2的幂。找到页号之后硬件——准确说是一部分逻辑电路加操作系统协助——拿着页号去查页表。页表是每个进程独享的一张表放在内核地址空间中它的每一项叫做页表项英文缩写PTE。页表项的索引就是页号表项里则记录着该逻辑页对应的物理页框号。拿到页框号之后把页框号左移12位再加上页内偏移就是最终的物理地址了。这里顺带讲一个我见过的初学者常见错误有人把页框号直接和逻辑地址相加得出物理地址。这完全错了。因为页框号和页内偏移是不同维度的信息一个是“第几页框”一个是“页框内第几个字节”。正确的做法是拼接物理地址等于页框号乘以页大小再加上页内偏移。在二进制层面页框号占据高位的位段页内偏移占据低位位段两者是拼出来的不是加出来的。我在模拟项目X里写地址转换模块时用C语言实现了这个逻辑。当时有一段代码看起来是这样// 逻辑地址拆分page_size_bits表示页大小的二进制位数4KB为12 unsigned int page_number logical_address page_size_bits; unsigned int offset logical_address ((1U page_size_bits) - 1); // 查页表page_table是模拟的页表数组 unsigned int frame_number page_table[page_number]; // 拼接物理地址 unsigned int physical_address (frame_number page_size_bits) | offset;代码本身不复杂但我觉得值得强调一下位掩码的意义。页面大小取2的幂之后offset部分直接用低12位与运算就出来了这比用取余快得多。查页表失败的分支——也就是缺页——后面专门讲这里先不提。3. 页表项里到底放了什么PTE字段逐位拆解只记录“页框号”这三个字听起来页表项没什么可聊的但在模拟项目X里我按32位x86风格的PTE字段去做实现时才发现它几乎像一个迷你状态机字段之间是有互相约束关系的。一个典型的32位页表项长这样高20位是物理页框号低12位是标志位。低12位各自都有名字存在位或有效位表示这一页是否真在物理内存中读写位表示这一页是否可写用户/管理员位表示这一页是否允许用户态访问还有访问位、脏位等。如果把这12个位用好你能组合出很丰富的行为。举个例子存在位为0时页框号字段就不可用了。因为这一页根本不在物理内存中你填一个物理页框号也没有意义。缺页异常的处理流程上来第一件事就是检查存在位。如果存在位是1才继续走页框号拼接地址否则就要触发保存现场、查磁盘、调页、更新页表、恢复现场这一整套流程。脏位是我在项目里容易忽略的字段。它表示这一页在调入内存后是否被修改过。如果没被修改以后这一页要被换出到磁盘时根本不需要写回磁盘直接丢掉就好如果被改过换出时必须把内容写回交换区否则数据丢了。这个字段的意义在于性能优化——大多数评测项目如果不考虑这一层也能运行但和真实系统差距就大了。真实系统对脏位的维护是由硬件在每次写操作时自动置位的软件只需要在换出时检查它。访问位则配合页面置换算法使用。比如讲究一点的LRU近似算法时钟替换算法就是用访问位来近似判断页面最近有没有被使用过。你不把访问位单独拆出来就不知道哪一页适合被牺牲掉。我建议自己动手做模拟项目时把PTE定义成一个结构体而不是一个裸的unsigned inttypedef struct { unsigned int present : 1; // 存在位 unsigned int writable : 1; // 可写位 unsigned int user : 1; // 用户态可访问 unsigned int accessed : 1; // 访问位 unsigned int dirty : 1; // 脏位 unsigned int reserved : 7; // 保留位 unsigned int frame : 20; // 页框号 } pte_t;别小看位域的用法这种结构体写法比手动位移的版本直观得多调试时看一眼结构体就能知道哪一位出了错。我写第一版代码时用的是裸unsigned int排错的时候全靠打日志后来改成结构体效率高了一截。做这类系统级模拟项目代码可读性本身就是生产力。4. 多级页表与反向页表应对大地址空间的工程玄机直接使用一级页表逻辑上最简单但工程上完全不可行。这是我在做分页模拟时遇到的下一个坎。以32位地址空间为例假设页大小4KB逻辑地址有2的20次方个页也就是1048576个页。每个页表项占4字节那么每个进程光页表就要占4MB内存。如果系统同时运行一百个进程光页表就要占400MB这还只是页表不是数据本身。页大小为4KB时4MB内存大约对应1M个页框页表的大小占整个物理内存的千分之一。看着不多但考虑到现实系统中每个进程都要有独立页表这个开销完全失控。更麻烦的是进程通常只使用地址空间的一小部分。一个进程虽然理论上可以有4GB的逻辑地址范围但实际跑起来可能只用了不到几百MB。一级页表不管你用不用都得给全部1048576个表项占用空间。这在内存管理上完全不能接受。多级页表的思路就是让页表本身也可以稀疏地放在物理内存里按需分配二级页表。比如x86风格的两级页表第一级叫页目录共1024项每项指向一个二级页表第二级共1024项每项指向一个物理页框。逻辑地址被拆成三段高10位是页目录索引中间10位是页表索引低12位是页内偏移。这样做有什么好处如果一个进程只使用了一小块地址空间就只需要分配一个页目录4KB加上少量二级页表每个4KB而不用一口气给全部1024个二级页表都分配好。整个页表空间是在进程访问缺页时慢慢建立起来的。我模拟过一个极端例子某进程只访问了地址0x00000000到0x00400000之间的空间也就是64MB它只需要一个页目录加16个二级页表总共约68KB的页表空间。如果用一级页表不管访问范围多小都固定是4MB。这两个数量级差得有点过分了。多级页表的代价是多了一次访问内存才能查到物理地址。一级页表查一次内存就够了两级页表要先查页目录再查页表最后访问目标地址相当于三次内存访问。如果每级页表都命中TLB这个代价可以忽略但万一TLB没命中性能损耗就明显了。所以工程上不会无限增加页表级数64位系统用四级页表就已经让很多人抱怨地址转换代价高Intel后来提出五级页表已经算很激进的方案了。反向页表又是另一个思路既然每个进程都要一张大页表很浪费干脆整个系统只维护一张表表的每一项对应一个物理页框记录“这个页框正被哪个进程的哪一页占据”。但是反向页表带来了一个搜索难题——你要根据逻辑页号反查到物理页框必须遍历整张反向表效率很低。所以实际系统多会配一个哈希加速结构增加了实现的复杂度普及程度不如多级页表。5. TLB快表CPU缓存思维在内存管理中的投影做分页模拟项目的时候如果只把逻辑地址和物理地址转换做到正确性能会极其难看。我第一次跑模拟时用的是逐条指令访问内存的驱动方式每条指令都要查页表而页表又放在内存里于是每转换一个地址就要多访问好几次内存。数据量一大模拟器慢得让人怀疑人生。真实硬件不会这么傻。CPU内部有一个专门用于地址转换的小缓存叫转换后备缓冲器英文缩写TLB也就是快表。它的核心思想跟CPU的高速缓存一脉相承最近的地址转换结果很可能在接下来还会被重复用到那就把它暂存起来下次直接命中。TLB的表项结构其实和页表项类似但多了两个关键信息逻辑页号和一个进程标识符之类的字段。为什么要有进程标识符因为每个进程都有独立的页表你的逻辑页号3在我的进程里可能指向完全不同的物理页框。如果TLB不区分进程从进程A切换到进程B时TLB里的旧映射就是错的。处理方式有两种一是进程切换时直接清空TLB简单但会损失刚建立的命中信息二是在TLB表项里记录地址空间标识符允许不同进程的转换结果共存命中时多检查一次标识符匹配。现在中等以上性能的处理器普遍支持地址空间标识符大家看CPU参数里所谓“上下文切换开销更小”这类描述背后的原因之一就在这里。TLB的命中率对整个系统性能影响有多大我拿模拟项目X做了个基准测试在没有TLB的纯软件模拟环境里执行一个包含100万次访存指令的测试程序地址转换相关的时间占了大约总运行时间的四成加入一个只有64项的模拟TLB后这个比例降到一成以下。有一次我用一个16项的小TLB跑一个跳跃访问型的测试程序命中率只有70%左右耗时依旧可观换个顺序访问型的测试程序命中率有98%耗时明显下降。这就说明测试程序访存局部性好TLB命中率就高狂跳着访问大范围内存TLB就发挥不出效果。TLB全称虽是“转换后备缓冲器”但本质就是一种缓存。管理TLB淘汰策略时主流方案都是近似的LRU不会真去记录全局时间戳那样代价太高。有些处理器用随机替换策略虽然某些场景下命中率略低但胜在电路简单、省电。做模拟项目时不必把硬件细节做十分逼真用一个哈希数组加简单替换策略就足够体现设计思路。6. 缺页中断与页面置换算法的实战选择内存管理到了缺页中断这一环才真正把操作系统和计算机组成原理融合在一起。没有缺页机制分页存储管理只是静态的地址映射有了缺页机制它才成为一个动态、自适应的存储系统。缺页流程大致是CPU访问某个逻辑地址查页表发现存在位为0立刻触发缺页异常。硬件部分会保存当前进程的现场包括程序计数器和相关寄存器然后跳转到操作系统预设的缺页处理函数。操作系统的工作是找到一个空闲物理页框如果找不到就要按置换算法淘汰一个旧页面接着从磁盘的交换区或可执行文件中读取缺失页面写入这个页框随后更新页表项把存在位置1填入页框号最后恢复现场重新执行那条触发缺页的指令。其中“重新执行指令”有一处坑一般人容易忽略。模拟器实现时如果简单地从缺页指令的下一条继续执行程序会直接得出错误结果。真实硬件和设计严谨的系统都要求重新执行原指令。这也导致一些指令不能随意放在跨页边界比如某些指令只能位于页内不能跨页否则缺页恢复时重新执行的语义就变得极其复杂。我做的模拟项目里踩过这个坑后来解决方法是把缺页返回地址设成当前指令地址而不是下一条指令地址。页面置换算法是这个流程的重要决策点。一个测试程序好坏很大程度取决于它访问序列的局部性而置换算法的质量决定物理内存不够时系统还能不能稳定推进。我在一次实验里对比了三大类算法说几个我觉得重要的观察FIFO算法实现最简单维护一个队列淘汰最早进入内存的页面。但它不考虑页面使用频率很笨。更糟的是它可能出现Belady异常——物理页框增加缺页次数反而增加。第一次看到这个现象时我反复检查代码以为逻辑错了后来确认确实是FIFO的特性。LRU算法理论上最贴近最优置换算法需要知道每个页面最后一次访问的时间每次淘汰最久未使用的那一个。但真实系统给每个页面维护一个精确的“最近使用时间”开销太大。实践中使用近似实现最常见的是时钟算法也叫CLOCK或第二次机会算法。维护一个环形链表给每页一个访问位。淘汰时从指针位置遍历遇到访问位为1的先置0然后跳过遇到访问位为0的就淘汰它。这个过程实质上是给那些“最近被用过”的页面第二次机会效果比FIFO好很多实现代价又不高。简单说在模拟项目中最容易见效的顺序是先实现FIFO再升级成简单的第二次机会算法最后再看情况做更精细的LRU近似。如果你一上来就试图实现精确LRU很快会陷入维护时间戳和堆结构的泥潭与学习分页机制的目标背道而驰。算法实现成本性能表现典型缺点FIFO很低一般可能出现Belady异常精确LRU很高接近最优真实系统不可行CLOCK/第二次机会低良好近似不保证绝对最优一次课上实验我用模拟项目X分别跑FIFO和CLOCK处理同一组随机访问序列物理页框数设成4个。FIFO缺页次数为84次CLOCK为67次。单独看不觉得CLOCK有多好但把物理页框调到5再跑FIFO的缺页次数反而升到91次CLOCK降到58次。Belady异常是真的会发生不是课本吓唬人。7. 模拟项目X实现过程中的几个典型错误与排查经验代码层面的坑往往比理论更折磨人。我把印象深刻的几个错误及其排查思路整理一下供做类似模拟的同学参考。第一个坑是逻辑地址参数没有验证就使用。页号大概率都在合法范围内但页内偏移有可能出问题。我写第一版地址转换函数时只检查了页号是否越界忽略了页内偏移字段结果跑一段随机生成的地址序列直接数组越界崩溃半天才找到原因。后来我养成了一个习惯无论多简单的解析函数入口第一件事就是断言参数合法。这个习惯在后续好几个项目里救了我。最典型的越界是“逻辑地址等于页大小的两倍减一个字节”这类边界值建议写测试用例时把边界全测一遍。第二个坑是PTE有效位和页框号字段混用。前面提过存在位为0时页框号是无意义的。有一次我的置换逻辑没有先判断存在位直接读页框号去拼接物理地址得到的结果看似有规律实则完全错误。排查时我打印出每个PTE的完整字段才发现那些“存在位0”的PTE页框号字段残留的是上次使用的旧值造成一种“映射好像存在”的假象。正确做法是查到PTE后先测存在位再决定下一步。第三个坑是缺页处理时机不对。我写的模拟器一开始在每次访存指令前都同步检查缺页但缺页处理本身又可能触发新的缺页处理新缺页过程中又访问同一块内存于是陷入递归栈溢出。这提醒我一个重要的设计原则缺页处理全程必须在关中断或相应屏蔽机制保护下进行至少在缺页处理函数内部不能再接受新的缺页中断。这个约束在真实内核里也存在只不过体现为中断屏蔽和内核态栈保护。做模拟时如果没有这层设计一定会踩栈溢出的坑。第四个坑是关于数据一致性的。页表更新了但TLB里的旧映射还在。模拟器里我自己维护TLB经常出现“页表明明已经改了但程序还是访问到旧地址”的奇怪现象。排查下来发现是我在做缺页处理完之后忘了无效化对应的TLB条目。真实的CPU也不会自动帮你把过期的TLB条目清掉所以硬件手册里专门强调软件在修改页表后必须执行失效指令。做模拟项目时不写这段失效逻辑就模拟不出真实系统的诡异行为。最后想分享一个偏实践的建议做这类分页模拟器最好先把日志级别设计好。开发时打开最详细的访存日志能看到每一步的地址拆分、页表查询、TLB命中情况调试稳定后关掉详细日志只保留缺页事件和置换事件。没有这套机制改一次代码要花一倍时间看无意义的输出。我后来给模拟项目X加了一个简单的环境变量开关任何一个级别的日志都能独立控制。说句实话这比加多少特性都值——本来多个分钟的排查现在几十秒就定位了。分页存储管理这一块内容学起来容易做起来会发现理论和工程之间隔着好几个层次的细节。但恰恰是这些细节构成了理解现代操作系统地址空间管理的基础。做模拟项目过程里踩的这些坑回头看基本都是很值得的经验写在这里供后来人参考。 
长河君 · 2026/10/17 15:40:41 · 阅读 1.2k 分页存储管理：从内存碎片到页表、TLB与缺页中断的实战解析
1. 内存碎片问题分页要解决的核心矛盾很多人学操作系统第一眼看到“分页存储管理”这六个字脑子里浮现的往往是页表、页框、逻辑地址、物理地址这一堆名词。但如果你只是把知识点背下来做几道换算题很快就会忘干净。我当年在一门系统编程课上做某个内存管理模拟项目X时同样陷入过“能做题但不知道在干什么”的尴尬状态。直到我真正用代码去模拟内存分配才意识到分页存储管理本质上回答的是一个极其朴素的问题为什么一块完整的内存用着用着就剩下一堆分散到没法用的小碎片在分页之前操作系统主流用的是连续分配方案。固定分区简单粗暴但区划死了放不下大作业浪费严重。动态分区稍微灵活一点可以按需切分但运行一段时间后内存里到处是形状各异的空闲块有的只有几百字节新来的进程却需要几MB连续区域于是匹配不上这就产生了外部碎片。就算你用一个空闲链表把这些碎片串起来也不能拿来分配。想让它们合并就得做紧凑把整个内存内容搬来搬去那代价太高了。你可以把连续分配想象成在一个书架上放一排挨着的书。每来一本新书都要找一个连续的空位置整本放下。时间久了书架上的空隙变得七零八落每一段都放不下一整本厚书可是你把所有空隙面积加起来可能放得下三本厚书。这就是碎片化的典型表现。分页思想的精髓是干脆不要求书必须连续摆放。把书架拆成等大的格子把书拆成等大的页每页放进任意一个空格子。这样再零碎的空间只要格子足够大就能被利用起来。存储管理中的对应做法是把物理内存切成固定大小的块叫做页框或物理块大小通常是4KB把进程的逻辑地址空间也切成同样大小的块叫做页或逻辑页。进程的任意一页可以放进任意一个页框不需要连续。这样一来外部碎片彻底消失不像动态分区那样东拼西凑也凑不齐一个大进程。2. 地址拆分的数学基础与转换链路抄起一张逻辑地址怎么把它变成物理地址这是分页存储管理真正动手的第一个关口。假设页大小是4KB也就是2的12次方字节。那么一个逻辑地址比如0x3A5F换成十进制是14943。拆分的规则很简单逻辑地址除以页大小商是页号余数是页内偏移。14943除以4096商是3余量是2655换算成十六进制是0x0A5F。所以这个地址的页号是3页内偏移是0xA5F。等等这里有个细节值得琢磨为什么页大小要是2的整数次幂如果页大小是1000字节你当然也能拆地址只是除法运算代价高。但页大小取2的幂后地址拆分的本质变成了位运算。一个32位地址低12位天然就是页内偏移高20位天然就是页号不需要除法和取模硬件直接截断就完成拆分。这也是为什么你不可能看到哪个真实系统用奇怪的页大小基本都是4KB、8KB、16KB这类2的幂。找到页号之后硬件——准确说是一部分逻辑电路加操作系统协助——拿着页号去查页表。页表是每个进程独享的一张表放在内核地址空间中它的每一项叫做页表项英文缩写PTE。页表项的索引就是页号表项里则记录着该逻辑页对应的物理页框号。拿到页框号之后把页框号左移12位再加上页内偏移就是最终的物理地址了。这里顺带讲一个我见过的初学者常见错误有人把页框号直接和逻辑地址相加得出物理地址。这完全错了。因为页框号和页内偏移是不同维度的信息一个是“第几页框”一个是“页框内第几个字节”。正确的做法是拼接物理地址等于页框号乘以页大小再加上页内偏移。在二进制层面页框号占据高位的位段页内偏移占据低位位段两者是拼出来的不是加出来的。我在模拟项目X里写地址转换模块时用C语言实现了这个逻辑。当时有一段代码看起来是这样// 逻辑地址拆分page_size_bits表示页大小的二进制位数4KB为12 unsigned int page_number logical_address page_size_bits; unsigned int offset logical_address ((1U page_size_bits) - 1); // 查页表page_table是模拟的页表数组 unsigned int frame_number page_table[page_number]; // 拼接物理地址 unsigned int physical_address (frame_number page_size_bits) | offset;代码本身不复杂但我觉得值得强调一下位掩码的意义。页面大小取2的幂之后offset部分直接用低12位与运算就出来了这比用取余快得多。查页表失败的分支——也就是缺页——后面专门讲这里先不提。3. 页表项里到底放了什么PTE字段逐位拆解只记录“页框号”这三个字听起来页表项没什么可聊的但在模拟项目X里我按32位x86风格的PTE字段去做实现时才发现它几乎像一个迷你状态机字段之间是有互相约束关系的。一个典型的32位页表项长这样高20位是物理页框号低12位是标志位。低12位各自都有名字存在位或有效位表示这一页是否真在物理内存中读写位表示这一页是否可写用户/管理员位表示这一页是否允许用户态访问还有访问位、脏位等。如果把这12个位用好你能组合出很丰富的行为。举个例子存在位为0时页框号字段就不可用了。因为这一页根本不在物理内存中你填一个物理页框号也没有意义。缺页异常的处理流程上来第一件事就是检查存在位。如果存在位是1才继续走页框号拼接地址否则就要触发保存现场、查磁盘、调页、更新页表、恢复现场这一整套流程。脏位是我在项目里容易忽略的字段。它表示这一页在调入内存后是否被修改过。如果没被修改以后这一页要被换出到磁盘时根本不需要写回磁盘直接丢掉就好如果被改过换出时必须把内容写回交换区否则数据丢了。这个字段的意义在于性能优化——大多数评测项目如果不考虑这一层也能运行但和真实系统差距就大了。真实系统对脏位的维护是由硬件在每次写操作时自动置位的软件只需要在换出时检查它。访问位则配合页面置换算法使用。比如讲究一点的LRU近似算法时钟替换算法就是用访问位来近似判断页面最近有没有被使用过。你不把访问位单独拆出来就不知道哪一页适合被牺牲掉。我建议自己动手做模拟项目时把PTE定义成一个结构体而不是一个裸的unsigned inttypedef struct { unsigned int present : 1; // 存在位 unsigned int writable : 1; // 可写位 unsigned int user : 1; // 用户态可访问 unsigned int accessed : 1; // 访问位 unsigned int dirty : 1; // 脏位 unsigned int reserved : 7; // 保留位 unsigned int frame : 20; // 页框号 } pte_t;别小看位域的用法这种结构体写法比手动位移的版本直观得多调试时看一眼结构体就能知道哪一位出了错。我写第一版代码时用的是裸unsigned int排错的时候全靠打日志后来改成结构体效率高了一截。做这类系统级模拟项目代码可读性本身就是生产力。4. 多级页表与反向页表应对大地址空间的工程玄机直接使用一级页表逻辑上最简单但工程上完全不可行。这是我在做分页模拟时遇到的下一个坎。以32位地址空间为例假设页大小4KB逻辑地址有2的20次方个页也就是1048576个页。每个页表项占4字节那么每个进程光页表就要占4MB内存。如果系统同时运行一百个进程光页表就要占400MB这还只是页表不是数据本身。页大小为4KB时4MB内存大约对应1M个页框页表的大小占整个物理内存的千分之一。看着不多但考虑到现实系统中每个进程都要有独立页表这个开销完全失控。更麻烦的是进程通常只使用地址空间的一小部分。一个进程虽然理论上可以有4GB的逻辑地址范围但实际跑起来可能只用了不到几百MB。一级页表不管你用不用都得给全部1048576个表项占用空间。这在内存管理上完全不能接受。多级页表的思路就是让页表本身也可以稀疏地放在物理内存里按需分配二级页表。比如x86风格的两级页表第一级叫页目录共1024项每项指向一个二级页表第二级共1024项每项指向一个物理页框。逻辑地址被拆成三段高10位是页目录索引中间10位是页表索引低12位是页内偏移。这样做有什么好处如果一个进程只使用了一小块地址空间就只需要分配一个页目录4KB加上少量二级页表每个4KB而不用一口气给全部1024个二级页表都分配好。整个页表空间是在进程访问缺页时慢慢建立起来的。我模拟过一个极端例子某进程只访问了地址0x00000000到0x00400000之间的空间也就是64MB它只需要一个页目录加16个二级页表总共约68KB的页表空间。如果用一级页表不管访问范围多小都固定是4MB。这两个数量级差得有点过分了。多级页表的代价是多了一次访问内存才能查到物理地址。一级页表查一次内存就够了两级页表要先查页目录再查页表最后访问目标地址相当于三次内存访问。如果每级页表都命中TLB这个代价可以忽略但万一TLB没命中性能损耗就明显了。所以工程上不会无限增加页表级数64位系统用四级页表就已经让很多人抱怨地址转换代价高Intel后来提出五级页表已经算很激进的方案了。反向页表又是另一个思路既然每个进程都要一张大页表很浪费干脆整个系统只维护一张表表的每一项对应一个物理页框记录“这个页框正被哪个进程的哪一页占据”。但是反向页表带来了一个搜索难题——你要根据逻辑页号反查到物理页框必须遍历整张反向表效率很低。所以实际系统多会配一个哈希加速结构增加了实现的复杂度普及程度不如多级页表。5. TLB快表CPU缓存思维在内存管理中的投影做分页模拟项目的时候如果只把逻辑地址和物理地址转换做到正确性能会极其难看。我第一次跑模拟时用的是逐条指令访问内存的驱动方式每条指令都要查页表而页表又放在内存里于是每转换一个地址就要多访问好几次内存。数据量一大模拟器慢得让人怀疑人生。真实硬件不会这么傻。CPU内部有一个专门用于地址转换的小缓存叫转换后备缓冲器英文缩写TLB也就是快表。它的核心思想跟CPU的高速缓存一脉相承最近的地址转换结果很可能在接下来还会被重复用到那就把它暂存起来下次直接命中。TLB的表项结构其实和页表项类似但多了两个关键信息逻辑页号和一个进程标识符之类的字段。为什么要有进程标识符因为每个进程都有独立的页表你的逻辑页号3在我的进程里可能指向完全不同的物理页框。如果TLB不区分进程从进程A切换到进程B时TLB里的旧映射就是错的。处理方式有两种一是进程切换时直接清空TLB简单但会损失刚建立的命中信息二是在TLB表项里记录地址空间标识符允许不同进程的转换结果共存命中时多检查一次标识符匹配。现在中等以上性能的处理器普遍支持地址空间标识符大家看CPU参数里所谓“上下文切换开销更小”这类描述背后的原因之一就在这里。TLB的命中率对整个系统性能影响有多大我拿模拟项目X做了个基准测试在没有TLB的纯软件模拟环境里执行一个包含100万次访存指令的测试程序地址转换相关的时间占了大约总运行时间的四成加入一个只有64项的模拟TLB后这个比例降到一成以下。有一次我用一个16项的小TLB跑一个跳跃访问型的测试程序命中率只有70%左右耗时依旧可观换个顺序访问型的测试程序命中率有98%耗时明显下降。这就说明测试程序访存局部性好TLB命中率就高狂跳着访问大范围内存TLB就发挥不出效果。TLB全称虽是“转换后备缓冲器”但本质就是一种缓存。管理TLB淘汰策略时主流方案都是近似的LRU不会真去记录全局时间戳那样代价太高。有些处理器用随机替换策略虽然某些场景下命中率略低但胜在电路简单、省电。做模拟项目时不必把硬件细节做十分逼真用一个哈希数组加简单替换策略就足够体现设计思路。6. 缺页中断与页面置换算法的实战选择内存管理到了缺页中断这一环才真正把操作系统和计算机组成原理融合在一起。没有缺页机制分页存储管理只是静态的地址映射有了缺页机制它才成为一个动态、自适应的存储系统。缺页流程大致是CPU访问某个逻辑地址查页表发现存在位为0立刻触发缺页异常。硬件部分会保存当前进程的现场包括程序计数器和相关寄存器然后跳转到操作系统预设的缺页处理函数。操作系统的工作是找到一个空闲物理页框如果找不到就要按置换算法淘汰一个旧页面接着从磁盘的交换区或可执行文件中读取缺失页面写入这个页框随后更新页表项把存在位置1填入页框号最后恢复现场重新执行那条触发缺页的指令。其中“重新执行指令”有一处坑一般人容易忽略。模拟器实现时如果简单地从缺页指令的下一条继续执行程序会直接得出错误结果。真实硬件和设计严谨的系统都要求重新执行原指令。这也导致一些指令不能随意放在跨页边界比如某些指令只能位于页内不能跨页否则缺页恢复时重新执行的语义就变得极其复杂。我做的模拟项目里踩过这个坑后来解决方法是把缺页返回地址设成当前指令地址而不是下一条指令地址。页面置换算法是这个流程的重要决策点。一个测试程序好坏很大程度取决于它访问序列的局部性而置换算法的质量决定物理内存不够时系统还能不能稳定推进。我在一次实验里对比了三大类算法说几个我觉得重要的观察FIFO算法实现最简单维护一个队列淘汰最早进入内存的页面。但它不考虑页面使用频率很笨。更糟的是它可能出现Belady异常——物理页框增加缺页次数反而增加。第一次看到这个现象时我反复检查代码以为逻辑错了后来确认确实是FIFO的特性。LRU算法理论上最贴近最优置换算法需要知道每个页面最后一次访问的时间每次淘汰最久未使用的那一个。但真实系统给每个页面维护一个精确的“最近使用时间”开销太大。实践中使用近似实现最常见的是时钟算法也叫CLOCK或第二次机会算法。维护一个环形链表给每页一个访问位。淘汰时从指针位置遍历遇到访问位为1的先置0然后跳过遇到访问位为0的就淘汰它。这个过程实质上是给那些“最近被用过”的页面第二次机会效果比FIFO好很多实现代价又不高。简单说在模拟项目中最容易见效的顺序是先实现FIFO再升级成简单的第二次机会算法最后再看情况做更精细的LRU近似。如果你一上来就试图实现精确LRU很快会陷入维护时间戳和堆结构的泥潭与学习分页机制的目标背道而驰。算法实现成本性能表现典型缺点FIFO很低一般可能出现Belady异常精确LRU很高接近最优真实系统不可行CLOCK/第二次机会低良好近似不保证绝对最优一次课上实验我用模拟项目X分别跑FIFO和CLOCK处理同一组随机访问序列物理页框数设成4个。FIFO缺页次数为84次CLOCK为67次。单独看不觉得CLOCK有多好但把物理页框调到5再跑FIFO的缺页次数反而升到91次CLOCK降到58次。Belady异常是真的会发生不是课本吓唬人。7. 模拟项目X实现过程中的几个典型错误与排查经验代码层面的坑往往比理论更折磨人。我把印象深刻的几个错误及其排查思路整理一下供做类似模拟的同学参考。第一个坑是逻辑地址参数没有验证就使用。页号大概率都在合法范围内但页内偏移有可能出问题。我写第一版地址转换函数时只检查了页号是否越界忽略了页内偏移字段结果跑一段随机生成的地址序列直接数组越界崩溃半天才找到原因。后来我养成了一个习惯无论多简单的解析函数入口第一件事就是断言参数合法。这个习惯在后续好几个项目里救了我。最典型的越界是“逻辑地址等于页大小的两倍减一个字节”这类边界值建议写测试用例时把边界全测一遍。第二个坑是PTE有效位和页框号字段混用。前面提过存在位为0时页框号是无意义的。有一次我的置换逻辑没有先判断存在位直接读页框号去拼接物理地址得到的结果看似有规律实则完全错误。排查时我打印出每个PTE的完整字段才发现那些“存在位0”的PTE页框号字段残留的是上次使用的旧值造成一种“映射好像存在”的假象。正确做法是查到PTE后先测存在位再决定下一步。第三个坑是缺页处理时机不对。我写的模拟器一开始在每次访存指令前都同步检查缺页但缺页处理本身又可能触发新的缺页处理新缺页过程中又访问同一块内存于是陷入递归栈溢出。这提醒我一个重要的设计原则缺页处理全程必须在关中断或相应屏蔽机制保护下进行至少在缺页处理函数内部不能再接受新的缺页中断。这个约束在真实内核里也存在只不过体现为中断屏蔽和内核态栈保护。做模拟时如果没有这层设计一定会踩栈溢出的坑。第四个坑是关于数据一致性的。页表更新了但TLB里的旧映射还在。模拟器里我自己维护TLB经常出现“页表明明已经改了但程序还是访问到旧地址”的奇怪现象。排查下来发现是我在做缺页处理完之后忘了无效化对应的TLB条目。真实的CPU也不会自动帮你把过期的TLB条目清掉所以硬件手册里专门强调软件在修改页表后必须执行失效指令。做模拟项目时不写这段失效逻辑就模拟不出真实系统的诡异行为。最后想分享一个偏实践的建议做这类分页模拟器最好先把日志级别设计好。开发时打开最详细的访存日志能看到每一步的地址拆分、页表查询、TLB命中情况调试稳定后关掉详细日志只保留缺页事件和置换事件。没有这套机制改一次代码要花一倍时间看无意义的输出。我后来给模拟项目X加了一个简单的环境变量开关任何一个级别的日志都能独立控制。说句实话这比加多少特性都值——本来多个分钟的排查现在几十秒就定位了。分页存储管理这一块内容学起来容易做起来会发现理论和工程之间隔着好几个层次的细节。但恰恰是这些细节构成了理解现代操作系统地址空间管理的基础。做模拟项目过程里踩的这些坑回头看基本都是很值得的经验写在这里供后来人参考。