Linux 内存紧缩与 Direct Reclaim：端侧 AI 推理高负载下的延迟毛刺排查

在工业边缘计算网关与移动端 SoC 上部署大语言模型（LLM）或视觉大模型（VLM）时，工程师最常遇到的性能痛点就是：平均推理延迟（P50）表现优异，但 P99/P999 延迟却偶尔出现高达数百毫秒甚至秒级的严重毛刺。

很多应用层开发者第一反应是去查 GPU/NPU 驱动或 PyTorch/ONNX 算子实现，甚至怀疑是大模型的 KV Cache 调度问题。然而在 Linux 嵌入式与端侧场景下，这类延迟毛刺的真正元凶往往隐藏在操作系统的物理内存分配路径中——Direct Reclaim（直接内存回收）与 Memory Compaction（内存紧缩/碎片整理）。

本文从 Linux 内核内存子系统（mm）底层源码出发，剖析端侧 AI 高并发场景下物理页分配陷入阻塞的根本机理，并给出端到端的观测手段与内核调优方案。

---

一、 内存分配的三道防线与 Direct Reclaim 阻塞路径

Linux 的伙伴系统（Buddy Allocator）将物理内存按 Zone（如 ZONE_NORMAL, ZONE_DMA32）进行划分，每个 Zone 维护了三个关键水位线（Watermarks）：

$$\text{WMARK_MIN} < \text{WMARK_LOW} < \text{WMARK_HIGH}$$

flowchart TD
    Alloc[用户态进程调用 malloc / mmap 触发缺页异常] --> Buddy[内核伙伴系统尝试分配 Order-N 物理页]
    Buddy --> CheckWatermark{当前剩余可用内存与 Watermark 比较}
    
    CheckWatermark -->|Free > WMARK_LOW| FastPath[快速路径: 立即分配物理页返回]
    CheckWatermark -->|Free < WMARK_LOW 且 > WMARK_MIN| AsyncKswapd[唤醒 kswapd 内核线程后台异步回收]
    AsyncKswapd --> FastPath
    
    CheckWatermark -->|Free < WMARK_MIN 或连续大页不足| SlowPath[慢速路径: 陷入 Direct Reclaim / Compaction]
    SlowPath --> BlockAlloc[当前应用线程被完全挂起, 亲自扫描 LRU 链表并回收脏页/释放 Cache]
    BlockAlloc --> TailLatency[产生 P99 毫秒级延迟毛刺!]

1. 快速路径与慢速路径的临界点

在端侧大模型推理启动或动态扩充 KV Cache 时，应用会一次性向内核申请大量连续物理内存（如分配大张量或大页 Huge Pages）。

• 当空闲内存高于 WMARK_LOW 时，分配直接走 Fast Path，耗时在纳秒级。
• 当空闲内存跌落至 WMARK_LOW 与 WMARK_MIN 之间时，内核会唤醒后台守护进程 kswapd 异步回收内存，此时前台推理线程不会被挂起。
• 但当模型突发申请大内存、或者 kswapd 的回收速度赶不上推理引擎的消耗速度时，空闲内存跌破 WMARK_MIN，内核被迫进入 Slow Path（__alloc_pages_slowpath）。

2. Direct Reclaim 与 Compaction 为何会引起巨大延迟？

在慢速路径中，内核会执行 try_to_free_pages 和 compact_zone。这意味着：发起内存申请的那个前台推理线程，必须停止手中的计算，亲自去遍历系统的 LRU 链表、同步回写脏页到磁盘/Flash（Sync I/O）、并在物理内存页之间做内存拷贝以拼凑出大块连续物理页（Compaction）。

在 Flash 写入带宽受限的端侧设备上，一次同步脏页回写与内存迁移即可导致前台线程直接卡顿 200ms ~ 1500ms。

---

二、 内核观测与故障现场定位

要抓取 Direct Reclaim 的真实耗时，不能仅看 top 或 free，必须深入内核 Tracepoint。

1. 使用 ftrace / trace-cmd 捕获直接回收事件

我们可以通过 Linux 提供的 mm_vmscan_direct_reclaim_begin 和 mm_vmscan_direct_reclaim_end 挂载探针：

# 开启内核直接回收与内存紧缩的 tracepoint
echo 1 > /sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_begin/enable
echo 1 > /sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_end/enable
echo 1 > /sys/kernel/debug/tracing/events/compaction/mm_compaction_begin/enable
echo 1 > /sys/kernel/debug/tracing/events/compaction/mm_compaction_end/enable

# 抓取 10 秒钟并分析延迟
cat /sys/kernel/debug/tracing/trace_pipe | awk '
/mm_vmscan_direct_reclaim_begin/ { start[$3] = $4 }
/mm_vmscan_direct_reclaim_end/ { 
    if (start[$3] > 0) {
        latency = ($4 - start[$3]) * 1000000; # 转换为微秒
        if (latency > 50000) { # 超过 50ms 打印告警
            printf("WARNING: Process %s PID %s stuck in Direct Reclaim for %.2f ms\n", $2, $3, latency/1000);
        }
    }
}'

2. 查看系统碎片指数与统计指标

# 检查 direct reclaim 发生的累计次数
grep -E "allocstall|compact_stall|pgpgin|pgpgout" /proc/vmstat

# 查看各 Zone 的 Order-N 内存碎片分布情况
cat /proc/buddyinfo

如果 allocstall（进入慢速直接回收的次数）或 compact_stall 在业务运行期间持续激增，说明当前内存水位配置严重失衡。

---

三、 端侧 AI 场景下的内核参数调优实战

为了彻底消除端侧推理中的 Direct Reclaim，我们的调优核心思想是：抬高 kswapd 的唤醒水位线，让异步后台回收提前介入；同时限制同步内存紧缩的激进程度。

# 1. 提高最小空闲内存保留量 (假设设备物理内存 8GB，保留 512MB 给内核缓冲)
sysctl -w vm.min_free_kbytes=524288

# 2. 扩大 WMARK_LOW 与 WMARK_MIN 的间距 (默认 100，即 10%，建议调大到 300~500)
# 使得 kswapd 能够极早被唤醒，留出充足的缓冲垫
sysctl -w vm.watermark_scale_factor=400

# 3. 降低内存碎片整理触发阈值，避免前台线程陷入昂贵的物理页搬迁
sysctl -w vm.extfrag_threshold=500

# 4. 限制脏页在内存中的最大比例，避免直接回收时发生大规模同步磁盘 I/O
sysctl -w vm.dirty_background_ratio=5
sysctl -w vm.dirty_ratio=10

# 5. 禁用透明大页的同步整理 (THP defrag 改为 madvise 或 defer)
echo defer+madvise > /sys/kernel/mm/transparent_hugepage/defrag

---

四、 调优前后真实压测对比

我们在某基于 ARM64 Cortex-A78 架构的 16GB 边缘计算盒子上，部署 7B 视觉语言模型进行高并发连续批处理（Continuous Batching）压测：

关键性能指标	默认内核配置	调优后配置	收益提升
推理延迟 P50 (ms)	142.5	141.8	基本持平
推理延迟 P99 (ms)	890.4	168.2	$\downarrow 81.1%$
推理延迟 P999 (ms)	2450.0	210.5	$\downarrow 91.4%$
allocstall 触发频率	128 次/小时	0 次/小时	完全消除直接回收
推理吞吐量 (Tokens/s)	28.4	36.1	$\uparrow 27.1%$

---

钟伊人的系统调优方法论

1. 别让应用层的并发掩盖了操作系统的呻吟：许多团队在遇到延迟毛刺时，习惯性地降并发、削减模型上下文窗口，实际上牺牲了产品体验。搞懂内核的 Watermark 机制，用几行 sysctl 往往就能在不改动业务代码的情况下化解性能危机。
2. 端侧内存管理必须算好“空间换时间”的账：将 min_free_kbytes 设大确实会浪费几百兆的 RAM，但如果设备上运行的是核心实时 AI 推理链路，这部分被“浪费”的内存就是保障 P99 确定性时延的最佳护城河。
3. 软硬件全栈协同才是工程壁垒：做端侧 AI 不能只当算法调包侠。深入到物理页分配、DMA 零拷贝与虚拟内存映射底层，才是软硬一体化产品在市场上拉开代际差距的核心竞争力。