/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 —— 这就是典型的高阶缺失信号。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

哪些现象说明碎片已影响实际分配

不能只看 /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 和内核分配路径的实际日志。别跳过这一步直接调参或重启。