强开thp=always会显著放大回收长尾延迟，根源在于khugepaged合并争锁、thp同步拆分阻塞、compaction与thp互斥形成恶性循环，三者通过关键内核锁深度耦合。
强开透明大页（THP=always）在垃圾回收（尤其是直接回收 Direct Reclaim 或 kswapd 后台回收）过程中，会显著放大物理页扫描的长尾延迟，根源不在“用了大页”，而在于 THP 的合并行为、碎片敏感性与回收路径的深度耦合。下面从三个底层机制层层拆解：
1. khugepaged 合并线程制造隐性内存压力
当 THP 处于 always 模式时，内核后台线程 khugepaged 持续扫描匿名页区域，尝试将 512 个连续 4KB 页合并为一个 2MB THP。这个过程本身不直接触发回收，但会：
- 频繁调用
isolate_lru_page()和try_to_unmap()，反复锁住 anon_vma 和页表项，与回收路径争用同一把锁； - 强制拆分已映射的 VMA（如因 mprotect 分裂），导致大量小 VMA 堆积在同一 anon_vma 上——这正是 KSM 反向映射优化所针对的瓶颈场景；
- 在内存紧张时，合并失败率陡增，
khugepaged会不断重试，形成“无效唤醒风暴”，抬高系统整体调度负载。
2. THP 拆分（splitting）在回收中成为同步阻塞点
当回收器需要释放某 2MB THP 中的个别页（例如该 THP 部分页被修改、部分页需 swap out），内核必须先执行 同步拆分（sync split）：
- 拆分需逐页
lock_page()、清 PTE、迁移内容、更新反向映射，全程不可中断； - 若该 THP 被多个进程共享（常见于 fork 后未写时复制的堆内存），还要遍历全部 rmap，触发前述高延迟的
rmap_walk_ksm()； - 一次拆分可能耗时 10–100ms，在高并发回收场景下，多个线程排队等待同一 THP 拆分完成，形成明显长尾。
3. 内存压缩（compaction）与 THP 共享页框产生恶性循环
当系统出现外部碎片（即有足够空闲页但无连续 2MB 块）时，THP 分配失败会触发 compact_zone()。而 compaction 本身依赖迁移页来整理空间，此时：
- THP 页面无法被迁移（除非先拆分），导致 compaction 扫描器跳过整块 2MB 区域，有效扫描范围大幅缩水；
- 为凑出连续空间，compaction 被迫更激进地迁移普通页，进一步加剧
try_to_unmap()和rmap_walk()负载； - 若恰有数据库进程正在做大范围 buffer pool 扫描（如 InnoDB LRU 刷新），其访问模式打散物理页局部性，反过来又抑制 THP 合并，使系统在“拼命合并→频繁拆分→持续压缩”之间震荡。
这些机制不是孤立运行，而是通过 anon_vma 锁、页表锁、lru_lock、zone->lock 等关键锁形成连锁阻塞链。实测显示：在 THP=always + 高并发写入的 MySQL 场景下，单次 direct reclaim 的 p99 延迟可突破 800ms，其中 >60% 时间消耗在 THP 相关的拆分与 rmap 遍历上。
