echo 1 > /proc/sys/vm/compact_memory 确实可手动触发一次同步内存规整，但仅扫描所有zone、不保证成功、不阻塞调用、无返回值，适用于调试而非生产环境稳定优化。
触发内存规整（memory compaction）的正确方式
Linux内核不会在空闲时主动做内存规整，只有当分配大页（如 HugeTLB 或 THP）失败、且当前存在足够空闲页但分散在不同迁移类型（migratetype）区域时，才会尝试同步规整。想“强制触发”不是靠某个命令一键执行，而是通过制造符合规整触发条件的分配请求来间接驱动。
echo 1 > /proc/sys/vm/compact_memory 真的有效吗？
这个接口确实存在，但它只触发一次同步规整扫描，并不保证成功或完成全部碎片整理。它的实际效果受限于：
- 当前内存域（zone）是否处于可规整状态（比如
zone->compact_blockskip_flush被置位会跳过） - 规整目标迁移类型（如
MIGRATE_MOVABLE）是否有足够空闲页供迁移 - 系统是否启用了
CONFIG_COMPACTION=y（主流发行版默认开启） - 它不阻塞调用者，也不返回结果，无法判断是否真有页面被合并
所以它更适合调试或临时干预，不能作为稳定规避分配延迟的手段。
真正影响大页分配延迟的是 vm.extfrag_threshold
这个参数控制内核是否认为某 zone 的外部碎片“严重到必须规整”。默认值是 500（范围 0–1000），数值越小，越激进触发规整。如果你观察到 cat /proc/buddyinfo 显示大量 2^0 ~ 2^3 页，但几乎没有 2^9+ 页，而 cat /sys/kernel/debug/extfrag/extfrag_level 输出持续高于阈值，说明规整没跟上——这时调低该值比反复写 compact_memory 更有效：
echo 250 > /proc/sys/vm/extfrag_threshold
注意：该值对每个 zone 单独生效，且仅影响后续分配路径中的规整决策，不回溯已存在的碎片。
为什么 alloc_pages(GFP_KERNEL, order=9) 还是卡住？
即使规整已运行，以下情况仍会导致分配失败或延迟：
- 目标 zone 中没有连续
2^9个空闲页（哪怕总空闲页数远超 512） - 进程运行在 cgroup v1 下，且 memory.limit_in_bytes 限制过严，导致规整被限制在极小范围内
- 分配上下文不可睡眠（例如中断上下文、持有 spinlock），此时内核根本不会尝试规整，直接返回
NULL -
vm.overcommit_memory=2且CommitLimit不足，连尝试分配的机会都没有
验证方法：在卡顿时刻抓取 dmesg -T | tail -20，如果看到 page allocation failure: order:9 后紧接 compact_success=0，说明规整尝试了但失败；若连 compact 日志都没有，则是分配路径压根没走到规整阶段。
