1、ftrace初探：什么是ftrace？为什么需要ftrace？
说实话，我第一次接触ftrace的时候，心里是有点抵触的。那时候我还在做嵌入式驱动开发，系统出了个诡异的内核态死锁，用printk打日志打到怀疑人生。同事扔过来一句「试试ftrace」，我一看这玩意儿连个像样的用户手册都没有，全是debugfs里那些零散的文件节点，心里直犯嘀咕。
但后来我服了。真的服了。
ftrace，全称是Function Tracer，是Linux内核内置的一个跟踪框架。说白了，它让你能「偷看」内核在干什么——哪个函数被调用了、调用了多久、调用的路径是什么样的。而且最关键的是，它几乎零开销（在关闭时），开启时的性能损耗也远低于其他方案。
核心要点：ftrace是内核自带的，不需要额外安装。你只要挂载debugfs，就能开始用。
为什么需要ftrace？
你想想看，调试内核最痛苦的是什么？是「黑盒」。用户态程序崩了，有core dump，有gdb。内核崩了？嗯，你只能看oops消息，或者祈祷自己的printk打得够多。
但ftrace不一样。它让你看到内核的执行流。我举个例子：
- 你想知道某个系统调用到底走了哪些内核函数？ftrace可以。
- 你想知道某个函数被调用了多少次？ftrace可以。
- 你想知道中断处理花了多长时间？ftrace也可以。
我在项目中遇到过最典型的场景：一个USB设备拔插时系统卡死。用printk？不行，因为卡死发生在中断上下文，printk可能引发更严重的死锁。用ftrace的irqsoff跟踪器，直接定位到某个驱动在关中断后执行了耗时操作。嗯，问题半小时就找到了。
个人建议：如果你刚开始学内核调试，我建议先从ftrace入手。因为它最简单，最直接，而且不会给你的系统引入额外的依赖。
ftrace与其他工具的对比
很多同学会问：有了perf和systemtap，为什么还要学ftrace？这个问题问得好。我整理了一张对比表，你看完就明白了。
| 特性 | ftrace | perf | systemtap |
|---|---|---|---|
| 安装方式 | 内核内置，无需安装 | 需安装perf工具包 | 需安装systemtap及内核调试符号 |
| 性能开销 | 极低（静态插桩） | 较低（硬件PMU+软件采样） | 较高（动态插桩，需编译脚本） |
| 使用难度 | 低（echo命令即可） | 中（命令行参数较多） | 高（需要学习脚本语言） |
| 适用场景 | 函数调用跟踪、延迟分析 | 性能剖析、CPU事件统计 | 复杂的内核动态分析 |
| 内核版本要求 | 2.6.27+ | 2.6.31+ | 需内核支持kprobes |
看到这里你可能会问：那什么时候用ftrace，什么时候用perf？
我的经验是这样的：
- 查函数调用关系、查延迟、查中断 → 用ftrace。它在这方面是王者。
- 做性能分析、看CPU利用率、看缓存命中率 → 用perf。perf的PMU采样能力是ftrace不具备的。
- 需要写复杂的条件逻辑来跟踪内核 → 用systemtap。但说实话，我现在越来越少用systemtap了，因为ftrace的trace_printk和kprobe_event已经能覆盖大部分需求。
避坑指南：我曾经在生产环境上直接用systemtap的脚本去跟踪调度器，结果脚本有个bug导致内核panic。从那以后，我在生产环境只用ftrace——因为它安全，即使你写错了，最多也就是跟踪不到数据，不会崩系统。
ftrace的工作原理（极简版）
ftrace的核心机制其实不复杂。它在内核函数的入口和出口处插入了「钩子」（mcount/gcc的-pg选项）。当你开启跟踪时，这些钩子会记录函数调用的信息。关闭时，钩子变成一条nop指令，几乎不消耗任何性能。
嗯，这里要注意：ftrace的静态插桩只针对编译时开启了mcount的函数。不过别担心，大部分内核函数都默认开启了。再加上kprobe动态插桩的配合，基本上你想跟踪的函数都能覆盖到。
好了，这一章我们先把ftrace是什么、为什么用它、它和其他工具的区别搞清楚。下一章我会带你亲手操作——挂载debugfs、打开跟踪器、看第一份trace输出。相信我，当你第一次看到内核函数的调用链在终端里刷刷刷地滚出来时，那种感觉，嗯，挺爽的。