Linux trace-cmd record / report / profile 的火焰图生成完整链路

必须显式指定-e sched:sched_switch和-e sched:sched_wakeup才能捕获完整调度路径，避免火焰图平顶；通配-e sched会漏迁移到事件，锁分析还需加-e lock:lock_acquired等。

trace-cmd record 怎么选 -e 事件才不漏关键调度路径

trace-cmd record 默认不抓调度事件，光录 syscalls 或 irq 画不出调度延迟火焰图。必须显式加 -e sched:sched_switch 和 -e sched:sched_wakeup，否则 trace-cmd report 里看不到进程切换上下文，火焰图里全是平顶——不是没热点，是根本没录到。

• sched:sched_switch 是必选，它记录每次 CPU 上下文切换的 from → to 进程
• sched:sched_wakeup 补上唤醒链，能看清谁把谁叫醒、为什么阻塞
• 避免用 -e sched（通配），内核 5.10+ 会默认禁用部分低频事件，反而漏掉 sched_migrate_task 这类跨 CPU 迁移线索
• 如果目标是锁竞争，得额外加 -e lock:lock_acquired 和 -e lock:lock_contended，不然火焰图里只看到 mutex_lock 调用，看不到谁在等谁

trace-cmd report 输出的 trace.dat 怎么喂给 FlameGraph

trace-cmd report 本身不输出文本堆栈，直接拿它的 stdout 去管道进 stackcollapse-perf.pl 会失败——因为格式是人类可读的事件流，不是 perf 格式。必须先用 trace-cmd extract 抽成二进制 trace.dat，再转成 perf 兼容格式。

• 正确链路：trace-cmd extract -o trace.dat（生成 trace.dat）→ perf script -F comm,pid,tid,cpu,time,period,Event,ip,sym,dso -F callgraph=fp -i trace.dat 2>/dev/NULL → 管道进 stackcollapse-perf.pl
• 注意 perf script 的 -F callgraph=fp 参数：必须显式指定，否则默认用 dwarf，而 trace-cmd 录的栈帧没 dwarf info，结果全是 [unknown]
• 如果 perf script 报错 “no symbols found”，不是符号没加载，是 trace-cmd 录的时候没开 --call-graph fp（但 trace-cmd 不支持该参数），所以只能靠 kernel 启用 CONFIG_FRAME_POINTER=y 编译，否则 fp 栈不可用

trace-cmd profile 为什么比 record + report 更适合快速看 CPU 占用热点

trace-cmd profile 是个快捷命令，底层自动启用 function_graph + sched + irq 事件，并做轻量聚合，省去手动挑事件、调 buffer size、防丢包的步骤。但它默认关掉了高精度时间戳，profile 输出的延迟分布会抹平 sub-millisecond 级抖动。

• 适合场景：快速定位哪个函数吃 CPU 最多，比如发现 ext4_writepages 占 40%，不用深挖调度细节
• 不适合场景：分析单次系统调用延迟毛刺，或确认某个 sched_wakeup 到 sched_switch 的精确间隔
• 它生成的 trace.dat 可直接用 trace-cmd report 查看，但火焰图效果不如 record -e sched* 细致——因为没录 full stack trace，只有函数入口/出口点
• 如果想保留精度又省事，改用：trace-cmd record -e sched:sched_switch -e sched:sched_wakeup -e irq:irq_handler_entry -r 8192 -b 8（增大 ring buffer 和子 buffer）

火焰图里出现大量 [unknown] 或 [k] 符号怎么修

[unknown] 不是工具坏了，是用户态符号或内核符号没对齐。常见原因有三个：符号文件路径不对、内核版本不匹配、或者 perf 没权限读 /proc/kallsyms。

• 检查 perf script 是否能解析内核符号：perf script -F sym | head -5，如果全是 [k] 或地址，说明 /proc/kallsyms 权限不足（需 root 运行 trace-cmd record，否则 kallsyms 为空）
• 用户态符号丢失：确保程序编译带 -g，且运行时没 strip；若用容器，宿主机和容器内 /proc/pid/root 下的二进制要一致
• 内核符号不匹配：uname -r 输出的版本必须和 /lib/debug/lib/modules/$(uname -r)/vmlinux 存在且校验通过，缺 vmlinux 就会 fallback 到地址，火焰图里就是一堆 0xffffffff81123abc

火焰图不是万能放大镜，它依赖 trace-cmd 录什么、perf 解什么、符号在哪——三个环节断一个，图就变“抽象派”。最常被跳过的其实是录之前确认 cat /proc/sys/kernel/kptr_restrict 是 0。