page cache 是 linux 文件读写的默认路径，非可选优化；它占用内存可被回收，导致 free -h 中可用内存减少，但系统不卡顿，本质是内核积极缓存文件数据。
Page Cache 不是“可选优化”，而是 Linux 文件读写的默认路径——几乎所有 read()、write()（非 O_DIRECT）都会经过它。理解它，不是为了调优炫技，而是避免误判内存使用、排查 I/O 延迟、读懂 free -h 里“可用内存”为何越来越小。
为什么 free 显示的可用内存越来越少？
这不是内存泄漏，是内核在积极缓存文件数据：Page Cache 占用的内存只要没被进程锁定（如 mlock()），就随时可被回收。当新内存申请到来，kswapd 会优先回收干净页（clean page），脏页（PG_dirty）则需先回写再释放。
- 现象：
free -h中available值低，但系统不卡顿 → 很可能只是Page Cache占得多 - 验证：看
/proc/meminfo的Cached:和Dirty:行，或用cat /sys/fs/cgroup/memory/memory.stat | grep -E "(cache|dirty)"（cgroup v1） - 误区：手动执行
echo 3 > /proc/sys/vm/drop_caches清缓存 → 短期释放内存，但立刻被新读写填满；且会引发后续大量磁盘读，反而拖慢响应
read() 和 write() 怎么走 Page Cache？
所有带缓冲的文件 I/O 都默认走 Page Cache，核心逻辑由 VFS 层统一调度，不依赖具体文件系统。
-
read()路径：
→ 查address_space的xarray（旧内核为 radix tree）找struct page（按inode + offset/page_index定位）
→ 命中且PG_uptodate==1→ 直接copy_to_user()
→ 未命中 → 分配页 → 发起磁盘 BIO → 完成后置PG_uptodate=1→ 加入 LRU -
write()路径：
→ 找/分配对应页 →copy_from_user()写入 → 标记PG_dirty=1→ 返回（不等刷盘）
→ 脏页由后台writeback线程异步刷出，触发条件包括：vm.dirty_ratio（如 20%）、vm.dirty_expire_centisecs（如 3000 = 30 秒） - 注意：
pwrite()、memcpy到mmap(MAP_SHARED)区域，同样生成脏页，行为一致
哪些操作会绕过 Page Cache？
绕过 ≠ 更快，而是换一种一致性模型。绕过意味着放弃缓存收益，直面磁盘延迟。
-
O_DIRECT：open 时指定 →read()/write()绕过Page Cache，直接与块层交互；要求用户 buffer 地址对齐（memalign(4096, size)）、长度对齐（4KB 倍数）；常见于数据库 WAL 日志写入 -
O_SYNC或fsync()：不绕过缓存，但强制等待脏页刷盘完成 → 增加延迟，保障持久性 -
Direct I/O + O_SYNC组合：既绕缓存又等落盘 → 最强持久性，最低吞吐，慎用 - 错误认知：“
dd iflag=direct就一定不进 Page Cache” → 实际上dd的输入文件若未开O_DIRECT，仍会走 cache；输出设备才决定是否 bypass
如何观察和简单干预 Page Cache 行为？
别迷信“清缓存”，重点看它是否健康工作：命中率高不高？脏页堆积严不严重？
- 查命中率：
cat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault"→ 用pgmajfault（缺页中断）反推读缓存效率（越少越好） - 控脏页节奏：
sysctl -w vm.dirty_ratio=15<br>sysctl -w vm.dirty_background_ratio=5
→ 降低触发后台回写的阈值，避免突发写导致阻塞 - 查某进程用了多少 Page Cache：
grep -i "mm\/.*cache" /proc/<pid>/smaps</pid>（含Shared_Clean/Shared_Dirty） - 关键提醒：
Page Cache是 per-file 的，多个进程打开同一文件，共享同一组缓存页（mapping相同），但各自有独立file->f_pos偏移 —— 这正是 mmap 共享内存的基础
Page Cache 的“共享性”和“延迟可见性”：你改了一个 mmap 区域，另一个进程立刻能读到新值，不是因为 magic，而是它们访问的是同一个 struct page；而这个页何时落盘，完全由 writeback 策略决定，跟你的 msync() 调用与否、甚至进程是否退出都无必然关系。 
