各位同仁，各位对Linux内核充满好奇的开发者们，大家下午好！
今天，我们将共同深入探索Linux内核的一个强大而又精密的工具——ftrace。我们将聚焦于一个核心议题：ftrace是如何以纳秒级的精度，追踪内核中每一个函数的进入与退出，从而揭示我们程序在内核层面的微观行为和性能瓶颈的。
作为一名编程专家，我深知在复杂的软件系统中，性能问题往往隐藏在最深的角落。当CPU使用率飙升，I/O延迟居高不下，或者系统响应变慢时，我们常常需要一把锋利的“手术刀”来剖析内核的内部运作，找出真正的病灶。ftrace正是这样一把手术刀，它让我们能够以前所未有的粒度，观察内核的“心跳”和“脉搏”。
本次讲座，我将带大家从ftrace的基本概念出发，逐步深入其工作原理，包括编译器如何协作、时间源的选择、环形缓冲区的设计，以及如何通过实际操作来驾驭这个强大的工具。我们将通过丰富的代码示例和严谨的逻辑推导，彻底理解ftrace的奥秘。
一、 引言：窥探内核的微观世界
在现代操作系统中，Linux内核是一个庞大而复杂的实体，承载着从进程调度到内存管理，从文件系统到网络通信等一切核心功能。当应用程序出现性能问题时，我们首先会想到通过perf、strace、oprofile等工具进行分析。然而，这些工具虽然强大，但往往在特定层面上工作：strace侧重于系统调用，perf擅长采样和硬件事件，而oprofile则提供整个系统的热点函数分布。
当我们需要了解某个特定内核函数执行了多久，或者一个函数调用链的详细耗时分布时，上述工具往往显得力不从心。此时，我们需要一种能够“照亮”内核内部函数执行路径，并精确测量其耗时的机制。ftrace正是为满足这一需求而生。
ftrace，全称“Function Tracer”，是Linux内核内置的一个动态追踪框架。它允许我们以极低的开销，在运行时追踪内核函数的调用、返回，甚至是更复杂的事件。它的一个显著特点是能够提供纳秒级的时间精度，这对于分析那些瞬息万变、微秒甚至纳秒级别的内核操作至关重要。
今天的核心目标，就是理解ftrace是如何实现这种惊人的纳秒级精度的，以及它背后的技术原理。
二、 ftrace核心概念与架构
在深入探讨纳秒级计时之前，我们首先需要建立对ftrace的基本理解。
2.1 什么是ftrace？
ftrace是Linux内核的一个内置功能，它提供了一个强大的基础设施，用于在内核运行时探测和追踪各种事件，其中最常用和最强大的就是函数追踪。它不像一些外部工具那样需要特殊的内核模块加载，而是直接集成在内核中，这意味着它拥有对内核内部状态的最高权限和最低开销的访问能力。
ftrace的接口通常通过一个名为tracefs（旧版本内核可能挂载在debugfs下）的伪文件系统暴露给用户空间。用户可以通过简单的文件操作（echo写入配置，cat读取结果）来控制追踪行为和获取追踪数据。
2.2 ftrace的运作原理概览
ftrace的工作原理可以概括为以下几个关键步骤：
- 编译器插桩 (Instrumentation)：在编译内核时，特定的编译选项会指示GCC在每个函数入口处插入一个特殊的调用指令。这个指令最初指向一个通用的“存根”函数（
ftrace_stub）。 - 动态重定向 (Dynamic Redirection)：当
ftrace被启用并配置为追踪函数时，内核会在运行时修改这些被编译器插入的调用指令。它会将这些指令的目标地址从ftrace_stub动态地重定向到实际的追踪处理函数。 - 事件记录 (Event Recording)：当一个被追踪的函数被调用时，控制流会经过被重定向的指令，跳转到
ftrace的追踪处理函数。在这个处理函数中，ftrace会记录下相关的事件信息，如函数地址、调用者、时间戳等，并将其存储在一个高性能的内核环形缓冲区中。 - 数据读取 (Data Retrieval)：用户空间程序可以通过
tracefs提供的接口（如trace_pipe或trace文件）读取环形缓冲区中的数据，进行分析。
这个过程的关键在于“动态重定向”，它使得ftrace能够在运行时灵活地开启或关闭对特定函数的追踪，而无需重新编译内核。
2.3 tracefs文件系统
tracefs是用户空间与ftrace交互的主要途径。它通常挂载在/sys/kernel/tracing/路径下。以下是其一些关键文件和目录：
| 文件/目录名 | 描述 |
|---|---|
tracing_on |
控制ftrace全局开关。写入1开启，写入0关闭。 |
current_tracer |
设置或显示当前使用的追踪器。例如，function、function_graph。 |
trace |
包含环形缓冲区中所有事件的文本表示。读取此文件会清空缓冲区。 |
trace_pipe |
提供一个实时流式输出接口。读取此文件不会清空缓冲区。 |
trace_options |
配置各种追踪选项，如latency-format、sleep-time等。 |
set_ftrace_filter |
指定要追踪的函数列表，支持通配符。 |
set_ftrace_notrace |
指定要排除追踪的函数列表，支持通配符。 |
set_ftrace_pid |
指定只追踪特定PID的进程。 |
set_graph_function |
function_graph追踪器专用，指定要构建调用图的根函数。 |
max_graph_depth |
function_graph追踪器专用，设置最大调用深度。 |
buffer_size_kb |
控制每个CPU追踪环形缓冲区的大小（单位KB）。 |
events/ |
包含各种事件追踪子系统，如syscalls、sched等。 |
通过对这些文件的操作，我们就能完全控制ftrace的行为。
三、 函数追踪的基石：编译器与内核的协作
要实现纳秒级的函数进入/退出追踪，首先要解决的问题是如何在不修改内核源代码的情况下，在每个函数入口和出口植入探测点。这需要编译器和内核的紧密协作。
3.1 函数入口点的魔法：-pg与-mfentry
在传统的性能分析中，GCC的-pg选项用于生成gprof所需的分析数据。它会在每个函数的入口处插入对mcount函数的调用。ftrace正是借鉴了这一思想，并对其进行了优化和扩展。
现代Linux内核编译时，通常会使用GCC的-mfentry选项。这个选项比-pg更直接，它会在每个函数（不包括被__attribute__((no_instrument_function))标记的函数）的起始位置插入一个对__fentry__（或直接是fentry）函数的调用。
// 伪代码：编译器插桩后的函数结构
void my_function(void) {
// 编译器在这里插入一条对__fentry__的调用
call __fentry__
// 原始函数体开始
// ...
// 原始函数体结束
}最初，这个__fentry__（或fentry）函数是一个非常简单的存根，例如ftrace_stub。它的作用是作为一个占位符，等待ftrace在运行时对其进行“改造”。
3.2 ftrace探测点的动态调整：Trampolines
当ftrace被启用并配置为追踪函数时，内核不会直接修改每个函数的机器码。相反，它利用了一种叫做“跳板”（Trampoline）或“蹦床”的机制。
具体来说，内核会：
- 识别目标地址：找到所有被
-mfentry插入的call __fentry__指令。 - 修改指令：将
call __fentry__指令中的目标地址从ftrace_stub（或__fentry__的原始地址）修改为指向ftrace真正的追踪处理函数（例如，对于functiontracer是ftrace_caller，对于function_graphtracer是ftrace_graph_caller）。 - 恢复与追踪：当追踪停止时，内核会将这些指令的目标地址改回
ftrace_stub，从而禁用追踪，将开销降到最低。
这种动态修改指令的技术被称为“ftrace call-site patching”。它允许在运行时开启和关闭追踪，而无需重启系统。
3.3 内核配置选项
要使ftrace的函数追踪功能可用，内核需要启用以下配置选项：
CONFIG_FTRACE: 启用ftrace框架本身。CONFIG_FUNCTION_TRACER: 启用function追踪器，用于追踪函数入口。CONFIG_FUNCTION_GRAPH_TRACER: 启用function_graph追踪器，用于追踪函数调用图（入口和出口），并计算函数耗时。
这些选项通常在内核的.config文件中可以看到。如果你的系统没有这些选项，则无法使用相应的ftrace功能。
四、 纳秒级计时：精确度何来？
现在，我们来到了本次讲座的核心——ftrace如何实现纳秒级的时间精度。要理解这一点，我们需要深入了解Linux内核的时间管理机制。
4.1 时间源的选择
Linux内核为了提供精确的时间服务，会根据不同的需求和硬件平台选择不同的时间源。对于高性能追踪，最重要的时间源是：
-
TSC (Timestamp Counter)
- 原理：
TSC是大多数现代x86处理器内置的一个64位计数器，它以CPU主频或固定频率递增。每次读取TSC（通过RDTSC或RDTSCP指令）都能获得一个非常精确的、CPU本地的时间戳。 - 精度：纳秒甚至皮秒级（理论上取决于CPU频率）。
- 优点：读取开销极低，通常只需要几个CPU周期。
- 挑战：
- 同步问题：多核CPU上的
TSC可能不同步，尤其是在没有constant_tsc和nonstop_tsc特性的旧硬件上。 - 频率变化：如果CPU频率动态调整（如通过SpeedStep、Turbo Boost），
TSC的频率可能不稳定。 - 虚拟化：在虚拟机中，
TSC可能被虚拟化，导致不准确。
- 同步问题：多核CPU上的
- 内核处理：Linux内核会尽力检测
TSC的特性，并在无法保证其稳定性和同步性时，回退到其他时间源。如果TSC被认为是可靠的（constant_tsc和nonstop_tsc），它将是内核高精度时间的首选。
- 原理：
-
ktime_get()- 原理：这是一个内核API，它封装了获取当前高精度时间的最佳方式。
ktime_get()会根据系统配置和硬件能力，智能地选择底层的时间源。在大多数现代系统中，如果TSC可靠，ktime_get()会使用TSC作为其主要时间源。否则，它可能会使用高精度事件定时器（HPET）、ACPI PM Timer或其他硬件定时器。 - 精度：通常是纳秒级，取决于底层时间源。
- 优点：开发者无需关心底层细节，直接使用即可获得尽可能高的精度。
- 原理：这是一个内核API，它封装了获取当前高精度时间的最佳方式。
-
CLOCK_MONOTONIC- 原理：这是一个单调递增的时间，表示系统启动以来的时间量，不受系统时间调整（如NTP同步或手动修改系统时间）的影响。
- 精度：通常是纳秒级。
- 用途：非常适合测量时间间隔和持续时间，因为它是单调的。
ftrace中的时间戳通常就是基于CLOCK_MONOTONIC或其内核对应物。
-
CLOCK_REALTIME- 原理：这是我们通常所说的“墙上时间”，即自Epoch（1970-01-01 00:00:00 UTC）以来的时间。它受系统时间调整的影响。
- 精度：通常是微秒或纳秒级。
- 用途：不适合测量持续时间，因为其非单调性可能导致测量误差，但在需要与外部事件关联时有用。
4.2 ftrace如何利用这些时间源
ftrace的核心时间戳机制是基于ktime_get()。当ftrace的追踪处理函数被调用时，它会立刻调用ktime_get()来获取当前的纳秒级时间戳。这个时间戳被记录下来，与函数地址、PID等信息一起存入环形缓冲区。
对于function_graph追踪器，它不仅在函数入口记录时间戳，还在函数出口处记录另一个时间戳。通过这两个时间戳的差值，就可以精确计算出函数从进入到退出的纳秒级耗时。
ktime_get()在底层会优先使用可靠的TSC。如果TSC不可靠，内核会使用其他高精度定时器。这种设计确保了ftrace在各种硬件环境下都能提供尽可能高的计时精度。
4.3 精度与开销的权衡
虽然TSC的读取开销非常低，但每次函数调用都要：
- 执行
call __fentry__指令。 - 跳转到
ftrace处理函数。 - 在
ftrace处理函数中读取时间戳 (ktime_get())。 - 将事件数据写入环形缓冲区。
- 返回到原始函数体。
这些操作都会引入额外的CPU周期和内存带宽消耗，这就是追踪的“开销”。即使是纳秒级的操作，在高速运行的内核中，如果追踪的函数非常频繁，累积的开销也可能变得显著。因此，在使用ftrace时，我们需要权衡追踪的精度和对系统性能的影响。
五、 实践ftrace：函数追踪器
理论知识固然重要，但掌握ftrace的关键在于实践。我们将重点介绍两个最常用的函数追踪器：function和function_graph。
5.1 function tracer
function tracer是最简单的函数追踪器，它只记录每个函数的进入事件。当你只想知道某个函数是否被调用，或者一个函数调用序列时，它非常有用。
启用function tracer的步骤：
-
切换到
tracefs目录：cd /sys/kernel/tracing/或者
/sys/kernel/debug/tracing/(旧内核) -
清空之前的追踪数据：
echo > trace这一步非常重要，可以确保你看到的是最新的追踪数据。
-
选择
function追踪器：echo function > current_tracer -
设置过滤器（可选但推荐）：
如果你不设置过滤器，ftrace会追踪所有内核函数，这会产生海量数据。通常我们会指定感兴趣的函数。例如，追踪所有与schedule相关的函数：echo '*schedule*' > set_ftrace_filter # 或者追踪特定函数，例如： # echo sys_write > set_ftrace_filter -
开启追踪：
echo 1 > tracing_on -
执行目标操作：
现在，执行你想要分析的应用程序或系统操作。 -
关闭追踪：
echo 0 > tracing_on -
读取追踪数据：
cat trace -
清理追踪器和过滤器：
echo nop > current_tracer echo > set_ftrace_filter将
current_tracer设置回nop（no operation）可以禁用所有追踪器，并释放相关资源。清空set_ftrace_filter可以移除所有过滤器。
function tracer输出示例：
# tracer: function
#
# entries-in-buffer/entries-written: 10478/10478 #P:4
#
# _-----=> irq-enable
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# R |||| duration
# B ||||| [ stack trace ]
# P |||||
# C ||||| TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# - ||||| -------- ---- ||||| --------- --------
<idle>-0 [000] d...1 12345.678901: __raw_spin_unlock_irqrestore <-try_to_wake_up
<idle>-0 [000] d...1 12345.678912: _raw_spin_unlock_irqrestore <-try_to_wake_up
<idle>-0 [000] d...1 12345.678923: __raw_spin_unlock_irqrestore <-try_to_wake_up
systemd-1 [001] d...1 12345.679000: sys_write <-ksys_write
systemd-1 [001] d...1 12345.679005: ksys_write <-__x64_sys_write
systemd-1 [001] d...1 12345.679010: __x64_sys_write <-entry_SYSCALL_64_after_hwframe输出的每一行代表一个函数被调用的事件。字段包括：
TASK-PID: 进程名和PID。CPU#: 发生事件的CPU核心ID。flags: 一系列标志位，如irq-enable、need-resched、hardirq/softirq、preempt-depth等，用于表示内核状态。TIMESTAMP: 事件发生时的相对时间戳，单位是微秒，但精度可以到纳秒（小数点后6位以上）。FUNCTION: 被调用的函数名，后面跟着其调用者（<-caller）。
5.2 function_graph tracer
function_graph tracer是ftrace中最强大的函数追踪器之一。它不仅记录函数入口，还记录函数出口，并能自动计算每个函数的执行时间。它以树状结构（通过缩进）展示函数调用链，非常直观。
启用function_graph tracer的步骤：
-
切换到
tracefs目录：cd /sys/kernel/tracing/ -
清空之前的追踪数据：
echo > trace -
选择
function_graph追踪器：echo function_graph > current_tracer -
设置过滤器（非常推荐）：
function_graph追踪的开销相对较大，如果不设置过滤器，可能会导致系统卡顿，并迅速填满缓冲区。通常，我们会指定一个或几个核心函数作为追踪的起点。echo vfs_read > set_graph_function # 或者同时过滤普通函数 # echo '*vfs*' > set_ftrace_filter注意：
set_graph_function与set_ftrace_filter可以一起使用。set_graph_function指定了当追踪器检测到这个函数时，才开始记录它及其内部所有被追踪函数的调用图。 -
设置最大调用深度（可选）：
echo 5 > max_graph_depth这可以限制追踪的深度，避免过长的调用链导致数据过于庞大。
-
开启追踪：
echo 1 > tracing_on -
执行目标操作。
-
关闭追踪：
echo 0 > tracing_on -
读取追踪数据：
cat trace -
清理追踪器和过滤器：
echo nop > current_tracer echo > set_graph_function echo > set_ftrace_filter
function_graph tracer输出示例：
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |
0) | do_sys_open() {
0) | path_openat() {
0) | do_filp_open() {
0) | vfs_open() {
0) | do_dentry_open() {
0) | try_module_get() {
0) 0.201 us | try_module_get();
0) 0.457 us | }
0) 0.985 us | }
0) 1.234 us | }
0) 1.567 us | }
0) 1.890 us | }
0) 2.100 us | }
0) 2.345 us |__x64_sys_openat() {
0) 2.567 us | do_sys_open();
0) 2.789 us | }注意：上述示例中的时间是微秒（us），但实际内部存储和计算是纳秒。ftrace的输出格式会根据trace_options中的latency-format等选项进行调整。当latency-format启用时，持续时间会以us或ms显示，但内部精度仍是纳秒。
六、 深入解析function_graph追踪数据
function_graph的输出是理解函数调用流和耗时的关键。让我们详细解析其字段：
6.1 输出格式详解
每一行function_graph的输出都提供了一系列信息：
CPU ID:0)或1)等，表示事件发生在哪个CPU核心上。函数调用深度: 通过前导的空格或|符号的缩进程度来表示。每个缩进级别代表函数调用栈中的一层。ftrace会尝试准确地显示函数调用和返回的配对。函数名: 被调用或返回的函数名称。{或}:{表示函数入口点。}表示函数出口点。
持续时间: 当函数返回时（即行尾为}），会在行首显示该函数从入口到出口的总执行时间。这个时间以纳秒或微秒为单位（如<123.456 us>或<123456 ns>），是ftrace通过比较函数入口和出口的时间戳计算得出的。
6.2 案例分析：一个简单的函数调用链
假设我们追踪了内核中一个典型的文件操作：sys_read。其调用链可能如下：
__x64_sys_read
|-- ksys_read
|-- vfs_read
|-- __vfs_read
|-- kernel_read
|-- file->f_op->read() (实际文件系统的读操作)使用function_graph追踪__x64_sys_read，我们可能得到类似如下的输出：
0) | __x64_sys_read() {
0) | ksys_read() {
0) | vfs_read() {
0) | __vfs_read() {
0) | kernel_read() {
0) | ext4_file_read_iter() {
0) 12.345 us | ext4_file_read_iter();
0) 12.500 us | }
0) 12.789 us | }
0) 13.000 us | }
0) 13.234 us | }
0) 13.456 us | }
0) 13.678 us | }从这个输出中，我们可以清晰地看到：
__x64_sys_read是最顶层的系统调用。- 它依次调用了
ksys_read、vfs_read、__vfs_read、kernel_read，直到最终调用到具体文件系统的读操作ext4_file_read_iter。 ext4_file_read_iter函数执行了12.345 us。- 当
ext4_file_read_iter返回后，控制流回到kernel_read，然后继续返回。 - 每一行的
}都标记了一个函数的返回，并且前面会显示该函数的总执行时间。
通过这种方式，我们不仅能看到函数的调用关系，还能精确地测量每个子函数在其父函数中的耗时，从而找出调用链中的性能瓶颈。
6.3 function_graph输出字段解释表格
为了更清晰地理解，我们用表格总结一下function_graph输出的关键字段：
| 字段 | 描述 | 示例 |
|---|---|---|
CPU ID |
发生事件的CPU核心ID。 | 0) |
函数调用深度 |
通过前导的空格或|符号表示，每个|代表一层调用深度。ftrace会尽量使{和}配对，以形成完整的调用图。 |
| do_sys_open() |
函数名 |
被调用或返回的函数名称。 | do_sys_open |
{ 或 } |
{ 表示函数入口；} 表示函数出口。 |
{ 或 } |
持续时间 |
仅在函数返回时（}行）显示。表示该函数从入口到出口的总执行时间。默认以微秒（us）或毫秒（ms）显示，但底层精度是纳秒。 |
12.345 us |
PID (可选) |
如果启用了trace_pid选项，或者在trace文件的头部，会显示进程ID。但对于function_graph的主体部分，通常不直接显示PID，而是通过trace的头部信息或trace-cmd工具来关联。 |
(通常不在每行显示) |
时间戳 (可选) |
如果启用了trace_timestamp选项，或者通过trace-cmd等工具解析，可以显示每个事件的绝对或相对时间戳。在原始function_graph输出中，持续时间已足以进行分析。 |
(通常不在每行显示，而是通过持续时间计算) |
七、 ftrace的内部机制：环形缓冲区
所有追踪到的事件数据都需要一个高效的存储机制，这就是ftrace环形缓冲区（Ring Buffer）的作用。
7.1 设计理念
ftrace环形缓冲区的设计目标是：
- 低开销写入：最大程度地减少追踪事件对系统性能的影响。
- 无锁或低锁竞争：在多核系统中，避免因为锁竞争导致性能瓶颈。
- 实时性：能够快速记录瞬时事件。
- 有限内存占用：通过环形结构，在固定大小的内存中循环使用。
7.2 数据结构
ftrace的环形缓冲区是每个CPU独立的。这意味着每个CPU核心都有自己的一个专属缓冲区，当一个CPU上的函数被追踪时，它会将数据写入到自己的缓冲区中，而不需要获取全局锁，从而大大减少了锁竞争，提高了并行写入的效率。
每个事件在缓冲区中都包含一个事件头（ftrace_event_call）和实际的事件数据。事件数据包括：
- 时间戳：纳秒级，通过
ktime_get()获取。 - 函数地址：被追踪函数的地址。
- 调用者地址：调用该函数的地址。
- PID：发生事件的进程ID。
- CPU ID：发生事件的CPU ID。
- 其他上下文信息：如中断状态、调度器信息等。
7.3 读取机制
用户空间可以通过两种主要方式读取环形缓冲区的数据：
-
trace文件：- 读取
cat /sys/kernel/tracing/trace会获取环形缓冲区中所有已记录的事件，并以格式化的文本形式输出。 - 重要提示：每次读取
trace文件都会清空缓冲区。这意味着如果你想保存数据，需要一次性读出并重定向到文件。
- 读取
-
trace_pipe文件：- 读取
cat /sys/kernel/tracing/trace_pipe会以流式方式实时获取新的追踪事件。 - 重要提示：读取
trace_pipe不会清空缓冲区。这使得它非常适合用于实时监控，或者与其他工具（如less、grep）结合使用。
- 读取
7.4 内存管理
环形缓冲区的大小是可配置的。通过修改/sys/kernel/tracing/buffer_size_kb文件，可以调整每个CPU的缓冲区大小（单位是KB）。
# 查看当前每个CPU的缓冲区大小
cat /sys/kernel/tracing/buffer_size_kb
# 设置每个CPU的缓冲区大小为10MB
echo 10240 > /sys/kernel/tracing/buffer_size_kb更大的缓冲区可以存储更多的事件数据，但也会占用更多的内核内存。需要根据实际需求进行权衡。
八、 过滤与控制：精确定位问题
在真实世界中，内核函数调用是海量的。如果不加过滤，ftrace会迅速填满缓冲区，并产生难以分析的数据。因此，ftrace提供了强大的过滤机制来精确定位我们感兴趣的事件。
8.1 函数过滤
-
set_ftrace_filter:
用于指定一个或多个要追踪的函数名称。只有列表中存在的函数才会被追踪。# 追踪单个函数 echo sys_read > set_ftrace_filter # 追踪多个函数（空格分隔，或多次echo） echo 'sys_read sys_write' > set_ftrace_filter # 追踪带通配符的函数（例如，所有以vfs_开头的函数） echo 'vfs_*' > set_ftrace_filter # 清空过滤器 echo > set_ftrace_filter -
set_ftrace_notrace:
与set_ftrace_filter相反，它用于指定一个或多个要排除追踪的函数。这些函数即使在set_ftrace_filter中，也会被忽略。# 排除追踪特定函数 echo do_idle > set_ftrace_notrace # 清空排除过滤器 echo > set_ftrace_notrace当
set_ftrace_filter和set_ftrace_notrace都设置时，set_ftrace_notrace的优先级更高。
8.2 PID过滤
set_ftrace_pid允许你指定只追踪特定进程（通过PID）产生的内核事件。这对于分析单个应用程序的内核行为非常有用。
# 追踪PID为1234的进程
echo 1234 > set_ftrace_pid
# 追踪多个PID
echo '1234 5678' > set_ftrace_pid
# 清空PID过滤器
echo > set_ftrace_pid结合set_ftrace_filter和set_ftrace_pid，你可以非常精确地定位到某个特定进程中特定函数的行为。
8.3 栈深度限制 (max_graph_depth)
对于function_graph tracer，如果函数调用链非常深，输出可能会变得难以阅读。max_graph_depth文件允许你限制追踪的函数调用深度。
# 设置最大追踪深度为5
echo 5 > max_graph_depth
# 重置为默认（无限制）
echo 0 > max_graph_depth8.4 代码示例：高级过滤
假设我们想追踪进程nginx（PID为12345）中所有ext4文件系统相关的函数调用，并且我们只对vfs_read的调用图感兴趣，深度不超过7层。
#!/bin/bash
TRACING_DIR=/sys/kernel/tracing
# 1. 进入追踪目录
cd $TRACING_DIR
# 2. 确保tracing_on是关闭的，并清空缓冲区
echo 0 > tracing_on
echo > trace
# 3. 设置追踪器为function_graph
echo function_graph > current_tracer
# 4. 设置PID过滤器为nginx的PID (假设为12345)
echo 12345 > set_ftrace_pid
# 5. 设置函数过滤器，追踪所有ext4相关的函数
echo 'ext4_*' > set_ftrace_filter
# 6. 设置graph_function，只在vfs_read被调用时开始记录调用图
echo vfs_read > set_graph_function
# 7. 设置最大调用深度
echo 7 > max_graph_depth
# 8. 开启追踪
echo 1 > tracing_on
echo "Tracing started for PID 12345 (nginx) on ext4 functions via vfs_read, depth 7."
echo "Press Enter to stop tracing..."
read
# 9. 关闭追踪
echo 0 > tracing_on
# 10. 读取追踪结果并保存到文件
cat trace > /tmp/nginx_ext4_vfs_read_trace.txt
echo "Trace saved to /tmp/nginx_ext4_vfs_read_trace.txt"
# 11. 清理所有过滤器和追踪器
echo > set_ftrace_pid
echo > set_ftrace_filter
echo > set_graph_function
echo 0 > max_graph_depth
echo nop > current_tracer
echo "Ftrace cleaned up."这段脚本演示了如何组合使用多种过滤和控制选项，实现非常精细化的追踪。
九、 ftrace的局限性与性能考量
尽管ftrace功能强大，但它并非没有局限性，并且在使用时需要考虑其对系统性能的影响。
9.1 追踪开销
- 指令开销：每次被追踪的函数被调用时，都会额外执行
call __fentry__指令，然后跳转到ftrace处理函数，再执行时间戳读取和环形缓冲区写入操作。这些额外的CPU周期会增加函数的实际执行时间。 - 内存带宽开销：大量事件写入环形缓冲区会消耗内存带宽。
- 缓存影响：追踪代码和数据会占用CPU缓存，可能导致原始工作负载的缓存命中率下降。
- 实时性影响：在高度实时的系统中，即使是微小的额外开销也可能导致任务错过截止时间。
因此，在生产环境或性能敏感的场景下，应谨慎使用ftrace，并尽量通过过滤器缩小追踪范围。
9.2 数据量巨大
内核中每秒钟有数百万甚至数千万次的函数调用。如果不加过滤地追踪所有函数，环形缓冲区会瞬间被填满，数据量将是天文数字，难以人工分析。这也是为什么过滤机制如此重要的原因。
9.3 不是万能药
- 仅限内核：
ftrace只能追踪内核代码，无法直接追踪用户空间应用程序的函数调用（尽管可以通过追踪系统调用来间接了解用户空间行为）。 - 编译器限制：
ftrace依赖于编译器在函数入口处插入探测点。对于未被插桩的内核代码（例如，某些汇编函数），ftrace无法追踪。 - 非侵入性有限：虽然是动态追踪，但它毕竟在运行时修改了内核的执行路径，仍有微小的侵入性。
十、 更高级的工具链与可视化
手动操作tracefs文件对于简单的追踪任务尚可，但对于复杂的分析场景，我们需要更强大的工具。
10.1 trace-cmd
trace-cmd是ftrace的命令行前端，它极大地简化了ftrace的使用。它提供了更友好的命令行接口来配置追踪、启动/停止、保存数据以及生成报告。
trace-cmd的优势：
- 简化操作：无需手动操作
tracefs文件，一条命令即可完成复杂的配置。 - 数据管理：可以将追踪数据保存为二进制文件（
.dat），便于后续分析和共享。 - 报告生成：可以生成各种统计报告，如函数调用频率、耗时分布等。
基本用法示例：
# 记录所有系统调用的事件
trace-cmd record -e syscalls -o /tmp/syscall_trace.dat
# 记录特定PID的function_graph
trace-cmd record -p function_graph -f vfs_read -F 'PID == 12345' -o /tmp/nginx_read.dat
# 查看记录的数据
trace-cmd report /tmp/nginx_read.dat10.2 kernelshark
kernelshark是trace-cmd的图形化前端，它提供了一个直观的用户界面来可视化ftrace数据。
kernelshark的优势：
- 时间轴视图：以时间轴的形式展示所有事件，包括函数调用、中断、调度事件等，便于观察事件的时序关系。
- 函数调用图：可以图形化地展示
function_graph追踪到的函数调用链，以及每个函数的耗时，非常直观。 - 过滤和搜索：提供强大的图形化过滤和搜索功能。
通过trace-cmd记录数据，然后使用kernelshark进行可视化分析，是使用ftrace进行深度性能分析的常见工作流。
10.3 Perf与ftrace的关系
Perf（Linux Performance Events）是Linux内核另一个非常重要的性能分析工具。perf可以利用CPU的性能监控单元（PMU）来采集硬件事件，也可以进行基于采样的堆栈分析。
ftrace与perf并非互斥，而是互补的：
perf可以利用ftrace作为其事件源之一，例如，perf probe可以动态地在ftrace支持的函数入口/出口插入探测点。ftrace提供的是精确的事件流，记录每一个被追踪事件的发生，非常适合分析特定代码路径的精确耗时。perf更擅长统计性分析，通过采样来发现热点函数，适合于大规模、长时间的性能监控。
结合使用这两个工具，可以从不同层面、不同粒度对内核行为进行全面分析。
十一、 洞悉内核，优化未来
通过今天的讲座，我们深入探讨了ftrace这个Linux内核的“透视镜”。我们理解了它如何借助编译器插桩、动态重定向以及高性能环形缓冲区，实现了对内核函数进入与退出的纳秒级精确追踪。我们学习了function和function_graph追踪器的实际操作，以及如何利用强大的过滤机制来精确定位问题。
ftrace不仅仅是一个调试工具，更是我们理解内核行为、发现性能瓶颈、优化系统响应的强大武器。掌握它，就如同获得了透视内核运行细节的能力。随着eBPF等更新技术的不断发展，与ftrace的结合也将为未来的系统观测和性能分析带来更多可能性。希望今天的分享能帮助大家更好地驾驭这个工具，从而写出更高效、更健壮的系统级代码。
感谢各位的聆听！