1. 为什么内核开发者都绕不开 /proc/vmallocinfo第一次在生产环境里排查内存泄漏是在一台跑了三天压力测试的服务器上。free -m显示可用内存还剩不少但slabtop和meminfo里VmallocUsed那一栏的数字却一路往上爬怎么都降不下来。当时翻遍了/proc/meminfo、/proc/slabinfo甚至把kmemleak都打开了最后才在/proc/vmallocinfo里找到线索——某个驱动模块在每次 ioctl 调用时都vmalloc了一块缓冲区但释放路径上漏掉了一个分支。/proc/vmallocinfo这个文件说白了就是内核给你开的一扇窗让你能看到当前系统里所有通过vmalloc系列接口分配的虚拟内存区域。它不像/proc/meminfo那样只给你一个汇总数字而是逐条列出每一块 vmalloc 区域的起始地址、大小、调用者、物理页使用情况等细节。对于做内核模块开发、驱动调试、内存泄漏排查的人来说这个文件的价值不亚于用户态里的valgrind。这篇文章适合谁看如果你写过字符设备驱动、做过内核模块的内存管理、或者被VmallocUsed只增不减的问题折磨过那这篇内容就是给你准备的。我会从 vmalloc 的底层机制讲起把/proc/vmallocinfo每一列的含义拆开揉碎再结合几个真实的排查场景把怎么用它定位问题、怎么读懂那些看起来像天书的地址和调用栈一步步说清楚。即使你之前只会在终端里敲cat /proc/vmallocinfo然后一脸茫然看完也能自己分析出个所以然来。2. vmalloc 机制与 /proc/vmallocinfo 的底层逻辑2.1 vmalloc 和 kmalloc 到底差在哪要理解/proc/vmallocinfo得先搞清楚 vmalloc 在内核内存管理体系里的位置。内核里分配内存主要有两条路kmalloc和vmalloc。kmalloc分配的是物理地址连续的内存直接映射在内核的线性映射区x86_64 上是PAGE_OFFSET开始的那片区域分配速度快但受限于物理内存碎片大块连续物理内存不好找。vmalloc则不同它分配的是虚拟地址连续、但物理地址可以不连续的内存内核通过页表把一块块分散的物理页映射到一段连续的虚拟地址空间上。这个区别带来的直接后果是vmalloc适合分配大块内存比如几十 MB 甚至上百 MB因为不需要物理连续碎片化压力小但代价是每次访问都要走页表映射TLB 命中率低性能不如kmalloc。而且vmalloc的分配和释放涉及页表操作开销比kmalloc大得多。所以内核里的原则是能用kmalloc就用kmalloc只有确实需要大块内存且对性能不那么敏感时才用vmalloc。/proc/vmallocinfo记录的就是所有走vmalloc路径分配的区域。这里说的vmalloc 路径包括vmalloc、vzalloc、vmalloc_user、vmalloc_exec、vmap、ioremap等一系列接口。它们最终都会在 vmalloc 地址空间里占一块地也都会出现在这个文件里。2.2 vmalloc 地址空间长什么样在 x86_64 架构上内核虚拟地址空间被划分成几个区域。直接映射区direct map从PAGE_OFFSET开始通常覆盖所有物理内存vmalloc 区则位于直接映射区之上范围大致在VMALLOC_START到VMALLOC_END之间。在 4 级页表的 x86_64 上VMALLOC_START一般是0xffffc90000000000VMALLOC_END是0xffffe8ffffffffff中间有大约 32TB 的虚拟空间可供 vmalloc 使用。每个 vmalloc 区域在内核里用一个struct vmap_area结构来描述记录起始地址、大小、标志位等信息。这些vmap_area被挂在一棵红黑树vmap_area_root和几个链表上方便快速查找和遍历。/proc/vmallocinfo的实现就是遍历这棵红黑树把每个vmap_area对应的信息格式化输出。具体来说内核里有个struct vm_struct结构它和vmap_area一一对应或者说vmap_area是地址空间的管理结构vm_struct是映射本身的描述。vm_struct里保存了addr、size、flags、pages数组、caller调用者地址等关键字段。/proc/vmallocinfo的show函数就是遍历所有vmap_area找到对应的vm_struct然后打印出这些字段。2.3 这个文件是什么时候出现的/proc/vmallocinfo并不是从一开始就有的。它最早在 2006 年左右被引入内核大约 2.6.19 版本最初的目的是给开发者提供一个调试 vmalloc 分配情况的接口。在这之前想知道系统里有哪些 vmalloc 区域只能靠猜或者加打印。引入之后它逐渐成为内核内存调试的标准工具之一。需要注意的是这个文件只有在内核编译时开启了CONFIG_PROC_FS和CONFIG_MMU的情况下才存在。大多数发行版的内核都默认开启但如果你在嵌入式环境里跑的是裁剪过的内核有可能这个文件根本不存在。另外读取这个文件需要 root 权限普通用户是看不到的。还有一个细节/proc/vmallocinfo的输出是动态生成的每次read都会重新遍历红黑树。这意味着在高并发分配释放 vmalloc 的场景下读到的数据可能不是完全一致的快照但用于排查问题足够了。3. 逐列拆解 /proc/vmallocinfo 的输出格式3.1 一行典型输出长什么样先看一行真实的输出0xffffc90000000000-0xffffc90000002000 8192 vmalloc N02 pages2 vmap callerffffffff81234567不同内核版本的格式略有差异但核心字段是一致的。较新的内核5.x 以后通常是这样0xffffc90000400000-0xffffc90000421000 135168 ioremap pages33 vmap callerffffffffa0001234我们逐段拆开看。3.2 地址范围与大小第一段是0xffffc90000400000-0xffffc90000421000这是这块 vmalloc 区域的虚拟地址起止范围。起始地址是0xffffc90000400000结束地址是0xffffc90000421000。两者相减得到0x21000也就是 135168 字节正好对应后面的 size 字段。这个地址范围告诉你两件事一是这块区域在 vmalloc 空间里的具体位置二是它的大小。如果你在排查地址冲突或者越界访问这个范围就是最直接的依据。比如某个驱动报告说访问了0xffffc90000420000附近的地址出了错你就能立刻定位到是哪个 vmalloc 区域。3.3 大小字段与对齐规则第二段是大小单位是字节。上面例子里的135168就是 132KB。注意 vmalloc 分配的大小都是页对齐的最小是一页4KB然后按页向上取整。比如你请求 5000 字节实际会分配 8192 字节2 页。所以你在/proc/vmallocinfo里看到的大小往往比代码里请求的稍大一些这是正常的。有个经验如果你看到某个区域的大小是 4096 的整数倍那基本可以确认是 vmalloc 分配的如果出现非页对齐的数字那可能是vmap或者ioremap的特殊情况需要结合后面的标志位判断。3.4 分配类型与标志位第三段是分配类型常见的有vmalloc、vzalloc、vmap、ioremap、vmalloc_user、vmalloc_exec等。这个字段直接告诉你这块内存是通过哪个接口分配的。vmalloc标准 vmalloc 分配物理页不连续虚拟地址连续。vzalloc和 vmalloc 一样但分配后清零。vmap把一组已经存在的物理页映射到连续的虚拟地址上常用于vm_map_ram或者模块加载时的代码段映射。ioremap把设备 MMIO 物理地址映射到内核虚拟地址用于访问硬件寄存器。vmalloc_user专门给用户态用的 vmalloc通常配合mmap使用。vmalloc_exec分配可执行内存用于 JIT 或者动态代码生成。这个字段是排查问题的第一线索。比如你发现ioremap区域特别多那可能是某个驱动反复映射寄存器却没释放如果vmalloc区域数量持续增长那大概率是内存泄漏。3.5 物理页信息与 N0 的含义较新内核的输出里会出现N02这样的字段。这里的N0表示 NUMA 节点 0 上使用的物理页数量。如果是多 NUMA 系统可能会有N0、N1等多个字段。这个信息对于分析内存分布很有用——如果某个 vmalloc 区域大量使用远端 NUMA 节点的内存性能可能会受影响。紧接着的pages33表示这块区域实际映射了 33 个物理页。注意这个数字和大小字段不一定完全对应因为 vmalloc 区域里可能有空洞比如vmap映射的页不连续或者有些页被特殊处理过。3.6 caller 字段定位调用者的关键callerffffffffa0001234这一行是最有价值的字段之一。它记录了调用vmalloc的那个函数的返回地址在内核代码段里的地址。通过这个地址你可以用addr2line或者gdb反查到具体的函数名和行号。具体操作是这样的假设你有一个带调试信息的内核镜像vmlinux执行addr2line -e vmlinux -f -i ffffffffa0001234输出会告诉你这个地址对应哪个函数、哪个文件、哪一行。如果是模块里的地址需要先找到模块的加载基址然后计算偏移。模块的加载信息可以在/proc/modules里看到每个模块的基址和大小都有记录。这个字段的精度取决于内核编译时是否开启了CONFIG_DEBUG_INFO和帧指针。有些优化过的内核可能拿不到准确的调用者信息这时候 caller 可能显示为0x0或者一个不太准的地址。3.7 用户态映射的特殊标记如果一块 vmalloc 区域是通过vmalloc_user分配并映射到用户态的输出里可能会看到user标记。这类区域通常和某个用户进程的mmap调用相关排查时需要结合/proc/pid/maps一起看。还有一种情况是vmap映射的页来自vm_map_ram这类区域在输出里会显示vmap类型并且 pages 字段可能和大小不完全对应因为vm_map_ram允许映射非连续的物理页。4. 实操用 /proc/vmallocinfo 定位内存泄漏4.1 场景设定与初步观察假设你负责维护一个字符设备驱动最近收到反馈说系统跑久了之后VmallocUsed持续增长最终导致vmalloc分配失败。你登录到测试机先看一眼整体情况grep Vmalloc /proc/meminfo输出VmallocTotal: 34359738367 kB VmallocUsed: 524288 kB VmallocChunk: 34359214080 kBVmallocUsed已经到 512MB 了而且你知道这个驱动正常情况下应该只用几 MB。接下来就该/proc/vmallocinfo上场了。4.2 统计各类型分配的数量和总大小直接cat /proc/vmallocinfo输出可能几千行先做统计awk {print $3} /proc/vmallocinfo | sort | uniq -c | sort -rn这会按分配类型统计数量。如果看到vmalloc类型的数量是几百上千那基本可以确定有泄漏。接着统计总大小awk /vmalloc/ {sum $2} END {print sum/1024/1024 MB} /proc/vmallocinfo如果这个数字远大于预期继续往下查。4.3 按 caller 聚合找出泄漏点关键一步是按 caller 聚合grep vmalloc /proc/vmallocinfo | awk {print $NF} | sort | uniq -c | sort -rn | head -20这会列出调用次数最多的 caller 地址。假设你看到某个地址出现了 500 次那它就是重点嫌疑对象。用addr2line反查addr2line -e vmlinux -f -i ffffffffc000abcd如果输出指向你驱动里的某个xxx_ioctl函数那问题就定位到了——每次 ioctl 都分配但没释放。4.4 对比不同时间点的快照有时候泄漏不是那么明显需要对比。做法是间隔一段时间抓两次快照cat /proc/vmallocinfo /tmp/vmalloc_1.txt sleep 60 cat /proc/vmallocinfo /tmp/vmalloc_2.txt diff /tmp/vmalloc_1.txt /tmp/vmalloc_2.txt | head -50如果 diff 输出里大量出现新增的 vmalloc 行而没有对应的减少那就是泄漏。这个方法在压力测试场景下特别有效因为正常分配释放会成对出现diff 里不会留下太多痕迹。4.5 结合模块信息定位到具体驱动如果 caller 地址落在某个内核模块里需要先找到模块基址grep xxx_driver /proc/modules输出类似xxx_driver 163840 0 - Live 0xffffffffc0000000基址是0xffffffffc0000000。假设 caller 是0xffffffffc000abcd那偏移就是0xabcd。用objdump反汇编模块objdump -d xxx_driver.ko | grep -A5 abcd或者如果有模块的调试信息直接用addr2line加上偏移addr2line -e xxx_driver.ko -f -i 0xabcd这样就能精确定位到模块里的哪一行代码在分配内存。4.6 一个真实的排查记录之前遇到过一个案例某驱动在每次打开设备时调用vmalloc分配一块 DMA 缓冲区但在release路径上只释放了部分资源漏掉了vfree。表现就是每次open/close循环后VmallocUsed增加一点。用上面的方法先按 caller 聚合发现某个地址的调用次数和open次数完全吻合反查后确认是release函数里少了一行vfree。补上之后问题解决。这个案例说明一个点/proc/vmallocinfo的 caller 字段是定位泄漏的利器但前提是内核和模块都带调试信息。生产环境的内核往往是裁剪过的这时候可以退而求其次用地址范围结合模块基址来大致判断是哪个模块。5. 常见问题与排查技巧实录5.1 为什么 VmallocUsed 和 vmallocinfo 加起来对不上这是个高频问题。/proc/meminfo里的VmallocUsed统计的是所有 vmalloc 区域占用的虚拟空间总和但/proc/vmallocinfo里你手动加起来可能对不上。原因有几个一是VmallocUsed包含了vmap和ioremap的区域而你可能只统计了vmalloc类型二是有些区域在统计时可能正在被释放存在竞态三是VmallocUsed的计算方式在不同内核版本里有差异有些版本会减去 guard page 的开销。排查时不要纠结于数字完全一致重点看趋势。如果VmallocUsed持续增长而 vmallocinfo 里的条目也在增加那方向就是对的。5.2 caller 显示为 0x0 怎么办caller 为 0 通常意味着内核编译时没有保留足够的调试信息或者调用路径经过了尾调用优化返回地址被覆盖了。这时候可以尝试检查内核配置里CONFIG_DEBUG_INFO是否开启。用CONFIG_FRAME_POINTER重新编译内核保留帧指针。如果实在拿不到 caller退而求其次用地址范围结合/proc/modules里的模块基址来缩小范围。5.3 大量 ioremap 区域不释放怎么查ioremap泄漏通常发生在驱动初始化时映射了寄存器但卸载时忘记iounmap。排查方法和 vmalloc 类似按 caller 聚合找到反复出现的地址。另外可以看/proc/iomem对比物理地址映射情况如果某个物理地址范围被反复映射那就是问题所在。5.4 vmalloc 分配失败但内存明明够这种情况往往是 vmalloc 地址空间碎片化导致的。虽然物理内存充足但 vmalloc 虚拟地址空间里找不到足够大的连续空洞。/proc/vmallocinfo可以帮你看到碎片情况——如果地址范围里有很多小空洞但最大的连续空洞不够大那分配就会失败。解决办法通常是减少不必要的 vmalloc 分配或者调整分配策略。5.5 读取 vmallocinfo 会不会影响性能会有一点影响因为读取时要遍历红黑树并格式化输出。在 vmalloc 区域特别多几万条的情况下一次cat可能耗时几百毫秒。生产环境排查时建议避开业务高峰或者用head、grep限制输出量。另外不要在高频循环里反复读取那样会加重锁竞争。5.6 常见问题速查表现象可能原因排查方法VmallocUsed 持续增长vmalloc 泄漏按 caller 聚合对比时间点快照caller 显示 0x0缺少调试信息检查内核配置重新编译分配失败但内存充足地址空间碎片化查看地址范围空洞分布ioremap 区域过多驱动未 iounmap按 caller 聚合检查驱动卸载路径读取耗时过长区域数量过多用 grep/head 限制输出避开高峰5.7 几个容易踩的坑第一个坑是直接cat /proc/vmallocinfo然后被几千行输出淹没。正确做法是先统计再细看用awk、sort、uniq组合快速定位异常。第二个坑是忽略了 guard page。vmalloc 分配时每个区域之间会插入一个 guard page 防止越界这个页不计入 size 字段但会占用地址空间。所以实际地址范围可能比 size 大 4KB。第三个坑是以为 vmallocinfo 是实时快照。实际上它是遍历时动态生成的在高并发场景下可能读到不一致的数据。如果需要精确对比最好在系统相对空闲时抓取。第四个坑是忘了检查模块基址。caller 地址如果是模块里的直接addr2line对vmlinux是查不到的必须先减去模块基址。6. 进阶用法结合其他工具做深度分析6.1 和 /proc/meminfo 联动看趋势单独看 vmallocinfo 只能看到当前状态结合/proc/meminfo的历史数据才能看出趋势。可以写个简单的监控脚本每隔一段时间记录VmallocUsed和 vmallocinfo 的条目数while true; do used$(grep VmallocUsed /proc/meminfo | awk {print $2}) count$(wc -l /proc/vmallocinfo) echo $(date %s) $used $count sleep 300 done把输出重定向到文件跑一天后画个图泄漏趋势一目了然。6.2 用 crash 工具做离线分析如果系统已经崩溃或者无法直接读取 proc 文件可以用crash工具分析内存转储。crash里有个vm命令可以列出 vmalloc 区域效果和/proc/vmallocinfo类似但可以在离线状态下使用。具体命令是crash vm这会输出所有 vmalloc 区域的地址、大小、类型和调用者。对于分析崩溃现场的 vmalloc 状态特别有用。6.3 自定义内核模块导出更多信息如果标准输出不够用可以写个内核模块遍历vmap_area_root红黑树导出更详细的信息比如每个区域的物理页分布、NUMA 节点分布、分配时间戳等。核心代码大致是struct vmap_area *va; struct vm_struct *vm; rcu_read_lock(); list_for_each_entry_rcu(va, vmap_area_list, list) { if (va-flags VM_VM_AREA) { vm va-vm; if (vm) { pr_info(addr%p size%lu caller%pS\n, vm-addr, vm-size, vm-caller); } } } rcu_read_unlock();这个模块可以按需加载输出到 dmesg 或者自定义的 proc 文件里。注意遍历时要加 RCU 锁否则可能和并发的分配释放操作冲突。6.4 在容器环境里的注意事项容器里读/proc/vmallocinfo看到的是宿主机的全局信息不是容器隔离的。因为 vmalloc 是内核全局资源没有 namespace 隔离。所以在容器里排查时看到的可能是其他容器或者宿主机本身的分配需要结合 cgroup 信息一起判断。另外容器里通常没有 root 权限可能读不了这个文件需要在宿主机上操作。6.5 自动化监控脚本示例最后给一个实用的监控脚本可以集成到现有的运维体系里#!/bin/bash THRESHOLD1048576 # 1GB in KB used$(grep VmallocUsed /proc/meminfo | awk {print $2}) if [ $used -gt $THRESHOLD ]; then echo WARNING: VmallocUsed is ${used}KB, exceeds threshold echo Top callers: grep vmalloc /proc/vmallocinfo | awk {print $NF} | \ sort | uniq -c | sort -rn | head -10 fi这个脚本可以放到 cron 里定时执行超过阈值就输出 top caller方便快速定位。我个人在实际操作中的体会是/proc/vmallocinfo最大的价值不在于它给了你一个数字而在于它把每一块 vmalloc 区域的来龙去脉都摊开给你看。caller 字段是灵魂学会用addr2line反查调用者基本上就能解决八成的 vmalloc 相关问题。剩下的两成要么是内核裁剪太狠拿不到信息要么是并发场景下的竞态那就需要结合 crash 工具或者自定义模块来深挖了。另外提醒一句排查完记得把监控脚本留着下次再出问题就不用从头来过了。