以前我对操作系统的内存管理一直停留在“malloc一调用背后肯定默默给你分配了一大块物理内存”这种认知。直到做完MIT6.S081的Lab4惰性分配我才发现自己错得离谱真正的操作系统根本没那么“勤快”你申请地址空间它只是先记一笔账等你真去读写那一页时才临时把物理页塞给你。这篇记录是我MIT6.S081学习系列的第五篇专门讲xv6实验里的lazy allocation惰性分配。我尽量把原理、代码改动、调试过程和踩坑经历都写清楚适合正在做Lab4但被缺页异常和守护页搞到一头雾水的同学也适合想了解现代操作系统为何普遍采用惰性内存分配策略的读者。如果你只想要现成答案下文也有可直接抄的代码如果你想弄明白“为什么这么改”那就更要多看几遍调试实录。1. 惰性分配到底想解决什么问题1.1 传统sbrk的“即时分配”行为xv6里用户程序扩展堆内存靠的是sys_sbrk这个系统调用。默认实现是收到一个n字节的请求后立刻把地址空间扩大并且伴随uvmalloc逐页分配物理内存、建立页表映射。也就是说sbrk(10000)一返回你要的那一万字节已经被真实物理页占住了哪怕你永远不会写它们。问题就在这。很多程序会一次性申请很大一块地址空间但实际只触碰其中一小部分。比如读取一个大文件时先根据文件大小预留整个缓冲区动态数组扩容时习惯性翻倍预留空间某些程序干脆预留了几乎不可能全部用到的栈空间或稀疏数组。如果操作系统在每次malloc背后都老老实实分配物理页轻则浪费物理内存重则拖慢系统。因为uvmalloc要遍历每个页、kalloc分配内存、再逐页填写页表项PTE一个sbrk系统调用里可能做了成千上万次操作。1.2 惰性分配的核心思想惰性分配的原则很简单延迟到最后一刻。sbrk只修改进程地址空间的上界p-sz不分配任何物理页也不建立页表映射。之后CPU访问这一范围内的空地址时MMU找不到对应的PTE就会触发缺页异常内核在缺页异常处理里发现这个地址“合法”此时才kalloc一页物理内存把PTE补上。这样一改系统调用本身变成O(1)操作物理内存也只在实际使用的时候才消耗。整个分配粒度也从“一次申请多少就给多少”变成“一页一页按需供给”。为了方便对比我把两种方式的关键差异整理成了一张表对比维度立即分配惰性分配sbrk系统调用开销与分配字节数成正比固定基本忽略不计物理内存占用分配时立即占用实际访问才占用地址空间越界行为分配时返回错误运行时触发缺页需额外判断对物理内存碎片的影响较高较低实现复杂度简单需处理缺页异常和边界情况从工程角度看惰性分配不是“省了系统调用的时间”这么简单它还为更高级的内存特性铺路。Linux里malloc大块内存后没有立即触碰物理内存迟迟不分配就是这个机制在起作用fork的写时复制、mmap文件映射也大量依赖延迟分配的思想。xv6这个实验虽然只是最小实现但它把这条链路上的核心环节全部暴露出来了所以非常值得亲手做完。2. 动手之前必须搞清的三个底层概念2.1 虚拟地址、页表与PTE的组成在xv6中每个用户进程都有一个独立页表。页表由多级页表组成RISC-V版是三级页表最后一级的页表项PTE里包含了关键的标志位PTE_V该页是否有效也就是是否已经映射了物理页PTE_R、PTE_W、PTE_X可读、可写、可执行PTE_U用户态可访问PPN字段物理页号指向实际的物理页。当PTE_V为0时CPU访问这个虚拟地址就会触发缺页异常。惰性分配的核心操作之一就是让sbrk不再为新增的地址建立PTE而只记住“这个范围属于进程”等缺页时再补建。xv6的地址空间布局也很关键开头是代码段往上依次是数据段、堆栈放在用户地址空间的最高处栈下方有一个独立的守护页guard page。进程地址空间上界记录在p-sz中它代表“合法虚拟地址的最大值”。任何大于等于p-sz的用户地址在正常堆操作下都被视为非法但栈地址是特例它从高处往低处增长实验中通常也需要单独考虑xv6的trapframe已经映射了其他细节。2.2 从虚拟地址到物理地址的缺失路径CPU执行指令访问某个虚拟地址时会先查页表。页表命中就拿到物理地址直接访问没命中且PTE_V0就会触发缺页异常陷入内核进入usertrap。在xv6的trap.c里用户态缺页异常会通过scause寄存器判断异常原因。RISC-V中scause12指令页错误scause13读页错误scause15写页错误。如何知道“缺在了哪个虚拟地址”答案是读stval寄存器它保存触发页错误的虚拟地址。所以惰性分配实验的常规做法就是在usertrap里识别scause是否为13或15再读stval拿到故障地址判断是否需要补页。2.3 用户态与内核态的转换xv6每个用户进程都保存了一个trapframe用于陷入内核时保存用户寄存器状态。usertrap处理完缺页异常后会返回用户态继续执行之前那条发生缺页的指令。这里有个容易忽略的细节缺页异常处理完成后CPU会重新执行触发异常的指令。如果我们在缺页处理里正确建立了映射被中断的指令就会顺利完成如果处理失败必须杀掉进程否则还会再次进入缺页循环。如果对这几个概念还不太熟我建议先动手读一读xv6源码里的vm.c、trap.c和proc.c不要急着改代码。我在做实验时最大的感受是只要理解了“页表只是地址映射不保证页面一定存在”这一点整个惰性分配的实现逻辑就清晰了大半。3. 核心实现只改两处代码让sbrk“只记账不付款”3.1 修改sys_sbrk去掉物理页分配xv6中系统调用的入口在kernel/sysproc.c本来长这样uint64 sys_sbrk(void) { int addr; int n; struct proc *p myproc(); if(argint(0, n) 0) return -1; addr p-sz; if(growproc(n) 0) return -1; return addr; }而growproc内部会根据n的正负调用uvmalloc或uvmdealloc完成实际物理内存分配。惰性分配的思路是绕过growproc直接修改p-sz不分配物理页uint64 sys_sbrk(void) { int addr; int n; struct proc *p myproc(); if(argint(0, n) 0) return -1; addr p-sz; p-sz n; return addr; }注意原来的growproc还做了负数判断和地址溢出检查这里为了简洁先不管实验测试也一般不会传负数。但我建议至少判断一下n为负时不能让p-sz变成负数否则后面访问任何地址都会被认为是合法范围隐患很大。就这么几行改动sys_sbrk立刻变得“飞快”。用户程序申请1GB内存也只是一次寄存器操作物理内存一点不动。3.2 在usertrap中处理缺页异常接下来是重头戏在kernel/trap.c的usertrap中识别用户态缺页异常并补页。先读异常原因和故障地址uint64 scause r_scause(); uint64 stval r_stval();然后判断if((scause 13 || scause 15) stval p-sz) { // 合法范围内按需分配一页 uint64 va PGROUNDDOWN(stval); char *mem kalloc(); if(mem 0) { p-killed 1; } else { memset(mem, 0, PGSIZE); if(mappages(p-pagetable, va, PGSIZE, (uint64)mem, PTE_W|PTE_X|PTE_R|PTE_U) ! 0) { kfree(mem); p-killed 1; } } }这里几个细节需要解释scause等于13或15分别对应读、写缺页实验要求一般只处理这两种stval p-sz判断故障地址是否在进程合法地址空间内。惰性分配允许的范围就是“已经被sbrk扩展但尚未建立映射”的地址段PGROUNDDOWN(stval)把故障地址向下取整到页边界。缺页发生在某个页内的任意位置我们一次性补一整页kalloc()分配物理页memset清零然后用mappages建立PTE并设置标志位可读可写可执行对应普通数据页如果mappages失败说明这个虚拟地址本身有其他映射冲突必须释放物理页并杀掉进程。这段代码放的位置也有讲究一般放在usertrap中处理其他例外之前。xv6默认的处理流程是如果scause是8系统调用走系统调用处理否则如果进程被杀或被信号标记就退出。缺页异常就走新增的这个分支。3.3 为什么不直接调用uvmalloc可能有同学会想既然要建映射为什么不直接调用现成的uvmalloc我给个理由uvmalloc是从oldsz到newsz按范围循环建映射它内部会自己处理从旧大小开始的每次分配而且它的设计默认“旧范围已全映射”在惰性分配下旧范围可能根本没映射用它反而会把不该映射的页也补上。另外缺页异常是“一页一页”发生的按故障地址精确补一页即可用uvmalloc会造成多余的分配和页表遍历。我最初偷懒直接调uvmalloc(p-pagetable, PGROUNDDOWN(stval), PGROUNDDOWN(stval)PGSIZE)结果出现了双重映射和旧边界处理混乱最后还是老老实实按单页分配。做实验别怕多写几行代码。4. 调试实录三连panic背后的真正原因4.1 panic: uvmunmap: not mapped改完代码第一个跑的就是课程提供的lazytests或简单sbrk测试。结果程序一启动内核直接panicpanic: uvmunmap: not mapped这个panic来自uvmunmap。它通常在进程退出、回收地址空间时被调用逐页遍历页表并释放映射。原版的uvmunmap要求所有PTE都是有效的一旦遇到PTE_V0的页就会panic。而惰性分配恰恰打破了这个假设sbrk扩展了p-sz但那些新地址范围根本没有PTE退出进程时uvmunmap从0到p-sz遍历自然撞上大量无效PTE。解决方法是修改uvmunmap遇到无效PTE直接跳过而不是panicif((pte walk(pagetable, a, 0)) 0) panic(uvmunmap: walk); if((*pte PTE_V) 0) continue; // 跳过未映射页而不是panic这里面的哲学是惰性分配让“地址空间有效”和“页表已映射”不再是同一件事。回收地址空间时只回收真正建立映射的页就行没映射的地址直接跳过。4.2 panic: uvmcopy: page not present修复第一个panic后接着遇到第二个这次发生在fork时panic: uvmcopy: page not presentfork会调用uvmcopy把父进程的用户页表完整复制一份给子进程。原版uvmcopy也假设源页表全部有效逐页复制PTE、分配新的物理页。现在父进程存在一个“已扩展但未映射”的地址段uvmcopy遍历到这些地址时同样看到PTE_V0于是panic。修复方式与uvmunmap一致遇到无效PTE就跳过。if((pte walk(oldpagetable, i, 0)) 0) panic(uvmcopy: pte should exist); if((*pte PTE_V) 0) continue;这里值得多思考几秒跳过未映射页是否会让子进程出错不会。惰性分配的子进程同样遵循“缺页时再补”的约定子进程访问那些地址时会用自己的usertrap补页所以跳过是完全合理的。这种分布式的“按需补页”机制正是惰性分配能够自然推广到fork的基础。4.3 第三个坑地址范围判断过松两个panic修完后基础测试能跑了但我手工测试时又碰到一个新问题。我给一段超过p-sz的地址赋值程序居然也“正常”分配了页并返回完全不像一个非法访问该有的样子。排查后发现问题出在缺页处理的分支顺序上。我把缺页异常处理逻辑放在usertrap的入口却没有在最终执行“杀进程”逻辑时正确标记错误。更隐蔽的是有些情况下scause不是13或15被默认分支杀掉是正常的但如果是合法的15stval却大于等于p-sz就说明程序越界访问了这时必须设置p-killed 1杀掉进程而不是分配内存。一个更完整的判断应该长这样if(scause 13 || scause 15) { if(stval p-sz) { // 合法惰性范围补页 } else if((p-trapframe-sp - stval) PGSIZE) { // 可能是栈向下增长越过栈顶但还在一个页范围内 } else { p-killed 1; } }栈的情况后面细说这里最关键的教训是越界的合法地址判断必须足够严不能让非法访问被当成惰性分配请求。我后来复盘时意识到真正严谨的实验要求里访问超过p-sz的地址就应该杀进程这样stval p-sz这一个条件就够用。栈的特殊映射另说。4.4 排查思路总结调试这类问题我通常按三步走看panic信息中的函数名找准是哪个系统调用触发的顺着调用栈回到页表操作函数思考“为什么这里假设页全部映射”把假设条件改成适应惰性分配的语义再重新跑测试。这三个panic其实暴露了同一个底层认知xv6原版中“PTE_V0”既意味着地址非法也意味着页不存在但在惰性分配下这两个概念被拆开了。后面所有panic都源于代码还在用旧假设逐个改到就好。5. 边界情况、测试验证与背后的设计取舍5.1 地址边界守护页、栈增长与越界保护xv6的用户栈使用方式比较特别栈从高地址向下生长栈顶在p-sz附近但栈底其实是操作系统的trapframe下方那个固定页。当栈向内核空间方向越界时会碰到一个未被映射的守护页。在惰性分配机制下需要区分几种情况普通堆访问stval p-sz合法惰性范围补页栈正常向下增长stval可能在p-sz之上一点点。xv6的默认growproc并不支持栈自动增长但有些同学在Lab里顺便把栈增长也做成惰性分配这就需要在补页判断中加入特殊逻辑真正的越界访问stval远超p-sz或落在守护页上应当杀进程。我个人的建议是先按课程标准要求做只处理stval p-sz这个分支不额外做栈自动增长避免把实验范围扩大。我在尝试同时实现栈惰性增长时花了比核心实验更多的时间去调整边界条件虽然有趣但并非必需。5.2 惰性分配与fork、exit、exec的联动惰性分配会影响所有涉及页表复制的路径除了上面提到的uvmcopy、uvmunmap还要注意exec。进程调用exec加载新程序时会新建页表并释放旧页表。旧进程使用过但未映射的惰性页不会在exec中造成问题因为它直接被整张旧页表替换。但如果旧进程通过fork产生了子进程父进程在惰性分配后fork子进程会复制全部已映射页未映射的页通过缺页机制自行补齐。这要求uvmcopy跳过未映射页且子进程缺页处理与父进程完全相同没有新增的工作量。这里有个值得一提的点如果某个惰性页已经使用并建立了PTEfork会照常复制它并分配新物理页如果没有使用fork不复制子进程之后再用时补页。这相当于把“按需分配”的语义自然带到了子进程中不需要为fork写专门逻辑。5.3 测试性能收益和正确性验证课程提供的lazytests包含几个典型用例大块内存申请后只访问部分区域、越界访问杀进程、fork后子进程访问惰性页。我自己还写了一个小测试申请100MB内存但只碰前面几页然后用time命令对比修改前后的性能。修改前sbrk(100MB)会瞬间分配26000多页系统调用耗时明显修改后系统调用几乎为零开销只有访问到的少数页会触发缺页整体程序运行时间大幅缩短。这背后的计算很简单立即分配要执行26000多次kalloc和页表写入惰性分配只在第一次访问时执行一次。正确性验证方面我建议至少覆盖sbrk分配后只访问前几页程序能正常运行访问超过p-sz的地址进程被杀死而不是补页成功fork后子进程能正常使用惰性分配的地址段连续多次sbrk和malloc混合调用没有内存泄漏使用ealloc等测试工具或自己写小循环反复调用sbrk确认不会panic。我给这几个用例画了个核对表方便自检测试场景预期行为我的实测结果申请大块内存访问部分页面程序正常物理内存占用低通过访问超过p-sz的页面进程被立即杀死通过fork后子进程访问惰性页子进程缺页补页正常访问通过多次sbrk后退出无panic无泄漏通过对未分配页执行写操作触发scause15分配新页并重试指令通过5.4 惰性分配与真实操作系统的对照xv6的惰性分配既然是实验性质和真实系统比还是有区别的。Linux的mmap和堆分配通常也使用惰性策略但内核还要额外处理内存过载时的OOM、页表错误导致的段错误、并发缺页的同步等问题。xv6的单核简化模型里这些都被省略了。不过有一个真实系统里经常讨论的取舍值得在这个实验后想一想惰性分配虽然省了物理内存却可能让错误暴露得更晚。立即分配时sbrk失败说明物理内存不足惰性分配时内存压力可能推迟到实际访问那一刻才出现。对某些系统来说这种“延迟报错”会让程序在奇怪的地方崩溃反而更难排查。这一点实验里不会体现但真正做工程时一定要权衡。写到这里我觉得这个实验最值的部分是它把“虚拟地址空间”和“物理页”之间的鸿沟摆到了眼前。你写一行sbrk操作系统只是画了一个空壳等你的程序真正去踩那页内存时它才手忙脚乱地搬来一块物理页填上。这个机制在现代操作系统里无处不在而xv6用几百行代码就把它讲明白了。最后再分享一个实测中的小技巧调试惰性分配时别光看pp-killed的报错信息多留意scause和stval的值。我第一次调试时傻傻盯着p-sz看了半天后来打印了stval才发现故障地址和我想的完全不是一回事。用printf在缺页处理分支里打印关键寄存器值能帮你少走一大半弯路。