linux内核中，物理页面一方面会与虚拟页面建立pte映射，另一方面也会与文件或者文件机制有关联，包括：

1. 交换分区（换入/换出）

2. 文件缓存（read()/write()）

3. 文件映射（mmap()）

4. 共享内存（只利用文件机制，没有IO操作）

所以，一个物理页面，在它的生命周期中，可能踏足很多地方，包括：

1. buddy子系统：某个NUMA node的某个zone的某个free_area（通过page->list接入）；

2. 文件address_space：&swapper_space、inode->i_mapping（通过page->list接入）；

3. lru队列：active_list、inactive_dirty_list、页面所属zone的inactive_clean_list（通过page->lru接入）；

4. hash表：page_hash_table（通过page->pprev_hash、page->next_hash接入）。

下面这张图，描述了各种场景下的关键流向：

(理解了关键流向，剩余流向，以及一些反直觉的情况，自然就好理解了，如果画上所有流向，会非常杂乱，反而不好理解)

要看清全面的流向，需要穷举相关执行路径（不断向上查找caller），例如：

1. active_list流入场景

2. inactive_dirty_list流入场景

反直觉的情况有哪些？

很多，举两个例子：

1. 有pte映射的页面，不一定在active_list

    一是刚分配的匿名页面，并不马上加入active_list，二是通过换入操作恢复映射的页面，也不立即转回active_list。

2. active_list中的页面，也可能没有pte映射

    执行换入时，从文件并不只读取目标页面内容，还会多预读一些页面，这些页面暂且放在active_list，并且不需要建立pte映射。

最后总结一下，是哪些力量在推动页面的流动？

1. 缺页异常：由页面的访问操作触发，最终执行do_page_fault()函数，进行分配、映射或换入；

2. 内核线程：

    kswapd：老化用户进程页面，并挑选不活跃页面进行换出；

    bdflush：将文件缓存页面内容，写入文件；

    kreclaimd：从指定zone的inactive_clean_list回收一个页面，到buddy子系统。

3. 文件访问：

    文件读写：缓存页面由内核使用，不映射到用户空间；

    对mmap()返回内存的读写：mmap()在用户程序中使用，将文件的指定区域，映射到一块用户空间；

    对共享内存的读写：利用文件机制，将不同用户进程的用户空间，映射到相同的物理内存，为进程间通信提供了一种方式。

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。