当前位置：首页 > news >正文

1.2 struct page 与 PFN：VMA 背后的物理存储

news 2026/5/22 5:21:46

本篇目标：理解 Linux 如何为每个物理页帧维护元数据（struct page），以及虚拟地址最终如何落实到物理内存。HMM 的关键创新之一，是让设备内存（GPU VRAM）也拥有struct page，从而被内核框架统一管理。

1. 从 VMA 到物理页：缺失的一环

上一篇我们看到，VMA 描述了"这段虚拟地址可读可写"——但它只是一份许可证，并没有说数据实际存储在哪里。虚拟地址终究只是一个"门牌号"，真正存放数据的地方是物理内存（DRAM 芯片）。那么，物理内存是如何被组织和管理的？内核怎么知道哪块物理内存正在被谁使用、处于什么状态？这正是本篇要回答的问题。

那么问题来了：虚拟地址空间的基本管理单位是 VMA，内核管理偌大的物理内存的基本单位是什么呢？

一个直觉的做法是按字节管理——但物理内存动辄数十 GB，逐字节跟踪状态显然不现实。Linux（以及几乎所有现代操作系统）的做法是：将物理内存划分为固定大小的块来管理，每个块称为一个页帧（Page Frame），大小通常为4KB（4096 字节）。这个"4KB 一块"就是内存管理的最小粒度。

对于每个页帧，内核分配一个struct page元数据结构体来记录它的状态（谁在用、什么用途、能否回收等）。所有struct page排列成一个全局数组（memmap），通过页帧的编号（PFN，Page Frame Number）直接索引：

虚拟地址 ──页表（下篇详解）──→ 物理页帧号（PFN）──索引──→ struct page（元数据） │ └──→ 物理内存中的 4KB 数据

2. 物理页帧与 PFN

物理内存被划分为固定大小的页帧（Page Frame），在 x86_64 上默认为 4KB。每个页帧有一个唯一的编号——PFN（Page Frame Number）：

物理地址: 0x0000_0000 0x0000_1000 0x0000_2000 ... PFN: 0 1 2 ... 换算关系: 物理地址 = PFN × PAGE_SIZE (PAGE_SIZE = 4096) PFN = 物理地址 >> PAGE_SHIFT (PAGE_SHIFT = 12，因为 4096 = 2^12) 也就是说，一个物理地址的低 12 位是页内偏移（定位 4KB 页帧内的具体字节）， 高位部分就是 PFN（定位是哪个页帧）。右移 12 位正好丢弃页内偏移，得到 PFN。

内核提供了一组宏来进行转换：

// include/linux/pfn.h#definePFN_PHYS(x)((phys_addr_t)(x)<<PAGE_SHIFT)// PFN → 物理地址#definePHYS_PFN(x)((unsignedlong)((x)>>PAGE_SHIFT))// 物理地址 → PFN// include/asm-generic/memory_model.h#define__pfn_to_page(pfn)(vmemmap+(pfn))// PFN → struct page*#define__page_to_pfn(page)((unsignedlong)(page)-(unsignedlong)vmemmap)// struct page* → PFN

PFN 是内核中引用物理页的通用语言——页表中存储的是 PFN，分配器返回的是 PFN 对应的struct page，HMM 输出的也是 PFN 数组。

3. struct page：物理页帧的元数据

每个物理页帧都有一个对应的struct page，它记录了这个页帧当前的使用状态。由于一个页帧在不同时刻可能扮演不同角色（页缓存页、匿名页、slab 对象、空闲页、设备页…），struct page大量使用 union 来复用空间：

// include/linux/mm_types.h（简化）structpage{memdesc_flags_tflags;// 页面状态标志（PG_locked, PG_dirty 等）union{struct{/* 页缓存 / 匿名页 */structlist_headlru;// LRU 链表节点structaddress_space*mapping;// 所属文件或匿名映射pgoff_tindex;// 文件内偏移（页单位）unsignedlongprivate;// 私有数据};struct{/* ZONE_DEVICE 页 */void*zone_device_data;// 设备驱动私有数据};struct{/* 复合页尾页 */unsignedlongcompound_info;};// ... 其他角色};union{unsignedintpage_type;// 页面类型（typed folios）atomic_t_mapcount;// 被多少个页表映射（-1 表示未映射）};atomic_t_refcount;// 引用计数（0 表示空闲）#ifdefCONFIG_MEMCGunsignedlongmemcg_data;// 内存 cgroup 记账#endif};

3.1 关键字段解读

字段	含义	HMM 相关性
`flags`	页面状态位图（locked/dirty/lru/active 等）	HMM 检查页面是否可迁移
`_refcount`	引用计数，>0 表示正在使用	迁移前需等待引用降为预期值
`_mapcount`	被多少个 PTE 映射（-1=未映射）	反向映射（rmap）用于迁移时解映射
`mapping`	所属的 address_space（文件）或 anon_vma	区分匿名页 vs 文件页
`lru`	LRU 链表位置	回收算法用；迁移时从 LRU 摘除
`zone_device_data`	ZONE_DEVICE 页的驱动私有数据	GPU 驱动存储设备相关信息

3.2 page flags：页面的状态机

flags字段编码了页面当前的状态，常见标志：

// include/linux/page-flags.h（部分）enumpageflags{PG_locked,// 页面被锁定（I/O 进行中）PG_referenced,// 最近被访问过（用于 LRU 老化）PG_dirty,// 页面内容已修改，尚未回写PG_lru,// 在 LRU 链表上PG_active,// 在活跃 LRU 链表上PG_swapcache,// 在 swap cache 中PG_writeback,// 正在回写到磁盘// ...};

内核通过PageXxx()/SetPageXxx()/ClearPageXxx()系列宏操作这些标志：

if(PageDirty(page))// 检查是否脏页SetPageWriteback(page);// 标记正在回写

3.3 引用计数与 mapcount

_refcount和_mapcount是两个最关键的计数器：

_refcount（引用计数）： - 分配时 = 1 - 每多一个使用者 +1（页表映射、内核持有、DMA pinning 等） - 降到 0 时释放回伙伴系统 - get_page() / put_page() 操作 _mapcount（映射计数）： - 初始 = -1（未被任何页表映射） - 每被一个 PTE 映射 +1 - page_mapcount(page) 返回实际映射次数 - 用于反向映射（rmap）——迁移时需要解除所有映射

HMM 与引用计数的关系：在页面迁移（migrate_vma）时，内核需要确认页面的引用计数符合预期（只有页表映射 + 隔离引用），否则迁移失败。这保证了不会把其他子系统正在使用的页面搬走。

4. memmap：struct page 的全局数组

系统中所有物理页帧的struct page形成一个逻辑上的大数组，称为memmap。PFN 就是这个数组的索引：

memmap 数组: ┌──────────┬──────────┬──────────┬──────────┬─── │ page[0] │ page[1] │ page[2] │ page[3] │ ... └──────────┴──────────┴──────────┴──────────┴─── PFN=0 PFN=1 PFN=2 PFN=3 物理内存: ┌──────────┬──────────┬──────────┬──────────┬─── │ 4KB │ 4KB │ 4KB │ 4KB │ ... └──────────┴──────────┴──────────┴──────────┴─── 0x0000 0x1000 0x2000 0x3000

在现代内核中，这个数组通过vmemmap（虚拟内存映射）实现——struct page数组本身被映射到内核虚拟地址空间的一个固定区域，使得pfn_to_page(pfn)只需一次加法即可完成：

// SPARSEMEM_VMEMMAP 模型（现代 x86_64 默认）staticinlinestructpage*pfn_to_page(unsignedlongpfn){returnvmemmap+pfn;// 简单的指针算术}

vmemmap 是什么？它不是一个普通的全局数组，而是一个宏，指向内核虚拟地址空间中一个预留的固定区域（x86_64 上起始于0xffffea0000000000附近）。内核启动时会用页表将这个虚拟区域映射到实际存放struct page的物理内存上。这样vmemmap + pfn就是一次指针加法——编译器会自动乘以sizeof(struct page)，直接得到目标struct page的虚拟地址。对于物理内存中的空洞，对应的 vmemmap 区域不会建立映射，从而不浪费内存。
如果想深入理解这个概念和背后的实现，请阅读文末的关联阅读。

4.1 内存模型的演进

模型	特点	pfn_to_page 复杂度
FLATMEM	单一连续数组	O(1)，直接索引
SPARSEMEM	按 section 分段	O(1)，两级查找
SPARSEMEM_VMEMMAP	虚拟映射	O(1)，单次加法

现代 x86_64 使用SPARSEMEM_VMEMMAP——它既能处理物理内存中的空洞（不浪费未用区域的struct page），又保持了 O(1) 的转换效率。

5. folio：struct page 的现代化封装

从 Linux 5.16 开始，内核逐步引入folio来替代直接操作struct page。folio 解决的问题是：struct page的含义太模糊——同一个指针可能指向一个独立的 4KB 页，也可能指向一个复合页（compound page）的尾页。这导致很多函数不确定自己收到的是"头页"还是"尾页"。

内核开发者选择这个名字，是因为 folio 在印刷术语中指"一整张纸"（而不是纸的某一面或某一角），正好对应它在内核中的语义：一个完整的内存单元（可能是单个 4KB 页，也可能是一个多页的复合页），保证你拿到的是"整张"而不是复合页中的某个尾页碎片。

// include/linux/mm_types.hstructfolio{union{struct{memdesc_flags_tflags;structlist_headlru;structaddress_space*mapping;pgoff_tindex;void*private;atomic_t_mapcount;atomic_t_refcount;// ...};structpagepage;// 与 struct page 内存布局兼容};// 大 folio 的额外信息（_large_mapcount, _nr_pages 等）};

folio 的核心保证：一个struct folio *一定指向复合页的头页（或一个独立的单页）。这消除了歧义。

旧 API（page）	新 API（folio）	说明
`page->mapping`	`folio->mapping`	所属文件/匿名映射
`page_ref_count(page)`	`folio_ref_count(folio)`	引用计数
`PageDirty(page)`	`folio_test_dirty(folio)`	检查脏标志
`lock_page(page)`	`folio_lock(folio)`	锁定页面

对 HMM 的影响：HMM 内部已经在使用 folio API。驱动通过hmm_range_fault()获得的仍然是 PFN 数组，但内核内部对这些 PFN 对应的页面操作（迁移、锁定等）已经使用 folio 接口。

6. ZONE_DEVICE：让设备内存也拥有 struct page（预告）

传统上，只有系统 DRAM 才有struct page。GPU VRAM、持久内存等设备内存对内核是"不可见"的——没有struct page，内核的迁移框架、反向映射等机制都无法作用于它们。

HMM 的关键创新之一是通过ZONE_DEVICE机制，让设备内存也拥有struct page，从而能作为"一等公民"参与内核框架的各种操作。这个机制的完整实现将在第 11 篇详解，这里只需记住一点：

有了struct page，设备内存就能被内核的页面迁移和反向映射框架统一管理——这正是 HMM 实现 CPU ↔ GPU 透明页面迁移的基础。

7. PFN 在 HMM 中的角色

hmm_range_fault()的核心输出就是一个PFN 数组——每个元素对应请求范围中的一个页面：

structhmm_range{unsignedlongstart;// 起始虚拟地址unsignedlongend;// 结束虚拟地址unsignedlong*hmm_pfns;// 输出：PFN 数组（每页一个）// ...};

输出的每个hmm_pfns[i]编码了：

PFN 值：物理页帧号（可以是系统内存或设备内存的 PFN）
标志位：
- HMM_PFN_VALID：该地址已映射
- HMM_PFN_WRITE：可写
- HMM_PFN_ERROR：发生错误

// include/linux/hmm.h// HMM PFN 标志定义enumhmm_pfn_flags{HMM_PFN_VALID=1UL<<63,// 地址有效HMM_PFN_WRITE=1UL<<62,// 可写HMM_PFN_ERROR=1UL<<61,// 错误// ...};

GPU 驱动从hmm_pfns数组中提取 PFN，转换为总线地址，然后编程到 GPU 的页表（或 IOMMU）中——这就完成了"让 GPU 访问同一物理页"的目标。

8. 实验：观察 PFN 映射

Linux 通过/proc/[pid]/pagemap暴露每个虚拟页对应的 PFN：

// pagemap_demo.c// 编译: gcc -o pagemap_demo pagemap_demo.c// 运行: sudo ./pagemap_demo#include<stdio.h>#include<stdlib.h>#include<string.h>#include<fcntl.h>#include<unistd.h>#include<stdint.h>#include<sys/mman.h>intmain(void){// 分配并触碰一个页面void*ptr=mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);memset(ptr,'X',4096);// 触发缺页，分配物理页// 读取 pagemapintfd=open("/proc/self/pagemap",O_RDONLY);unsignedlongvaddr=(unsignedlong)ptr;unsignedlongoffset=(vaddr/4096)*8;// 每个条目 8 字节uint64_tentry;lseek(fd,offset,SEEK_SET);read(fd,&entry,sizeof(entry));close(fd);if(entry&(1ULL<<63)){// bit 63 = presentunsignedlongpfn=entry&((1ULL<<55)-1);printf("虚拟地址: %p\n",ptr);printf("PFN: %lu (0x%lx)\n",pfn,pfn);printf("物理地址: 0x%lx\n",pfn*4096);}else{printf("页面未驻留（可能被换出或未分配）\n");}munmap(ptr,4096);return0;}

运行示例（需要 root 权限）：

虚拟地址: 0x7f3a00100000 PFN: 524388 (0x80064) 物理地址: 0x80064000

这个实验展示了从虚拟地址到 PFN 再到物理地址的完整链路——正是 HMM 内部hmm_range_fault()所做的事情，只不过 HMM 在内核态通过遍历页表完成，而我们这里是通过/proc/self/pagemap接口观察。

9. 与 HMM 的联系

回顾全貌，struct page和 PFN 是 HMM 工作的核心基础：

HMM 操作	依赖的 struct page / PFN 机制
`hmm_range_fault()`	遍历页表提取 PFN，返回给驱动
页面迁移到设备	源页面有 struct page → 迁移框架可工作
设备内存有 struct page	ZONE_DEVICE 提供 → 迁移回 CPU 时框架可工作
反向映射（rmap）	通过 struct page 的 mapping/mapcount 找到所有映射
引用计数	确保迁移期间没有其他使用者

一句话总结：struct page让每个物理页帧成为内核框架的一等公民；ZONE_DEVICE 把这个身份扩展到了设备内存；PFN 是所有操作的通用标识。

10. 本篇关键代码路径

文件	核心内容
`include/linux/mm_types.h`	`struct page`、`struct folio`定义
`include/linux/page-flags.h`	页面标志位定义（PG_locked 等）
`include/linux/pfn.h`	PFN ↔ 物理地址转换宏
`include/asm-generic/memory_model.h`	`pfn_to_page()`/`page_to_pfn()`
`include/linux/memremap.h`	`enum memory_type`、`struct dev_pagemap`
`mm/memremap.c`	ZONE_DEVICE 页面的创建（`memremap_pages()`）
`include/linux/hmm.h`	HMM PFN 标志定义