内核栈峰值只能通过debugfs+stack_tracer查看，需先挂载debugfs、启用stack_tracer_enabled，再读取stack_max_size和stack_trace文件获取历史最大值及对应调用链。
内核栈峰值只能通过 debugfs + stack_tracer 查看
Linux 内核本身不提供运行时实时的“当前栈用量”接口，/proc/[pid]/stack 只给用户态线程栈快照，跟内核栈无关。真正能拿到内核栈历史峰值和对应调用链的，只有 stack_tracer 机制，它依赖 debugfs 挂载和内核配置支持（CONFIG_STACK_TRACER=y）。没启用就根本看不到——不是命令没输对，是功能压根没开。
确认是否可用：
-
mount | grep debugfs—— 若无输出，需sudo mount -t debugfs nodev /sys/kernel/debug -
cat /proc/sys/kernel/stack_tracer_enabled—— 输出0表示禁用，用echo 1 | sudo tee /proc/sys/kernel/stack_tracer_enabled开启 -
ls /sys/kernel/debug/tracing/stack_*—— 应存在stack_max_size和stack_trace两个文件
查看已记录的最大内核栈深度及调用链
stack_max_size 是字节单位的峰值大小，stack_trace 是触发该峰值时的完整调用链。二者必须一起看才有意义。
执行：
cat /sys/kernel/debug/tracing/stack_max_size
输出类似：4072（单位：字节）
再执行：
cat /sys/kernel/debug/tracing/stack_trace
输出会包含 Depth、Size 和 Location 三列，最后一行才是栈底（即最深一层），例如：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
Depth Size Location 0) 4072 do_syscall_64+0x3a/0x90 1) 4000 __x64_sys_openat+0x15/0x20 2) 3928 do_filp_open+0x11c/0x2b0 ... 39) 0 page_fault+0x3e/0x5f0
注意：Size 列是累计栈用量，不是单层消耗；Location 是符号名，若内核未编译带调试信息（CONFIG_DEBUG_INFO=y），这里会显示十六进制地址而非函数名。
watch 实时监控内核栈峰值变化
stack_tracer 不是采样器，它只在每次刷新时记录**历史最大值**，不会自动清零。所以单纯 cat 一次看不出“当前压力”，得靠 watch 观察是否还在增长：
watch -n 1 'cat /sys/kernel/debug/tracing/stack_max_size'
如果数值持续变大，说明有内核路径在递归或嵌套过深（比如异常处理链、锁竞争、驱动 bug）；如果卡住不动，说明当前负载未触发新峰值。
关键限制：
- 该机制只跟踪 **内核态执行路径**，用户态栈、中断栈、softirq 栈都不计入
- 开启后有一定性能开销（尤其高频率系统调用场景），生产环境慎用长期开启
-
stack_max_size不重置，除非重启或手动 echo 0 > stack_max_size（但部分内核版本不支持写入）
为什么 ps/top/pmap 都查不到内核栈用量
因为内核栈不在进程虚拟内存空间里管理：/proc/[pid]/maps 显示的是用户空间映射，ps aux 的 VSZ/RSS 完全不含内核栈；pmap -x 只解析用户段；top 的 %MEM 更是整个进程物理内存占比的粗略估算。
常见误解：
- 把
VmStk当成内核栈——错，那是用户态主线程的**栈段虚拟内存上限**（单位 KB），和内核栈毫无关系 - 用
pstack或gdb -p看到的全是用户态调用栈，哪怕进程正卡在系统调用里，gdb 也进不到内核上下文 - 认为
/proc/[pid]/stack能反映内核栈——它只显示该线程最后一次陷入内核时的**寄存器现场**，不是栈用量，也不含历史峰值
真要定位内核栈爆掉（如 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted），stack_trace 文件里的调用链就是唯一可追溯的线索，别指望靠通用内存命令凑出来。
