Linux 内核 Tracepoints 与 ftrace 深度实战：从静态探针到生产级延迟诊断

2.3 写入路径的无锁协议

// 简化的写入流程
1. reserve_page(page)
   - 获取 per_cpu buffer 的 write pointer
   - 如果当前页剩余空间不足 → 切换到下一个 page（head page）
   - cmpxchg 原子推进 write pointer

2. write_event(page, event)
   - 将事件头和 data 写入 page->data[offset]
   - 如果数据跨页 → 会自动 split

3. commit_page(page)
   - 使用 smp_wmb() 保证写入可见
   - commit += event_size
   - 此时事件对 reader 可见

4. 检查是否需要唤醒 reader（poll_wait 机制）

2.4 快照机制与 Instant Trace

Ring buffer 支持两种特殊模式：

• Snapshot 模式：缓冲区回绕时，保留 N 秒前的数据（通过 SWAP 到 snap buffer）
• Max latency 追踪：只记录最大延迟事件，丢弃常规数据

// 使用示例：通过 tracefs 启用 snapshot
echo 1 > /sys/kernel/debug/tracing/trace_options/snapshot
echo 1000000 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/tracing_on
# ... 模拟压力测试 ...
echo 0 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/snapshot > /tmp/crash.dump

三、ftrace 函数追踪器：从 mcount 到函数图谱

3.1 ftrace 的三层架构

+--------------------------------------------------+
|             用户接口层 (tracefs)                    |
|  trace_options, set_ftrace_filter, function_profile |
+--------------------------------------------------+
|             调度层 (ftrace.c)                       |
|  register_ftrace_function(), ftrace_run_update_code  |
+--------------------------------------------------+
|            指令修改层 (arch specific)                 |
|  x86: ftrace_make_nop / ftrace_make_call            |
|  ARM64: aarch64_insn_gen_branch_imm                 |
+--------------------------------------------------+

3.2 函数入口热补丁机制

当内核启用 -pg 或 -mfentry 编译选项时，每个函数入口都有一条 NOP 指令：

// x86_64 下的典型函数入口（~5字节 NOP）
push   %rbp
mov    %rsp,%rbp
nop    nop    nop    nop    nop    # &__ftrace_call 注入点

启用函数追踪时，该 NOP 被动态替换为 <ftrace_caller>：

// ftrace_caller 伪代码
ftrace_caller:
    push   %rdi          # 保存第一个参数（用于探针）
    push   %rsi
    push   %rdx
    push   %rcx
    push   %r8
    push   %r9
    mov    RIP_AFTER_CALL,%rdi  # 当前函数地址
    mov    PARENT_IP,%rsi       # 调用方返回地址
    call   ftrace_ops_list_func  # 遍历所有注册的 ops
    # 恢复寄存器和执行原始代码
    pop    %r9
    ...
    ret

3.3 函数图谱追踪（Function Graph Tracer）

Function Graph Tracer 不仅追踪函数是否被调用，还能记录函数调用栈和时间戳：

// 启用 function_graph 追踪器
echo function_graph > /sys/kernel/debug/tracing/current_tracer
echo do_sys_openat2 > /sys/kernel/debug/tracing/set_graph_function
echo 1 > /sys/kernel/debug/tracing/tracing_on

# 输出示例（trace 文件）
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)               |  do_sys_openat2() {
 0)   1.234 us    |    getname();
 0)   0.876 us    |    alloc_fd();
 0) + 12.456 us   |    do_filp_open();
 0) + 14.567 us   |  }

3.4 ftrace 的 filter 机制

ftrace 支持通配符过滤和正则匹配来减少追踪开销：

# 只追踪 scsi_ 开头的函数
echo 'scsi_*' > set_ftrace_filter

# 只追踪不在 net_ 中的函数 (NOTRACE)
echo 'net_*' > set_ftrace_notrace

# 函数图谱只追踪某函数子调用
echo 'tcp_sendmsg' > set_graph_function

# 基于 PID 过滤
echo 1234 > set_ftrace_pid

四、Hist Triggers 与 Synthetic Events：超越数据采集

4.1 Hist Triggers：内核内直方图统计

Hist triggers 允许在 Ring Buffer 层面直接聚合数据，避免用户空间后处理的开销：

# 创建 hist trigger：按时延统计上下文切换频率
echo 'hist:keys=prev_comm,next_comm:vals=hitcount,lat=common_timestamp.usecs' > \
  /sys/kernel/debug/tracing/events/sched/sched_switch/trigger

echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable

# 查看聚合结果（无需等待 trace 数据回绕）
cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist

输出示例：

{ next_comm: swapper/0, prev_comm: nginx } hitcount=1245, lat: 1288 ulat: 1206
{ next_comm: postgres, prev_comm: swapper/2 } hitcount=892, lat: 756 ulat: 712
... (截断输出)

4.2 Synthetic Events：用户定再造事件

Linux 5.0 引入的 Synthetic Events 允许用户自定义"虚拟事件"，由多个真实事件组合触发：

# 创建合成事件：将 sched_switch 和 wakeup 组合为 cross_latency
echo 'synthetic/wake_latency \
    u64 wake_t; \
    u64 sleep_ns;' \
    > /sys/kernel/debug/tracing/synthetic_events

# 关联：在 sched_wakeup 时记录 wake_t
echo 'hist:keys=pid:wake_t=common_timestamp.usecs \
    if comm=="my_server"' \
    > events/sched/sched_wakeup/trigger

# 关联：在 sched_switch 时计算 sleep_ns（sched_switch 到下次 wakeup 间隔）
echo 'hist:keys=pid,prio:\
    sleep_ns=common_timestamp.usecs-$wake_t \
    if comm=="my_server"' \
    > events/sched/sched_switch/trigger

# 将 hist 结果导入合成事件
echo 'hist:keys=pid,sleep_ns:\
    onmatch(sched.sched_switch).wake_latency($wake_t,sleep_ns) \
    if comm=="my_server"' \
    > events/sched/sched_switch/trigger

五、trace-cmd 与 KernelShark：生产级工具链

5.1 trace-cmd 核心用法

trace-cmd 是 ftrace 的命令行封装，支持跨主机分布式追踪和快照捕获：

# 基础追踪
trace-cmd start -p function_graph -g tcp_sendmsg
trace-cmd show > /tmp/trace.out

# 条件过滤
trace-cmd start -e sched_switch -f 'prev_prio < 120 && next_comm ~ "nginx*"'

# 差分分析（与基准对比）
trace-cmd start -e sched_switch
stress-ng --cpu 8 --timeout 120s
trace-cmd stop
trace-cmd extract -o /tmp/stress.dat
trace-cmd split -o /tmp/split/ -m 1000000  # 按文件大小分割

# 跨主机追踪（使用 trace-cmd listen）
# 在目标机：
trace-cmd listen -p 5678
# 在诊断机：
trace-cmd start --host target:5678 -e sched_switch

5.2 KernelShark 图形化分析

KernelShark 是 ftrace 的 GUI 分析工具，支持：

• 多 CPU 时间轴同步显示
• Task Interleave Analysis（同一任务在多个 CPU 上的调度）
• Event Filter（正则+函数名匹配）
• Markers（手动标注特定时间点）
• 导出高分辨率 SVG 时序图

# 启动分析
kernelshark /tmp/stress.dat

# 加载多个 trace data 对比
kernelshark -m /tmp/baseline.dat /tmp/stress.dat

六、Tracepoints 与 eBPF/perf 的融合

6.1 从 Tracepoint 到 BPF Program

Tracepoints 天然支持 eBPF attach（类型为 BPF_PROG_TYPE_TRACEPOINT），使得 BPF 程序可以直接在静态探针点执行：

// BPF 程序（定义在 BPF 代码中）
SEC("tracepoint/sched/sched_switch")
int tracepoint__sched_sched_switch(struct trace_event_raw_sched_switch *ctx)
{
    u32 prev_pid = ctx->prev_pid;
    u32 next_pid = ctx->next_pid;
    
    // 使用 BPF 内置函数读用户态内存（无需 copy_to_user）
    bpf_probe_read_str(ctx->prev_comm, sizeof(ctx->prev_comm));
    
    // 推送到 BPF ring buffer（比 perf buffer 更高效）
    struct e *e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
    if (e) {
        e->prev = prev_pid;
        e->next = next_pid;
        bpf_ringbuf_submit(e, 0);
    }
    return 0;
}

6.2 Perf 与 Tracepoints 集成

Perf 可以将 tracepoints 作为采样点（sampling event）：

# 使用 perf stat 统计调度次数
perf stat -e 'sched:sched_switch' -p 1234 sleep 10

# 使用 perf record 采样并生成火焰图
perf record -e sched:sched_switch -g -a sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > sched_switch.svg

# 使用 perf trace 直接追踪
perf trace -e sched:sched_switch --call-graph=dwarf

6.3 Tracepoint vs kprobe 性能对比

七、实战：生产环境延迟尖刺诊断

7.1 诊断框架

我们面对的问题：某金融交易系统偶发 50ms 延迟尖刺（99 分位），不可复现。

诊断步骤：
1. 使用 trace-cmd + snapshot 模式持续追踪调度器和块层事件
2. 当延迟尖刺发生时通过 GPIO 触发 snapshot
3. 用 KernelShark 分析 50ms 时间窗口内的调度/block/irq 事件
4. 使用合成事件关联关键时间戳
5. 用 BPF 程序自动捕获毫秒级统计数据

7.2 完整诊断脚本

#!/bin/bash
# setup_latency_trace.sh
SYSFS=/sys/kernel/debug/tracing

# Step 1: 配置环形缓冲区 + snapshot
echo 8192 > $SYSFS/buffer_size_kb
echo 1 > $SYSFS/trace_options/snapshot

# Step 2: 启用关键事件
echo 1 > $SYSFS/events/sched/sched_switch/enable
echo 1 > $SYSFS/events/sched/sched_wakeup/enable
echo 1 > $SYSFS/events/irq/irq_handler_entry/enable
echo 1 > $SYSFS/events/block/block_rq_issue/enable
echo 1 > $SYSFS/events/block/block_rq_complete/enable

# Step 3: 设置过滤器 - 只追踪关键 PID
echo 0 > $SYSFS/set_event_pid  # 先清空
echo $TRADING_PID >> $SYSFS/set_event_pid

# Step 4: 添加 synthetic 延迟统计
echo 'hist:keys=common_pid:lat=common_timestamp.usecs-$last_ts' \
    > $SYSFS/events/sched/sched_switch/trigger
echo 'hist:keys=common_pid:last_ts=common_timestamp.usecs' \
    > $SYSFS/events/sched/sched_switch/trigger

# Step 5: 启动追踪
echo 1 > $SYSFS/tracing_on

echo "跟踪已启动。PID: $TRADING_PID"
echo "尖刺发生后执行: echo 1 > $SYSFS/snapshot"

7.3 BPF 监控程序实时统计

// latency_monitor.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, u32);   // cpu
    __type(value, u64); // last sched time
    __uint(max_entries, 512);
} last_time SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __type(key, u32);   // bucket index
    __type(value, u64); // count
    __uint(max_entries, 64);
} hist SEC(".maps");

SEC("tp_btf/sched_switch")
int BPF_PROG(trace_sched_switch, bool preempt,
         struct task_struct *prev, struct task_struct *next)
{
    u64 now = bpf_ktime_get_ns();
    u32 cpu = bpf_get_smp_processor_id();
    u64 *last = bpf_map_lookup_elem(&last_time, &cpu);
    u64 delta = last ? now - *last : 0;
    
    // 更新直方图（10us 一档，64 档覆盖 640us）
    u32 bucket = delta / 10000;
    if (bucket >= 64) bucket = 63;
    u64 *count = bpf_map_lookup_elem(&hist, &bucket);
    if (count) __sync_fetch_and_add(count, 1);
    
    if (last) *last = now;
    return 0;
}

char _license[] SEC("license") = "GPL";

八、高级主题：Tracepoint 扩展与未来演进

8.1 自定义 Tracepoint 开发

驱动开发者可以创建子系统专属的 tracepoint：

// my_driver.h
#undef TRACE_SYSTEM
#define TRACE_SYSTEM my_driver

#if !defined(_TRACE_MY_DRIVER_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_MY_DRIVER_H

#include <linux/tracepoint.h>

TRACE_EVENT(my_driver_dma_complete,
    TP_PROTO(struct device *dev, dma_addr_t handle, int status),
    TP_ARGS(dev, handle, status),
    
    TP_STRUCT__entry(
        __string(    dev_name,    dev_name(dev))
        __field(    dma_addr_t,    handle)
        __field(    int,        status)
    ),
    
    TP_fast_assign(
        __assign_str(dev_name, dev_name(dev));
        __entry->handle = handle;
        __entry->status = status;
    ),
    
    TP_printk("dev=%s handle=%pad status=%d",
          __get_str(dev_name), &__entry->handle, __entry->status)
);

#endif /* _TRACE_MY_DRIVER_H */

// 确保只包含一次
#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE my_driver_trace
#undef TRACE_INCLUDE_PATH
#define TRACE_INCLUDE_PATH .
#include <trace/define_trace.h>

8.2 LTTng 与内核 Tracepoints 对比

8.3 内核 Tracepoint 演进趋势

• BPF 取代 reader 阶段：通过 BPF_MAP_TYPE_RING_BUF 替代传统 read() 流，实现零拷贝采集
• Telemetry 框架合并：2024 年内核社区讨论将 eBPF/extrace/tracepoint 整合为统一的 telemetry 子系统
• 硬实时支持：RT 内核中 tracepoints 已经实现不可抢占区最小化，保证 preempt-rt 延迟确定性

九、总结与工程检查清单

Tracepoints 作为 Linux 内核静态探针的三大支柱之一（另两个是 kprobe 和 perf event），具有不可替代的工程价值：

• 零成本基线：未启用时仅一条条件分支 + 5 字节 NOP，对生产性能影响可忽略
• ABI 稳定：面向用户的 tracepoint API 保证跨内核小版本兼容，适合监控探针长期维护
• 生态完整：toolchain（trace-cmd/kernelshark）+ 可视化（CTF/perf）+ 编程（eBPF）形成闭环

生产诊断检查清单：

1. 确认目标系统 tracefs 挂载：mount -t debugfs none /sys/kernel/debug
2. 使用 trace-cmd check 验证所有依赖（libtracefs/libtraceevent）
3. 首选 tracepoint 而非 kprobe 获取函数级数据（稳定性更好）
4. 使用 hist trigger 做聚合统计，避免 userland 后处理开销
5. 高负载环境优先使用 BPF ring buffer 而非 perf buffer
6. 将自定义 tracepoint 与 sysfs/proc 数据源结合构建全栈可观测性
7. 保留 snapshot buffer，捕获偶发性延迟事件而非完整 trace

通过将 Tracepoints 与 eBPF、perf 等工具组合使用，我们可以构建一套覆盖"宏观聚合统计 + 微观事件追踪"的全栈诊断体系，为生产环境中的偶发性延迟问题提供从发现问题到定位根因的完整链路。