内核栈已用最大值通过cat /sys/kernel/debug/tracing/stack_max_size查看，对应调用链通过cat /sys/kernel/debug/tracing/stack_trace获取，二者需在debugfs挂载且stack_tracer_enabled=1后才有效。
怎么查内核栈已用最大值（stack_max_size）
内核栈的“峰值使用量”不是运行时实时可读的瞬时值，而是自系统启动或启用追踪以来记录过的最大深度（单位字节）。它存在 /sys/kernel/debug/tracing/stack_max_size，但前提是 debugfs 已挂载且 stack tracer 已启用。
操作分三步：
- 挂载 debugfs：mount -t debugfs nodev /sys/kernel/debug（若目录为空，说明未挂载）
- 启用追踪：echo 1 > /proc/sys/kernel/stack_tracer_enabled
- 查峰值：cat /sys/kernel/debug/tracing/stack_max_size
注意：该值不会自动清零，重启或手动 echo 0 > /proc/sys/kernel/stack_tracer_enabled 再 echo 1 才能重置。它只反映“历史上最深的一次”，不是当前线程栈用量。
怎么看到对应峰值的完整调用链（stack_trace）
有了 stack_max_size，下一步是定位触发该峰值的内核函数路径。关键文件是 /sys/kernel/debug/tracing/stack_trace，它和前者同步更新。
直接 cat 它会输出带缩进的调用链，例如：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
Depth Size Location ----- ---- -------- 0) 4072 do_sys_open+0x4a/0x1c0 1) 3984 do_filp_open+0x5e/0x120 2) 3864 path_openat+0x2b8/0x12c0 ...
每行开头的 Depth 是帧序号，Size 是该帧起始到栈顶的字节数（累加即为 max_size），Location 是符号化地址。若看不到函数名，说明内核未配置 CONFIG_KALLSYMS 或未启用 CONFIG_STACKTRACE。
常见坑：
- /sys/kernel/debug/tracing/stack_trace 只在 stack_tracer_enabled == 1 时更新
- 若文件为空，先确认 cat /sys/kernel/debug/tracing/stack_max_size 是否非零
- 输出中出现大量 ??? 表示缺少符号映射，需检查内核是否带调试符号（vmlinux 文件）
为什么 dmesg | grep -i "stack" 几乎没用
很多人想用 dmesg 搜栈相关日志，但内核默认不打印栈深度信息。SysRq+t 输出的是当前所有 CPU 的任务栈快照（类似用户态 pstack），不是历史峰值；它也不带字节数，只有函数名和寄存器状态。
真正有用的线索只在 tracing 子系统里：
- stack_max_size 和 stack_trace 是唯二记录“最大值+调用链”的组合
- SysRq+t、crash、perf 都只能看瞬时栈，无法回溯峰值
- /proc/[pid]/stack 是用户态线程栈，和内核栈无关
别被名字误导：“stack” 在不同上下文指代完全不同——内核栈、用户栈、内核线程栈、中断栈，它们各自独立，且监控路径完全不同。
实际排查时最容易忽略的点
stack tracer 不是开箱即用的功能。它依赖三个隐性条件同时满足：
- debugfs 必须挂载在 /sys/kernel/debug（不是其他路径）
- 内核编译时启用了 CONFIG_STACKTRACE=y 和 CONFIG_TRACING=y
- 当前运行的内核镜像（vmlinux）必须与 /proc/kallsyms 符号表匹配，否则 stack_trace 里全是地址，没法看出是哪个驱动或子系统惹的祸
如果你在容器里或云主机上试，大概率失败——多数生产环境内核裁剪掉了 tracing 支持，或者 debugfs 被禁用。这时候只能靠 crash 分析 dump 文件，或改用 ftrace 动态过滤特定函数来间接逼近问题点。
