1. 从物理内存说起：ucore Lab3 到底在解决什么问题
做过操作系统课程实验的人大多有个共同感受：Lab1 和 Lab2 还能靠“照着文档敲代码”混过去，到了 Lab3 突然就撞上一堵墙。这堵墙的名字叫物理内存管理。你打开实验指导书，看到一堆陌生名词——页帧、页表、物理地址、虚拟地址、连续内存分配器、首次适配、最佳适配——每个字都认识，连在一起就不知道在说什么。更让人抓狂的是，代码里突然冒出来一个pmm_init()，里面调了一长串函数，每个函数都跟硬件寄存器打交道，稍有不慎就是三重错误（Triple Fault），QEMU 直接重启，连个报错信息都不给你留。
我当初做这个实验的时候，光理解“为什么需要物理内存管理”就花了两三天。后来才慢慢想明白，Lab3 的核心任务其实就一句话：让操作系统能够掌控整台机器的物理内存，知道哪些内存被占用了、哪些是空闲的、怎么分配、怎么回收。听起来简单，但这是所有后续实验的地基。没有物理内存管理，Lab4 的内核线程没法创建，Lab5 的用户进程没法加载，Lab6 的调度器连栈都分配不出来。所以 Lab3 在整个 ucore 实验体系里扮演的是“承上启下”的角色——上承 Lab2 的物理内存布局探测，下启 Lab4 之后的所有内存相关操作。
这篇文章我会从设计思路、核心数据结构、关键算法、实操步骤、常见坑点五个维度，把 ucore Lab3 物理内存管理彻底拆开讲清楚。不管你是正在做这个实验的学生，还是想复习操作系统内存管理原理的开发者，都能从中拿到可以直接用的东西。我不会只告诉你“怎么做”，更会告诉你“为什么这么做”——因为只有理解了设计者的意图，你才能在遇到变体题目时自己推导出答案。
2. 物理内存管理的整体设计思路拆解
2.1 为什么不能直接用物理地址
在写 Lab3 之前，你可能会有个疑问：Lab2 里我们已经能访问物理内存了，为什么还要搞一套“管理”机制？直接拿物理地址用不就行了吗？
这个问题的答案藏在多道程序设计的需求里。假设系统里同时运行着三个程序，每个程序都假设自己从地址 0 开始使用内存。如果直接让它们访问物理地址，三个程序就会互相踩踏——A 程序写地址 0x1000 的数据，可能正好覆盖了 B 程序放在那里的代码。所以操作系统必须提供一层抽象，让每个程序都以为自己独占内存。这层抽象就是虚拟地址到物理地址的映射，而映射的基础就是物理内存管理。
ucore 的设计思路很清晰：先把物理内存划分成固定大小的页帧（Page Frame），通常一页 4KB，然后用一个全局的页帧管理器来记录每个页帧的状态——是空闲的、已分配的、还是被内核保留的。当程序需要内存时，管理器分配一个页帧；当程序释放内存时，管理器回收这个页帧。整个过程就像图书馆管理书架：每个书架格子是一个页帧，管理员手里有一张表，记录哪些格子空了、哪些放了书、哪些是预留的。
2.2 两种管理策略的取舍
ucore Lab3 实际上要求实现两种物理内存管理方式：连续内存分配和非连续内存分配。这两种方式对应不同的应用场景，理解它们的区别是做好实验的关键。
连续内存分配器（First Fit / Best Fit）用于分配物理地址连续的内存块。什么时候需要物理地址连续？最典型的就是 DMA 操作——外设直接访问内存时，它不认识虚拟地址，只能按物理地址读写。所以内核中需要为 DMA 预留连续物理内存。ucore 里用default_pmm_manager来实现这个分配器，默认采用首次适配算法。
非连续内存分配则是通过页表机制，把物理上不连续的页帧映射成虚拟上连续的地址空间。这是现代操作系统的主流做法，因为它能有效利用碎片化的物理内存。ucore 里通过pmm_manager的alloc_pages和free_pages接口来管理页帧，配合页表实现虚拟内存。
注意：很多同学做实验时只关注连续分配器的实现，忽略了页帧管理器的初始化流程。实际上 Lab3 的评分点里，页帧管理器的正确初始化是基础中的基础，如果
page_init()没写好，后面所有分配都是空中楼阁。
2.3 物理内存布局的探测
在管理内存之前，必须先知道内存的布局。ucore 通过 BIOS 提供的E820 内存映射表来获取物理内存信息。这个表在启动时由 BIOS 填充，记录了哪些地址范围是可用的 RAM、哪些是保留的、哪些是 ACPI 数据区。Lab2 里已经完成了 E820 表的解析，Lab3 要做的是基于这些信息初始化页帧数组。
这里有个容易忽略的细节：内核本身占用的内存必须被标记为已使用。ucore 的内核通常加载在物理地址 0x100000（1MB）处，内核代码段、数据段、BSS 段以及启动栈都占据了一部分物理内存。在初始化页帧管理器时，必须把这些区域对应的页帧标记为“已保留”，否则后续分配可能会覆盖内核代码，导致系统崩溃。
3. 核心数据结构与关键算法解析
3.1 页帧描述符 page 结构体
ucore 用struct Page来描述一个物理页帧。这个结构体是整个物理内存管理的核心，它的字段设计直接决定了管理效率。我们来看关键字段：
struct Page { int ref; // 引用计数 uint32_t flags; // 状态标志 unsigned int property; // 连续空闲页数量（用于连续分配） list_entry_t page_link; // 空闲链表节点 list_entry_t pra_page_link; // 页替换算法用 uintptr_t pra_vaddr; // 页替换算法用 };ref字段记录这个页帧被引用了多少次。当ref为 0 时，表示页帧空闲；大于 0 时表示已被分配。这个设计支持共享内存场景——多个虚拟地址可以映射到同一个物理页帧，只要引用计数正确管理，释放时就不会出现悬空指针。
flags字段用位标志记录页帧状态，比如PG_reserved表示保留页（内核占用），PG_property表示该页是连续空闲块的起始页。位操作在内存管理中非常常见，因为一个 32 位整数可以同时表示 32 种状态，节省空间。
property字段只在连续内存分配器中使用，记录从当前页开始有多少个连续空闲页。这个字段是首次适配算法高效运行的关键——有了它，分配器不需要每次都遍历链表来统计连续页数。
3.2 空闲页链表的管理
ucore 用双向链表free_list来管理所有空闲页帧。每个空闲页帧的page_link字段作为链表节点挂入free_list。当需要分配页帧时，从链表头取下一个节点；当释放页帧时，把节点插回链表。
这里有个设计上的精妙之处：链表节点直接嵌入在Page结构体内部，而不是单独分配节点。这样做的好处是避免了额外的内存分配，同时通过le2page宏可以从链表节点反推出Page结构体的地址：
#define le2page(le, member) \ to_struct((le), struct Page, member)这个宏利用了 C 语言的结构体成员偏移量计算，是内核编程中非常经典的技巧。理解这个宏对于读懂 ucore 的链表操作至关重要。
3.3 首次适配算法的实现细节
首次适配（First Fit）算法的思路很朴素：从空闲链表头开始遍历，找到第一个大小满足要求的连续空闲块，从中切分所需大小的内存返回。ucore 的default_alloc_pages函数实现了这个算法。
算法的核心步骤：
- 遍历
free_list，检查每个空闲块的property字段是否大于等于请求的页数 n。 - 找到第一个满足条件的块后，如果块大小正好等于 n，直接将该块从链表移除。
- 如果块大小大于 n，从块中切分 n 页，剩余部分保留在链表中，并更新剩余块的
property字段。 - 对于被分配的 n 页，设置
ref为 1，清除PG_property标志。
这里有个容易出错的地方：切分后剩余块的起始页需要重新设置PG_property标志。因为原来的起始页被分配出去了，新的起始页变成了原来起始页加上 n 的位置。如果忘记设置这个标志，后续分配时就会把这个块当成非空闲块跳过，导致内存泄漏。
3.4 释放页帧时的合并逻辑
释放页帧比分配更复杂，因为需要合并相邻的空闲块，否则内存会碎片化。ucore 的default_free_pages函数需要处理四种情况：
- 前一个页帧空闲，后一个页帧也空闲：三块合并成一块。
- 只有前一个页帧空闲：当前块与前一块合并。
- 只有后一个页帧空闲：当前块与后一块合并。
- 前后都不空闲：当前块独立成为新的空闲块。
合并操作需要修改链表的链接关系，同时更新property字段。这里的关键是正确判断相邻关系：两个页帧相邻的条件是它们的物理地址连续，即page2pa(page) + PGSIZE == page2pa(next_page)。ucore 提供了page2pa宏来完成这个转换。
实操心得：在实现释放逻辑时，建议先用纸笔画出示意图，把四种情况的链表变化都画出来，再写代码。我当初直接上手写，结果在“前后都空闲”的情况下把链表指针改乱了，导致 QEMU 直接死机，调试了整整一个下午。
4. 实操过程与核心环节实现
4.1 实验环境准备与代码结构
ucore Lab3 的代码主要分布在以下文件：
| 文件路径 | 作用 |
|---|---|
kern/mm/pmm.c | 物理内存管理器主框架 |
kern/mm/default_pmm.c | 默认连续内存分配器实现 |
kern/mm/memlayout.h | 内存布局相关宏定义 |
kern/mm/pmm.h | 物理内存管理接口声明 |
kern/init/init.c | 内核初始化入口 |
编译和运行命令：
make lab3 make qemu如果一切正常，你会看到内核启动信息，最后停在pmm_init()完成后的某个位置。如果出现三重错误，QEMU 会不断重启，这时候需要检查pmm_init()中的每一步是否正确。
4.2 页帧初始化的完整流程
pmm_init()是 Lab3 的入口函数，它的执行流程如下：
- 探测物理内存布局：调用
detect_memory()获取 E820 表信息，确定物理内存的起始地址和大小。 - 计算页帧数量：
npage = maxpa / PGSIZE，其中maxpa是最大物理地址。 - 分配页帧数组：
pages = (struct Page *)ROUNDUP((void *)end, PGSIZE)，其中end是内核结束地址。页帧数组本身占用一部分物理内存，需要从可用内存中扣除。 - 初始化页帧数组：遍历所有页帧，设置
ref为 0，flags为 0，初始化链表节点。 - 标记保留页：把内核代码段、数据段、页帧数组本身占用的页帧标记为
PG_reserved。 - 初始化空闲链表：把非保留页帧按物理地址顺序插入
free_list，并设置连续块的property字段。 - 初始化连续内存分配器：调用
pmm_manager->init()完成分配器的初始化。
这个流程中，第 3 步的ROUNDUP操作很关键。页帧数组必须按页对齐，否则后续通过数组下标计算页帧地址时会出现偏差。第 5 步的保留页标记也不能遗漏，否则分配器可能把内核代码页分配出去，导致系统崩溃。
4.3 首次适配分配器的代码实现
default_alloc_pages函数的完整实现如下：
static struct Page * default_alloc_pages(size_t n) { assert(n > 0); if (n > nr_free) { return NULL; } struct Page *page = NULL; list_entry_t *le = &free_list; while ((le = list_next(le)) != &free_list) { struct Page *p = le2page(le, page_link); if (p->property >= n) { page = p; break; } } if (page != NULL) { if (page->property > n) { struct Page *p = page + n; p->property = page->property - n; SetPageProperty(p); list_add_after(&(page->page_link), &(p->page_link)); } list_del(&(page->page_link)); nr_free -= n; ClearPageProperty(page); page->property = n; page->ref = 1; } return page; }这段代码有几个细节值得注意：
list_add_after把剩余块插入到当前块之后，保持链表的物理地址顺序。这个顺序对于后续的合并操作很重要。ClearPageProperty(page)清除起始页的PG_property标志，因为这块内存已经被分配了，不再是空闲块的起始。page->property = n记录分配块的大小，释放时需要用这个信息来合并。
4.4 释放与合并的代码实现
default_free_pages函数的实现：
static void default_free_pages(struct Page *base, size_t n) { assert(n > 0); struct Page *p = base; for (; p != base + n; p ++) { assert(!PageReserved(p) && !PageProperty(p)); p->flags = 0; set_page_ref(p, 0); } base->property = n; SetPageProperty(base); nr_free += n; list_entry_t *le = list_next(&free_list); while (le != &free_list) { p = le2page(le, page_link); if (base + base->property == p) { base->property += p->property; ClearPageProperty(p); list_del(&(p->page_link)); } else if (p + p->property == base) { p->property += base->property; ClearPageProperty(base); base = p; } le = list_next(le); } list_add_before(le, &(base->page_link)); }这段代码的合并逻辑是：遍历空闲链表，检查当前块是否与base块相邻。如果base的结束地址正好是某个空闲块的起始地址，就向后合并；如果某个空闲块的结束地址正好是base的起始地址，就向前合并。合并后更新property字段，并从链表中删除被合并的块。
注意：合并操作必须在插入
base到链表之前完成，否则遍历时会把base自己也遍历到，导致逻辑混乱。我当初就是把list_add_before放在了循环前面，结果合并时把base自己合并了，property变成原来的两倍，分配时直接越界。
5. 常见问题与排查技巧实录
5.1 三重错误（Triple Fault）的排查思路
三重错误是 Lab3 最常见的崩溃形式，表现为 QEMU 不断重启，没有任何输出。排查三重错误可以按照以下顺序：
- 检查页帧数组是否越界：
npage的计算是否正确？pages数组是否覆盖了所有物理页帧？如果npage算小了，访问超出数组范围的页帧就会踩到其他数据。 - 检查保留页标记：内核代码段、数据段、页帧数组本身是否都被标记为
PG_reserved？如果遗漏了，分配器可能把内核代码页分配出去。 - 检查链表操作：
list_add、list_del的调用是否正确？链表指针被改乱后，遍历时会访问非法地址。 - 检查
property字段：连续块的property是否正确设置？如果property为 0，分配器会认为这个块大小为 0，跳过它。
5.2 内存泄漏与碎片化问题
如果实验运行一段时间后出现分配失败，但nr_free显示还有空闲页，那很可能是碎片化导致的。首次适配算法本身不解决碎片化问题，只能通过合并来缓解。如果释放时没有正确合并相邻块，空闲页就会变成一个个小碎片，无法满足大块分配请求。
排查碎片化问题的方法：在default_alloc_pages和default_free_pages中加入调试输出，打印每次分配和释放的页帧地址、大小、nr_free变化。通过日志可以清楚地看到空闲链表的变化过程，找出没有合并的块。
5.3 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| QEMU 不断重启 | 三重错误，通常是页帧数组越界或链表损坏 | 检查npage计算和链表操作 |
分配返回 NULL 但nr_free足够 | 碎片化，没有可用的连续块 | 检查释放时的合并逻辑 |
| 分配到的页帧地址异常 | page2pa转换错误或页帧数组基址不对 | 检查pages数组的起始地址 |
释放后nr_free不增加 | nr_free更新遗漏或合并逻辑错误 | 检查default_free_pages的nr_free += n |
| 内核启动后卡死 | 保留页标记遗漏，内核代码被覆盖 | 检查page_init中的保留页标记 |
5.4 调试技巧与工具使用
ucore 提供了print_pgdir()函数来打印页目录信息，但在 Lab3 阶段页表还没完全建立，这个函数用处不大。更实用的调试方法是在关键位置插入cprintf输出：
cprintf("alloc_pages: n=%d, page=%p, nr_free=%d\n", n, page, nr_free);另外，GDB 调试也是排查内存问题的利器。在Makefile中加入-s -S参数启动 QEMU，然后用 GDB 连接：
make qemu-gdb gdb (gdb) target remote :1234 (gdb) break default_alloc_pages (gdb) continue在 GDB 中可以查看free_list的链表结构、每个Page结构体的字段值，对于定位链表损坏问题非常有效。
实操心得：我建议在做 Lab3 时养成“先画图再写代码”的习惯。把空闲链表的初始状态、分配后的状态、释放后的状态都画出来，对照图来写代码，比直接对着屏幕敲要快得多。尤其是合并逻辑，画图能帮你理清四种情况的边界条件。
6. 从 Lab3 延伸出去：物理内存管理的实际应用
6.1 伙伴系统与 SLAB 分配器
ucore 的首次适配算法适合教学，但实际操作系统用的更多是伙伴系统（Buddy System）和SLAB 分配器。伙伴系统把内存按 2 的幂次划分，分配和释放时通过“伙伴”关系快速合并，效率比首次适配高很多。SLAB 分配器则针对内核中小对象频繁分配释放的场景，通过缓存池来减少碎片化。
理解 Lab3 的首次适配算法后，再去看伙伴系统的实现会容易很多。两者的核心思想是一致的：维护空闲块链表，分配时切分，释放时合并。区别在于伙伴系统用位图或树结构来管理，合并时通过地址计算直接找到伙伴块，不需要遍历链表。
6.2 页帧引用计数与共享内存
Page结构体中的ref字段在 Lab3 中只是简单设置为 1，但在实际系统中，引用计数是共享内存和Copy-on-Write的基础。当多个进程共享同一块物理内存时，ref会大于 1；当某个进程释放时，ref减 1，只有减到 0 时才真正回收页帧。Lab4 之后会用到这个机制，所以 Lab3 中正确管理ref是为后续实验打基础。
6.3 物理内存管理对性能的影响
物理内存管理的效率直接影响系统性能。首次适配算法在空闲块较多时，遍历链表的时间复杂度是 O(n)，n 是空闲块数量。伙伴系统通过位图或树结构把查找时间降到 O(log n)。SLAB 分配器则通过缓存常用对象，把分配时间降到 O(1)。这些优化手段在实际系统中非常重要，因为内存分配是内核中最频繁的操作之一。
6.4 实验后的扩展练习
做完 Lab3 的基础部分后，可以尝试以下扩展练习来加深理解：
- 实现最佳适配（Best Fit）算法，比较它与首次适配的碎片化程度。
- 实现最差适配（Worst Fit）算法，观察大块内存的分配效率。
- 在
default_free_pages中加入统计信息，记录合并次数和碎片化率。 - 尝试用位图替代链表来管理空闲页帧，比较两种实现的性能差异。
这些练习不需要修改实验框架，只需要替换default_pmm.c中的实现即可。通过对比不同算法的表现，你能更深刻地理解物理内存管理的设计权衡。
我个人在实际操作中的体会是，Lab3 的难点不在于代码量，而在于对内存布局和链表操作的理解。把pmm_init的每一步都搞清楚，把free_list的变化过程画出来，代码自然就写对了。踩过几次三重错误的坑之后，你会对“操作系统如何管理内存”这件事有完全不同的认识——不再是课本上抽象的概念，而是实实在在的代码和数据结构。后续做 Lab4 创建内核线程时，你会发现自己对alloc_pages和free_pages的调用已经得心应手，这就是 Lab3 打下的基础在发挥作用。
