从 Linux 5.13 开始，vmalloc() 默认尝试使用大页映射，但需满足空闲大页充足、地址对齐及分配大小足够（通常 ≥ 几十 KB）等条件；可通过启用 CONFIG_DEBUG_VM_VALLOC 查看 dmesg 日志或结合 /sys/kernel/debug/page_owner 分析页 order 确认，小内存系统慎用，启动参数 nohugevmalloc 可全局禁用。
vmalloc() 用大页了吗？怎么确认？
从 Linux 5.13 开始，vmalloc() 默认尝试使用大页（huge pages）映射，但不是所有情况都生效——它依赖 zone 的空闲大页数量、对齐要求和分配大小。你不能靠 cat /proc/vmallocinfo 直接看出是否用了大页，因为该接口不暴露页粒度信息。
内核提供了 is_vm_area_hugepages(const void *addr) 这个内联函数来判断，但它依赖未导出的 find_vm_area()，所以**树外模块（比如你自己写的 ko）根本没法调用**。实际调试时，更可行的方式是：在内核配置中启用 CONFIG_DEBUG_VM_VALLOC，然后触发分配后检查 dmesg 是否出现 vmalloc(): using hugepage 类似日志；或者用 /sys/kernel/debug/page_owner 配合 addr 查看对应页的 order（order ≥ 2 通常意味着 4KB → 2MB 映射）。
- 嵌入式小内存系统慎用：大页可能导致内部碎片，比如只申请 16KB 却占掉一个 2MB 大页
- 启动时加
nohugevmalloc参数可全局禁用，比运行时 patch 更可靠 - 注意：即使启用了，
vmalloc(4096)也大概率还是用 4KB 页——大页只对 ≥ 几十 KB 的分配有收益
SLAB 回收为什么有时“卡住”不释放？
SLAB 分配器本身不主动回收 slab 缓存，而是等 kmem_cache_shrink() 被显式调用或由内存压力触发的 shrink_slab() 路径间接执行。常见现象是：你调了 kmem_cache_destroy()，但 /proc/slabinfo 里对应缓存项仍存在，甚至 slabinfo -a 显示 active_objs > 0。
原因通常是对象还在被引用：比如某个 struct 被放在链表里但没删干净，或被 RCU 持有未完成宽限期。SLAB 不会强制回收正在使用的对象，也不会等待 RCU 宽限期自动结束。
- 用
slabinfo -v cache_name查看详细状态，重点关注active_objs和num_objs差值 - RCU 场景下，必须确保所有
synchronize_rcu()或call_rcu()回调已执行完毕 - 驱动模块卸载前，务必先清空所有对象引用，再调
kmem_cache_destroy()，否则可能 oops
OOM 前内存回收到底按什么顺序走？watermark 是怎么起作用的？
不是等 free 内存归零才回收，而是在空闲页低于 watermark[WMARK_LOW] 时就启动快速回收（kswapd），低于 watermark[WMARK_MIN] 则触发直接回收（alloc_pages() 中同步阻塞执行）。三个水位关系固定：min ，且 low = min + min/4，high = min + min/2。
关键点在于：kswapd 只负责把空闲页拉回 high 水位以上；一旦进程分配触发 direct reclaim，说明 low 都守不住了，此时回收路径会更激进（比如扫描更多 LRU 链表、尝试 swap、甚至考虑 OOM）。
- 查看当前水位：
grep -A10 "Node.*DMA\|Node.*Normal" /proc/zoneinfo -
echo 1 > /proc/sys/vm/swappiness并不能阻止 page cache 回收——只要 anon 和 file 页面都在 LRU 上，file 页面永远优先被回收 - 频繁触发 direct reclaim？说明工作负载长期压着 low 水位跑，要么加内存，要么减少 mmap 大量文件或 tmpfs 使用
用户态看到的 “free 内存少”，真缺内存吗？
Linux 把大量空闲内存用于 page cache 和 slab，free 命令显示的 “available” 才是真正可立即分配的预估值（含可回收 cache）。很多运维第一反应是 kill 进程，但往往杀的是正在用 cache 加速 I/O 的进程，反而让磁盘变慢、延迟飙升。
真正要查的是：有没有进程在疯狂分配 anon 内存又不释放（如内存泄漏）、是否 swapin/si 持续升高（说明已在用 swap）、/proc/meminfo 中 Inactive(file) 是否远高于 Active(file)（cache 没被有效利用）。
- 别信 top 里的 %MEM 排序结果——它算的是 RSS，包含共享库和 mmap 共享内存，不代表独占消耗
- 用
ps aux --sort=-vsz | head -10看虚拟内存占用，再结合pmap -x PID看具体段分布 - 如果
Available还剩 1GB 以上，但系统卡顿，大概率是 I/O 或锁竞争问题，不是内存不足
水位计算是 per-zone 的，NUMA 系统里某 node 的 low 水位被击穿，可能只影响该 node 分配，不一定触发全局 OOM；而 slab 回收的时机藏在 shrink_slab() 的调用链深处，不深入到 mm/vmscan.c 很难看清它到底什么时候愿意放手。
