页表项(PTE)Present Bit为0但页仍在RAM中的原因及实例求解

你看到的这段教材描述是虚拟内存机制的入门级简化表述：

最后一位（标记为P，即Present Bit）用于标识对应页是否存在于RAM中。如果该位为0，那么任何对该页的访问都会触发page fault（页错误）。

这段描述仅覆盖了最基础的单进程、无页缓存的理想场景，教授的说法才符合现代商用操作系统的实际设计逻辑。

核心逻辑说明 #

• Present位本质是给硬件MMU使用的标记：MMU做地址转换时只有检测到该位为1，才会直接使用PTE中存储的物理地址完成转换；只要该位为0，无论对应页实际存储在什么位置，都会触发页错误，交由操作系统的页错误处理程序处理。
• 操作系统自身会独立维护所有物理页的状态元数据（比如Linux内核中的struct page结构），物理页是否存在于RAM中，和对应PTE的Present位值没有绝对的绑定关系，内核完全可以根据需求手动将存在于RAM中的页对应的PTE的Present位设为0。

多进程共享场景下的具体实例 #

实例1：共享页换出的中间状态 #

当系统内存存在压力时，内核会选择不常访问的页换出到交换分区/磁盘，以释放内存空间。如果被选中的是多进程共享的页（比如通过shmget创建的共享内存页、多个进程映射的同一个动态库的可写数据段等），会出现以下流程：

1. 内核先遍历所有映射了该共享页的进程的页表，将所有对应PTE的Present位置为0，同时在PTE的保留位中记录该页的交换分区位置索引
2. 内核将该页的内容写入交换分区
3. 完成写入后，内核并不会立刻回收该物理页，而是将它放入交换缓存队列中，等待后续真正需要内存时再释放

在第1步完成到第3步页被真正回收的整个时间段内，这个物理页始终存在于RAM中，但所有映射它的进程对应PTE的Present位都是0。此时如果有进程访问该虚拟地址触发页错误，内核可以直接将对应PTE的Present位改回1，不需要从磁盘重新读取数据，性能开销极低。

实例2：NUMA架构下的共享页迁移 #

在多NUMA节点的服务器上，操作系统会自动将进程访问的页迁移到进程所在的NUMA节点，以降低内存访问延迟。如果要迁移的是多进程共享的页，会出现以下流程：

1. 内核先将所有映射该共享页的进程对应PTE的Present位置为0，防止迁移过程中进程修改页内容导致数据不一致
2. 内核将该物理页的内容复制到目标NUMA节点的内存页中
3. 内核更新所有进程的对应PTE，填入新的物理地址并将Present位置为1，再释放原来的物理页

在第1步完成到第3步PTE更新完成的时间段内，原物理页和新复制的物理页都存在于RAM中，但所有进程对应PTE的Present位都是0。

内容的提问来源于stack exchange，提问作者Dan