CONFIG_TRACEPOINTS和CONFIG_FTRACE的作用

要理解linux kernel CONFIG_TRACEPOINTS和CONFIG_FTRACE的作用，需要从内核跟踪框架的分层设计入手——前者是静态跟踪点的基础设施，后者是内核通用跟踪框架的核心。两者结合构成了Linux内核强大调试与性能分析能力的基础。

一、先明确核心概念

内核跟踪（Kernel Tracing）的本质是记录内核或应用程序运行时的关键事件（如函数调用、进程切换、中断触发、内存分配等），用于调试复杂问题、分析性能瓶颈或理解系统行为。

CONFIG_TRACEPOINTS和CONFIG_FTRACE分别对应跟踪体系中的“探针”和“框架”。

二、CONFIG_TRACEPOINTS：静态跟踪点的支持

1. 作用

CONFIG_TRACEPOINTS宏用于启用内核中的“静态跟踪点”（Static Tracepoints）。

静态跟踪点是内核开发者预先在代码中埋下的“标记点”，每个跟踪点包含：

• •

  唯一名称（如sched_switch表示进程切换、ext4_file_write_iter表示EXT4文件写入）；

• •

  上下文信息（如函数参数、进程ID、时间戳等元数据）；

• •

  触发条件（通常是无条件触发，但可通过工具过滤）。

这些跟踪点编译时确定，不会增加运行时开销（除非主动启用跟踪），适合生产环境或低开销场景。

2. 技术细节

静态跟踪点的实现依赖TRACE_EVENT宏：

内核开发者用TRACE_EVENT定义跟踪点的结构（比如事件名称、参数列表），编译时会生成对应的探针函数和数据存储格式。例如：

TRACE_EVENT(sched_switch,TP_PROTO(bool preempt, struct task_struct *prev, struct task_struct *next),TP_ARGS(preempt, prev, next),...
);

这个宏定义了sched_switch跟踪点，用于记录进程切换的前后任务及是否抢占。

3. 如何使用？

静态跟踪点本身不产生数据，需要工具读取：

• •

  perf工具：最常用，比如perf record -e sched_switch采集进程切换事件，perf script解析结果；

• •

  ftrace框架：通过debugfs接口（如/sys/kernel/debug/tracing/events/sched/sched_switch/enable）启用跟踪点；

• •

  第三方工具：如SystemTap、LTTng也可利用静态跟踪点。

三、CONFIG_FTRACE：内核通用跟踪框架

1. 作用

CONFIG_FTRACE宏用于启用内核的“函数跟踪框架”（Function Tracer Framework），这是Linux内核最核心的内置跟踪基础设施。

FTRACE的设计目标是轻量级、灵活、可扩展，提供了：

• •

  跟踪器（Tracers）：不同的跟踪策略（如函数调用跟踪、函数图跟踪、中断跟踪、调度跟踪等）；

• •

  缓冲区管理：内核中环形缓冲区（Ring Buffer）存储跟踪数据，避免磁盘IO影响性能；

• •

  控制接口：通过debugfs（/sys/kernel/debug/tracing/）动态配置跟踪参数（如启用/禁用、过滤事件、设置缓冲区大小）；

• •

  扩展能力：支持静态跟踪点（TRACEPOINTS）、动态探针（kprobes/uprobes）等多种数据源。

2. 核心组件

FTRACE的关键子功能（需配合其他配置启用）：

• •

  CONFIG_FUNCTION_TRACER：跟踪内核函数的调用关系（最基础的跟踪器）；

• •

  CONFIG_FUNCTION_GRAPH_TRACER：跟踪函数的调用图（包括进入/退出函数的时间）；

• •

  CONFIG_IRQSOFF_TRACER：跟踪中断关闭的时长（用于分析实时性瓶颈）；

• •

  CONFIG_SCHED_TRACER：跟踪进程调度事件（依赖TRACEPOINTS中的sched_*系列事件）。

3. 如何使用？

FTRACE的使用方式非常灵活：

• •

  debugfs接口：直接操作文件控制跟踪，比如：

  # 启用函数图跟踪
  echo function_graph > /sys/kernel/debug/tracing/current_tracer
  # 设置过滤条件（只跟踪ext4相关函数）
  echo ext4_* > /sys/kernel/debug/tracing/set_ftrace_filter
  # 开始跟踪
  echo 1 > /sys/kernel/debug/tracing/tracing_on
  # 执行测试操作
  # 停止跟踪并导出数据
  echo 0 > /sys/kernel/debug/tracing/tracing_on
  cat /sys/kernel/debug/tracing/trace > trace.log

• •

  trace-cmd工具：更友好的命令行工具，封装了debugfs的操作（如trace-cmd record -p function_graph）；

• •

  图形化工具：如KernelShark可可视化跟踪数据。

四、两者的关系与区别

维度​	CONFIG_TRACEPOINTS​	CONFIG_FTRACE​
角色​	静态跟踪点的“探针”基础设施	内核跟踪的“框架”（整合数据源、缓冲、控制）
数据源​	内核预定义的静态标记点	支持静态跟踪点、动态探针（kprobes）、函数调用等
开销​	无（未启用跟踪时）	轻量级（环形缓冲区+动态配置）
使用场景​	生产环境低开销跟踪、perf性能剖析	调试内核问题、分析函数调用/调度/中断等

五、应用场景

这两个配置的应用场景包括：

1. 1.

   驱动调试：比如跟踪显示驱动（如DRM/KMS）的函数调用，定位画面撕裂或延迟问题；

2. 2.

   性能优化：用sched_switch跟踪点分析进程调度延迟，或用function_graph跟踪多媒体解码函数的耗时；

3. 3.

   实时性分析：用irqsoff跟踪器找出中断关闭时间过长的代码段，优化实时性能；

4. 4.

   系统稳定性：跟踪USB/HDMI接口的驱动事件，定位偶发的设备断开问题。

总结

• •

  CONFIG_TRACEPOINTS：给内核打“静态标记”，让工具能采集特定事件；

• •

  CONFIG_FTRACE：提供“跟踪引擎”，整合各种数据源（包括静态跟踪点），实现灵活的跟踪与分析。

两者结合，是Linux内核调试与性能优化的“黄金组合”——尤其是在嵌入式系统中，无需额外硬件就能深入分析内核行为，非常实用。

深圳坝光