1. ftrace 简介：起源、发展历史与核心地位
ftrace（Function Tracer）是 Linux 内核内置的追踪基础设施，自 2.6.27 内核（2008 年）合入主线以来，已成为内核调试与性能分析的事实标准。它允许开发者以极低的开销捕获内核函数调用、调度事件、中断上下文、系统调用以及自定义探针数据，是理解内核行为、定位调度延迟、排查性能瓶颈的核心工具。
一句话定义：ftrace 是一个零外部依赖、内核原生、支持静态与动态插桩的追踪框架，无需加载内核模块即可启用。
1.1 ftrace 的起源
ftrace 最初由 Steven Rostedt 在 2006 年开发，目的是解决实时 Linux（RT-Preempt）项目中调度延迟的测量问题。当时内核缺乏统一的低开销追踪手段，开发者只能依赖 printk 或外部分析仪，这些方法要么开销过高，要么无法捕获内核态函数调用链。
- 2006 年：Steven Rostedt 在 Red Hat 工作期间，为 RT 内核编写了早期的 "latency tracer"，用于记录调度器唤醒延迟。
- 2007 年：该 tracer 被重构为通用框架，更名为 "ftrace"，并增加了函数追踪（function tracer）和函数图追踪（function_graph tracer）能力。
- 2008 年 10 月：Linux 2.6.27 正式合入 ftrace，成为内核主线的一部分。
关键动机：实时内核需要精确测量“中断关闭时间”和“调度延迟”，而当时已有的 LTTng（Linux Trace Toolkit Next Generation）和 SystemTap 需要用户态守护进程或内核模块加载，不适合早期启动阶段的调试。
1.2 发展历史里程碑
| 内核版本 | 发布时间 | 里程碑特性 |
|---|---|---|
| 2.6.27 | 2008-10 | ftrace 首次合入主线，包含 function tracer、function_graph tracer、irqsoff tracer、preemptoff tracer |
| 2.6.28 | 2008-12 | 新增 trace_printk() 接口，允许内核代码直接向 ftrace 缓冲区输出格式化日志 |
| 2.6.30 | 2009-06 | 新增 events 子系统，支持静态 tracepoint 事件追踪 |
| 2.6.33 | 2010-02 | 新增 kprobe 动态探针支持，允许在任意内核指令地址插入追踪点 |
| 3.1 | 2011-10 | 新增 uprobe 用户态探针支持，扩展追踪范围到用户空间 |
| 3.15 | 2014-06 | 新增 hist triggers（直方图触发器），支持在 tracepoint 上做聚合统计 |
| 4.1 | 2015-06 | 新增 function_graph 的深度控制与任务过滤，提升调度追踪精度 |
| 5.1 | 2019-03 | 新增 fgraph（function graph）的 retval 追踪，可捕获函数返回值 |
| 5.10 | 2020-12 | 新增 fprobe（function probe），基于 ftrace 的轻量级动态探针框架 |
| 6.1+ | 2022-12 | 持续优化 ring buffer 性能，支持 per-CPU 缓冲区动态大小调整 |
注意：ftrace 的演进始终围绕“低开销”和“易用性”两个核心目标。从最初的延迟追踪器到现在的多探针框架，它从未依赖过外部工具链，这是其在内核调试领域保持核心地位的关键原因。
1.3 ftrace 在 Linux 内核调试中的核心地位
ftrace 之所以成为内核调试的“瑞士军刀”，是因为它同时满足了以下四个关键需求：
- 零外部依赖：ftrace 随内核发布，无需安装额外的用户态工具或内核模块，在嵌入式、容器、生产环境均可直接使用。
- 极低开销：静态 tracepoint 的开销仅为几条 NOP 指令（动态禁用时），动态函数追踪的开销也远低于 printk 或 kprobe。
- 多维度追踪：支持函数调用、调度事件、中断、系统调用、自定义探针，覆盖内核行为的所有层面。
- 生产环境安全：ftrace 的 ring buffer 设计保证了追踪数据不会阻塞生产路径，且支持动态启用/禁用，无需重启系统。
核心地位体现：在 Linux 内核社区，ftrace 是调度器调试、实时性分析、性能回归测试的首选工具。几乎所有的调度器补丁（CFS、RT、EEVDF）在合入主线前，都会使用 ftrace 验证其行为正确性。
1.4 ftrace 整体架构
下图展示了 ftrace 的核心组件及其数据流关系。从用户态接口到内核追踪点，再到 ring buffer 和 trace data 输出，构成了一个完整的追踪链路。
1.5 ftrace 与同类工具的对比
为了更清晰地理解 ftrace 的定位，下表将其与内核调试领域的其他主流工具进行对比：
| 工具 | 依赖 | 开销 | 追踪粒度 | 生产环境适用 | 调度事件支持 |
|---|---|---|---|---|---|
| ftrace | 无（内核内置） | 极低 | 函数级 / 事件级 | 是 | 原生支持 |
| perf | perf_event_open 系统调用 | 低 | 事件级 / 采样级 | 是 | 通过 tracepoint |
| eBPF | 内核配置 + bpftool | 低 | 程序级 / 事件级 | 是 | 通过 kprobe/tracepoint |
| SystemTap | 需要安装 kernel-debuginfo | 中 | 函数级 / 语句级 | 有限 | 通过脚本 |
| LTTng | 需要加载内核模块 | 低 | 事件级 | 是 | 通过 tracepoint |
| printk | 无 | 高 | 自定义 | 否（影响性能） | 手动添加 |
ftrace 的独特优势：在调度器调试场景中，ftrace 是唯一一个无需任何外部依赖、即可在函数入口/出口处捕获调度器核心函数（如
__schedule、enqueue_task_fair、dequeue_task_fair）的工具。eBPF 虽然功能更强，但需要较新的内核版本和额外的工具链支持。
1.6 本章小结
ftrace 从 2008 年合入主线至今，已从一个简单的延迟追踪器发展为涵盖函数追踪、事件追踪、动态探针、直方图聚合的完整追踪框架。它的核心地位源于：
- 零外部依赖——任何 Linux 系统均可直接使用
- 极低开销——适合生产环境长期开启
- 调度事件原生支持——无需额外配置即可追踪调度器行为
- 持续演进——从 2.6.27 到 6.x，每个版本都在增强能力