4、内存性能优化：内存分配路径分析、slab分配器调优、DMA缓冲区管理、内存泄漏检测

内存性能优化，说白了就是让系统在「找内存、用内存、还内存」这条路上跑得又快又稳。我做了这么多年驱动，见过太多系统崩溃、性能瓶颈，最后追根溯源，十有八九都跟内存管理脱不了干系。今天咱们就掰开揉碎，把这条路径上的几个关键节点聊透。

先说说内存分配这条「高速公路」。你写个 kmalloc()，内核到底干了啥？

我习惯把分配路径分成三层：

为什么会这样设计？你想想看，大部分驱动分配的内存都很小（几十到几百字节），如果每次都去伙伴系统折腾，那性能就全浪费在锁和链表遍历上了。

核心知识点：分配路径的瓶颈往往不在分配本身，而在「等待」。等待锁、等待回收、等待页面迁移。我建议你在调试时，先看看 /proc/meminfo 里的 DMA、Normal 区域水位线，如果频繁触发 reclaim，那路径肯定有问题。

这里我画了一张分配路径的流程图，帮你理清脉络：

slab 分配器，说白了就是内核里的「小物件批发市场」。你每次 kmalloc(32)，它不会真去伙伴系统拿一个页，而是从预先准备好的 slab 缓存里切一块给你。

我在项目中遇到过一个问题：某个网卡驱动频繁分配和释放 sk_buff 结构体，导致 slab 缓存碎片化严重，分配延迟从几微秒飙升到几百微秒。后来怎么解决的？调了 slab 的 batchcount 和 limit 参数。

调优技巧：你可以通过 /proc/slabinfo 查看每个 slab 缓存的使用情况。重点关注 active_objs 和 num_objs 的比值。如果比值长期低于 50%，说明缓存浪费严重，可以考虑减小 limit 值。

具体调哪些参数？我列个表：

嗯，这里要注意：调优不是越大越好。我曾经把 batchcount 调得太大，结果内存占用暴涨，反而触发了更频繁的回收。建议你每次只改一个参数，观察 slabinfo 和 perf 数据的变化。

DMA 缓冲区，这是驱动开发里最容易踩坑的地方。说白了，DMA 要的是「物理连续」的内存，而内核平时分配的内存可能是「虚拟连续、物理离散」的。

我习惯把 DMA 缓冲区管理分成三个层次：

一致性 DMA 映射（Consistent DMA）：用 dma_alloc_coherent()。保证 CPU 和 DMA 控制器看到的内存视图一致。适合控制类数据传输。
流式 DMA 映射（Streaming DMA）：用 dma_map_single()。需要手动处理缓存一致性。适合大数据块传输。
DMA 池（DMA Pool）：用 dma_pool_create()。适合频繁分配固定大小 DMA 缓冲区的场景。

避坑指南：我曾经在调试一个视频采集驱动时，发现图像数据偶尔出现撕裂。查了两天才发现，是流式 DMA 映射后忘了调用 dma_sync_single_for_cpu()。记住：流式 DMA 映射的缓冲区，在 CPU 访问前必须做同步！

这里有个常见的性能优化点：对于大数据块传输，尽量使用 dma_map_sg() 做分散/聚集映射。它能把多个不连续的物理页映射成一个 DMA 描述符链，减少 DMA 中断次数。

内存泄漏，驱动开发者的噩梦。用户态泄漏顶多进程挂掉，内核态泄漏直接系统崩溃。

我常用的检测手段有三个：

kmemleak：内核自带的内存泄漏检测器。配置 CONFIG_DEBUG_KMEMLEAK=y，然后 echo scan > /sys/kernel/debug/kmemleak 触发扫描。
slabinfo 监控：写个脚本定时抓取 /proc/slabinfo，对比 active_objs 的变化趋势。如果某个 slab 缓存的对象数只增不减，那大概率泄漏了。
kprobe 跟踪：对 kmalloc 和 kfree 做插桩，记录分配和释放的调用栈。我习惯用 trace-cmd 配合 kernelshark 可视化分析。

实战案例：有一次我发现 dma_alloc_coherent 分配的内存没有对应释放。用 kmemleak 一查，报出了未引用的内存块。定位到代码后发现，是某个错误处理路径里忘了调用 dma_free_coherent。修复后，系统稳定性明显提升。

最后送你一句话：内存优化没有银弹。每个驱动、每个场景都不一样。但只要你把分配路径摸透了，把 slab 和 DMA 的机制搞清楚了，再配合好用的检测工具，大部分问题都能迎刃而解。

我的习惯：每次提交驱动代码前，我都会在 insmod 和 rmmod 前后对比 /proc/meminfo 和 /proc/slabinfo。如果内存占用有变化，那一定是有泄漏。这个习惯帮我避免了好几次线上事故。

想要更多资料，联系可可