ftrace 是 linux 内核原生动态追踪机制，通过 function_graph tracer 记录函数入口出口时间戳、计算自身耗时并保留调用嵌套关系，结合 set_ftrace_filter 限定目标函数、tracepoints 补全上下文、trace-cmd 封装录制与分析，可精准定位内核延迟根因。
ftrace 是 Linux 内核原生支持的动态追踪机制，无需修改代码、不中断服务，就能精确测量内核函数执行延迟。关键在于利用其 function_graph tracer 模式——它记录每个函数的入口和出口时间戳，自动计算耗时，并保留调用嵌套关系，是分析执行延迟最直接有效的手段。
启用 function_graph tracer 并设置目标函数
进入 tracing 接口目录后，先确认 debugfs 已挂载（mount -t debugfs nodev /sys/kernel/debug），再执行：
- 关闭其他 tracer：echo nop > /sys/kernel/debug/tracing/current_tracer
- 启用函数图模式：echo function_graph > /sys/kernel/debug/tracing/current_tracer
- 限定跟踪范围（避免日志爆炸）：echo schedule > /sys/kernel/debug/tracing/set_ftrace_filter（可替换为你要测的函数名，如 __do_softirq、try_to_wake_up）
- 开启 trace：echo 1 > /sys/kernel/debug/tracing/tracing_on
捕获并解析延迟数据
让系统运行一段时间（例如触发一次调度或软中断），然后停掉 trace 并读取结果：
- echo 0 > /sys/kernel/debug/tracing/tracing_on
- cat /sys/kernel/debug/tracing/trace 输出类似如下结构：
0) 1.234589:
0) 1.234621:
0) 1.234635:
0) 1.234642:
0) 1.234650:
0) 1.234658:
0) 1.234666:
0) 1.234674:
每行末尾的 “+ X us” 就是该函数自身的执行耗时（不含子函数），嵌套层级反映调用深度。延迟异常时，可快速定位哪一层耗时突增。
结合 tracepoints 定位延迟上下文
仅看函数耗时不足够，还需知道“为什么此时执行”。启用相关事件 tracepoint 可补全上下文：
- 打开调度事件：echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable
- 打开中断事件：echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable
- 查看混合输出：cat /sys/kernel/debug/tracing/trace_pipe（实时流式输出，适合抓瞬态延迟）
这样就能看到：某次 sched_switch 发生前 50μs，irq_handler_entry 刚被触发，从而判断延迟是否由硬中断抢占导致。
用 trace-cmd 提升效率与可复现性
手动操作易出错且难复现，推荐使用 trace-cmd 封装流程：
- 录制指定函数调用链：trace-cmd record -p function_graph -l 'schedule' -l '__do_softirq'
- 同时采集调度+中断事件：trace-cmd record -e sched:sched_switch -e irq:irq_handler_entry -e softirq:softirq_entry
- 生成火焰图分析热点：trace-cmd report > report.txt 或用 kernelshark 图形化查看时间轴
对于实时系统抖动问题，配合 cyclictest 触发峰值延迟，再用 trace-cmd 精确捕获那一刻的内核执行路径，能明确区分是锁竞争、C-state 唤醒延迟，还是软中断处理阻塞。
