2. ftrace架构
ftrace 是 Linux 内核内置的追踪框架，其设计遵循分层与模块化原则。理解 ftrace 的架构是掌握调度器追踪的基础。本章将拆解 ftrace 的三大核心组件：Ring Buffer（环形缓冲区）、Tracer（追踪器）与 Trace Events（追踪事件），并梳理它们之间的数据流关系。
2.1 ftrace 整体框架
ftrace 的架构可以抽象为三层：用户接口层、核心框架层与数据采集层。用户通过 tracefs 文件系统（通常挂载于 /sys/kernel/tracing）与内核交互；核心框架负责管理追踪器与事件注册；数据采集层则负责将追踪数据写入 Ring Buffer。
关键点： ftrace 并非单一功能模块，而是一个可扩展的追踪基础设施。调度器追踪只是其众多应用场景之一。
2.2 Ring Buffer：高性能追踪存储核心
Ring Buffer（环形缓冲区）是 ftrace 的存储基石。它是一个固定大小的、按 CPU 分配的循环缓冲区，用于高效存储追踪数据，避免动态内存分配带来的性能开销。
2.2.1 设计原理
- 每 CPU 缓冲区：每个 CPU 拥有独立的 Ring Buffer，避免多核竞争锁，提升并发写入性能。
- 固定大小：在启动时或通过
buffer_size_kb配置，写入超过容量时覆盖旧数据。 - 原子写入：使用本地原子操作（local_t）管理写指针，保证写入的原子性。
2.2.2 关键数据结构
| 数据结构 | 作用 | 所在文件 |
|---|---|---|
struct ring_buffer | 全局 Ring Buffer 实例，管理所有 CPU 缓冲区 | kernel/trace/ring_buffer.c |
struct ring_buffer_per_cpu | 每 CPU 的缓冲区控制块，包含读写指针、页链表 | kernel/trace/ring_buffer.c |
struct buffer_page | 缓冲区页，实际存储追踪数据的单元 | kernel/trace/ring_buffer.c |
struct trace_array | ftrace 实例，每个实例拥有独立的 Ring Buffer | kernel/trace/trace.h |
2.3 Tracer：追踪行为的执行者
Tracer 是 ftrace 中定义“如何追踪”的组件。每个 Tracer 实现特定的追踪逻辑，例如追踪函数调用、函数调用图或调度延迟。用户通过 current_tracer 文件选择当前激活的 Tracer。
2.3.1 常用 Tracer 一览
| Tracer 名称 | 功能描述 | 典型用途 |
|---|---|---|
function | 追踪内核函数的调用入口与出口 | 函数调用频率分析 |
function_graph | 以缩进图形式显示函数调用链 | 函数调用路径可视化 |
preemptirqsoff | 追踪抢占与中断关闭的最大时间 | 实时性延迟分析 |
wakeup | 追踪高优先级任务的唤醒延迟 | 调度延迟测量 |
nop | 空追踪器，不产生任何追踪数据 | 关闭追踪或仅使用事件 |
提示： 调度器追踪通常不直接使用 Tracer，而是通过 Trace Events 实现。但
wakeup Tracer 是调度延迟分析的经典工具。
2.4 Trace Events：细粒度的追踪探针
Trace Events 是 ftrace 中最灵活、最常用的追踪手段。它们是在内核代码中预定义的静态探针（或通过 kprobe 动态添加），当特定代码路径执行时，事件被触发并写入 Ring Buffer。
2.4.1 事件分类
- 静态 Trace Events：使用
TRACE_EVENT()宏在内核源码中定义，编译时生成。调度器事件（如sched_switch、sched_wakeup）均属此类。 - 动态 Trace Events：通过
kprobe或uprobe在运行时动态创建，无需重新编译内核。
2.4.2 调度器关键事件
| 事件名称 | 触发时机 | 关键字段 |
|---|---|---|
sched_switch | CPU 上下文切换时 | prev_comm, prev_pid, next_comm, next_pid |
sched_wakeup | 任务被唤醒时 | comm, pid, target_cpu, prio |
sched_wakeup_new | 新创建任务首次被唤醒时 | comm, pid, target_cpu |
sched_migrate_task | 任务被迁移到其他 CPU 时 | comm, pid, orig_cpu, dest_cpu |
sched_process_exec | 进程执行 exec 系统调用时 | filename, pid, old_pid |
2.5 数据流图：从事件触发到用户读取
理解 ftrace 的数据流是调试调度器的关键。以下流程图展示了从调度事件触发到用户最终读取追踪结果的完整路径。
2.6 组件协作示例：调度事件追踪
以追踪 sched_switch 事件为例，展示三个组件的协作过程：
- 配置阶段：用户通过
echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable启用事件。 - 触发阶段：内核执行
context_switch()函数时，调用trace_sched_switch()宏。 - 写入阶段：宏展开后，将事件数据（prev_pid、next_pid 等）写入当前 CPU 的 Ring Buffer。
- 读取阶段：用户执行
cat /sys/kernel/tracing/trace，ftrace 从 Ring Buffer 读取数据并格式化为可读文本。
性能考量： Ring Buffer 的写入路径经过高度优化，在典型调度事件触发时，额外开销仅为数百纳秒级别，适合在生产环境进行短时追踪。
2.7 本章小结
- ftrace 架构分为用户接口层、核心框架层和数据采集层。
- Ring Buffer 是高性能的每 CPU 循环缓冲区，是追踪数据的存储核心。
- Tracer 定义追踪行为，Trace Events 提供细粒度的静态或动态探针。
- 调度器追踪主要依赖 Trace Events（如
sched_switch、sched_wakeup）。 - 数据流路径为：事件触发 → TRACE_EVENT 宏 → Filter 检查 → Ring Buffer 写入 → 用户读取。