/proc/buddyinfo 是唯一能直接反映伙伴系统碎片状态的内核接口，通过各order空闲页块数量分布判断外部碎片程度，高阶为0而低阶堆积表明严重碎片；需结合page allocation failure、pgalloc统计及THP合并失败等运行时现象交叉验证，free/top等工具因不体现物理连续性而无法反映碎片问题。
/proc/buddyinfo 是唯一能直接反映伙伴系统当前碎片状态的内核接口。它不告诉你“有没有碎片”，而是用数字告诉你“碎片成什么样了”——高阶空闲块越少、低阶堆积越多，外部碎片就越严重。
怎么看 /proc/buddyinfo 里每列数字的实际含义
每一行对应一个 NUMA 节点和内存区域（如 Node 0, zone DMA），每列对应一个 order 值（0 到 10）：
-
order=0：表示 1 个页（4KB）的空闲块数量 -
order=1：表示 2 个连续页（8KB）的空闲块数量 -
order=9：表示 512 个页（2MB）的空闲块数量 -
order=10：表示 1024 个页（4MB）的空闲块数量
关键不是看总数，而是看分布趋势。例如这一行：Node 0, zone Normal 24 18 12 8 4 2 1 0 0 0 0，说明 order=7（512KB）还有 1 个块，order=8（1MB）起全为 0 —— 这就是典型的高阶缺失信号。
哪些现象说明碎片已影响实际分配
不能只看 /proc/buddyinfo 数字“好看不好看”，要结合运行时行为交叉验证：
- dmesg 中出现
page allocation failure: order:X，X ≥ 5（即需 ≥128KB 连续页）且反复发生 - 程序申请大内存（如驱动用
__get_free_pages(GFP_KERNEL, 9)）失败，但MemAvailable仍很高 -
/proc/vmstat中pgalloc_normal高而pgalloc_high极低，或compact_success/compact_fail比值持续恶化 - 启用 THP 后
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag长期卡在0，说明找不到 2MB 连续页供合并
为什么不能只依赖 free 或 top 判断碎片
这两个工具只显示虚拟内存视图，完全不体现物理页连续性：
-
free -h的available字段再高，也解决不了kmalloc(2*1024*1024, GFP_KERNEL)因找不到 2MB 物理连续页而 fallback 到vmalloc的问题 -
top显示的RES是物理页驻留量，但这些页在物理内存中可能是完全离散的，对 DMA 或大页无意义 -
/proc/meminfo里的DirectMap4k/DirectMap2M可辅助判断大页映射能力，但它反映的是当前已建立的映射，不是空闲能力
真正决定“能不能分到大块物理内存”的，只有 /proc/buddyinfo 和内核分配路径的实际日志。别跳过这一步直接调参或重启。
