3. ftrace 架构与原理

ftrace（Function Tracer）是 Linux 内核内置的跟踪框架，专为低开销、高精度的运行时分析而设计。理解其架构与核心机制，是进行内核裁剪与故障排查的基础。本章将深入剖析 ftrace 的整体架构、ring buffer 原理以及两种核心 tracer 的工作机制。

3.1 ftrace 整体架构

ftrace 采用分层设计，从上到下依次为：用户空间接口、核心框架层、数据收集层与硬件/内核层。这种分层结构保证了灵活性与可扩展性。

3.2 Ring Buffer 原理

Ring Buffer（环形缓冲区）是 ftrace 性能的基石。它是一个固定大小的循环内存区域，采用无锁（lockless）设计，支持多生产者（多个 CPU 核心）与单消费者（用户态读取）的高效并发写入。

3.2.1 核心数据结构

3.2.2 写入与读取流程

1. 写入（Producer）： 内核事件发生时，tracer 在当前 CPU 的 ring buffer 中预留空间，写入事件数据，然后更新 commit 指针。
2. 读取（Consumer）： 用户态读取 trace 文件时，内核将每个 CPU 的 reader page 与 commit page 原子交换，然后从 reader page 中拷贝数据到用户空间。
3. 覆盖策略： 当缓冲区满时，新事件会覆盖最旧的事件（overwrite mode），保证始终保留最新数据。

3.3 Function Tracer 工作机制

Function Tracer 是 ftrace 最基础的 tracer，用于跟踪内核函数的调用。它通过编译器在函数入口处插入的 mcount（或 fentry）指令来实现动态插桩。

3.3.1 工作流程

1. 编译阶段： 内核编译时，所有函数入口被插入 mcount 调用（通过 -pg 选项）。
2. 启动阶段： 内核初始化时，ftrace 将所有 mcount 替换为 nop 指令，实现零开销。
3. 激活阶段： 用户写入 current_tracer 为 function 时，ftrace 将匹配函数的 nop 动态替换为跳转到跟踪回调的指令。
4. 执行阶段： 每次调用被跟踪函数时，先执行回调，记录函数地址、时间戳、进程信息等到 ring buffer，然后继续执行原函数。

3.3.2 过滤机制

3.4 Function Graph Tracer 工作机制

Function Graph Tracer 在 Function Tracer 的基础上增加了函数返回跟踪能力，能够记录函数的调用深度、执行时间以及调用链，是性能分析中最常用的 tracer 之一。

3.4.1 核心原理

Function Graph Tracer 在函数入口和出口各插入一个回调：

• 入口回调（trace_graph_entry）： 记录函数开始时间、调用深度，并压入当前函数的返回地址到影子栈（shadow stack）。
• 出口回调（trace_graph_return）： 从影子栈弹出返回地址，计算函数执行耗时，记录函数结束事件。

3.4.2 输出格式解读

典型的 Function Graph Tracer 输出如下：

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)   0.125 us    |        sys_open();
 0)   0.080 us    |          do_sys_open();
 0)   0.050 us    |            do_filp_open();
 0)   0.020 us    |              path_openat();
 0)               |              } /* path_openat */
 0)   0.110 us    |            } /* do_filp_open */
 0)   0.210 us    |          } /* do_sys_open */
 0)   0.450 us    |        } /* sys_open */