【编辑部·技术】用 ftrace 查嵌入式 Linux 驱动延迟：function_graph、irqsoff 和 trace-cmd 上手

嵌入式 Linux 上遇到「偶发卡顿」「中断响应慢」「某个驱动调用偶尔耗时很长」，第一反应往往是加 printk。但 printk 本身有开销，还会改变时序。内核自带的 ftrace 是更好的工具，几乎所有发行版和大部分嵌入式内核配置都可以打开。

一、打开和入口

1. 内核配置里打开 CONFIG_FTRACE 以及需要的跟踪器，比如 CONFIG_FUNCTION_TRACER、CONFIG_FUNCTION_GRAPH_TRACER、CONFIG_IRQSOFF_TRACER。
2. 接口在 tracefs 下，新内核一般是 /sys/kernel/tracing，老内核在 /sys/kernel/debug/tracing。
3. cat available_tracers 可以看到当前内核支持的跟踪器。

二、三个最常用的跟踪器

1. function_graph：记录函数调用的进入和返回，并给出每个函数的耗时，适合查「某个驱动函数为什么慢」。用 set_graph_function 限定只跟踪你关心的函数，避免数据量爆炸。
2. irqsoff：记录关中断时间最长的那一段代码路径，适合查「中断响应偶发变慢」，看看是谁关中断太久。
3. wakeup_rt：记录最高优先级实时任务从被唤醒到真正运行之间的最大延迟，适合实时性调优。

另外，事件跟踪（events 目录下的 sched、irq 等跟踪点）开销较低，适合长时间挂着抓偶发问题。

三、用 trace-cmd 简化操作

直接读写 tracefs 文件比较繁琐，可以用 trace-cmd：
1. trace-cmd record -p function_graph -g 你的驱动函数名，然后运行复现程序；
2. trace-cmd report 查看结果；
3. 数据可以拷到 PC 上用 KernelShark 图形化查看。

四、使用建议

1. 先用事件跟踪大范围定位，再用 function_graph 精确到函数，跟踪范围越小，对系统的干扰越小。
2. 实时性问题可以配合 rt-tests 里的 cyclictest 先量化延迟，再用 ftrace 找原因。
3. 生产固件里可以保留 ftrace 但默认关闭，出问题时现场打开，比重新编译带调试打印的版本方便得多。

讨论：你们在嵌入式 Linux 项目里排查延迟问题，最常用的是 ftrace、perf，还是别的工具？有没有一次靠跟踪工具找到意想不到的根因？

【编辑部】补充一句：生产环境打开 function_graph 全量跟踪会明显拖慢系统，务必用 set_graph_function / set_ftrace_filter 收窄范围；偶发问题优先用 events 长时间挂着。

大家嵌入式 Linux 项目里，延迟问题最常用 ftrace、perf 还是示波器看 GPIO 翻转？