动态分析 Linux 内核函数调用关系

🚀返回专栏总目录

更多内容可以加入Linux系统知识库套餐（教程＋视频＋答疑）

加我微信领取Linux大全课程大额优惠劵：

文章目录

• 前言
• 一、环境准备
• 1.1 内核配置
• 1.2 挂载 debugfs / tracefs
• 1.3 工具安装
• 二、Ftrace：内核函数追踪利器
• 2.1 核心 Tracer 类型
• 2.2 function 追踪器：函数调用记录
• 2.3 function_graph 追踪器：调用关系图
• 2.4 控制追踪深度
• 2.5 过滤特定进程
• 三、trace-cmd：Ftrace 的瑞士军刀
• 3.1 手工 Ftrace vs trace-cmd
• 3.2 核心命令
• 3.3 实战示例
• 3.4 record 命令常用选项
• 四、KernelShark：图形化时间线分析
• 4.1 启动与界面
• 4.2 核心功能
• 4.3 典型分析流程
• 五、Perf：内核性能采样利器
• 5.1 基本用法
• 5.2 追踪特定内核函数
• 5.3 perf ftrace 子命令
• 5.4 生成调用关系图
• 六、FlameGraph：壮观的火焰图
• 6.1 从 Perf 数据生成火焰图
• 6.2 从 Ftrace 数据生成火焰图
• 6.3 火焰图解读
• 七、工具对比与选择
• 工具选择建议
• 八、实战案例：追踪系统调用的内核路径
• 8.1 使用 Ftrace 直接追踪
• 8.2 使用 trace-cmd 一键完成
• 8.3 使用 Perf + FlameGraph
• 九、总结

沉淀、分享、成长，让自己和他人都能有所收获！😄

前言

源码分析是开发者理解系统行为的基石。在前面的文章中，我们分别介绍了如何静态分析 C 程序的函数调用关系（利用 cflow、calltree 等工具直接从源码文本中提取调用树），以及如何动态分析用户态应用程序的实际函数执行路径（利用 gprof、Valgrind 等工具记录运行时的调用情况）。

本文将视角深入到内核空间——当一个应用程序执行时，它究竟调用了哪些内核接口（系统调用）？这些接口在内核内部的执行路径是怎样的？哪些函数是性能热点？

我们将围绕三款核心工具展开：Ftrace（内核内置追踪框架）、Perf（内核性能采样利器）和 FlameGraph（火焰图可视化），系统讲解如何动态分析 Linux 内核的函数调用关系。

一、环境准备

1.1 内核配置

Ftrace 和 Perf 依赖内核的特定配置项。主流 Linux 发行版通常已经默认启用，可以通过以下方式检查：

grep-E"CONFIG_FTRACE|CONFIG_DEBUG_FS|CONFIG_FUNCTION_TRACER|CONFIG_FUNCTION_GRAPH_TRACER" /boot/config-$(uname-r)

期望输出：

CONFIG_FTRACE=y
CONFIG_DEBUG_FS=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y

1.2 挂载 debugfs / tracefs

Ftrace 通过 debugfs（或 tracefs）文件系统对外暴露接口：

# 手动挂载（重启后失效）
sudomount-t debugfs none /sys/kernel/debug

# 永久生效：在 /etc/fstab 中添加
# debugfs /sys/kernel/debug debugfs defaults 0 0

挂载成功后，Ftrace 的控制中心位于 /sys/kernel/debug/tracing/。

1.3 工具安装

# Ftrace 命令行封装
sudoapt-getinstall trace-cmd kernelshark

# Perf 性能分析工具
sudoapt-getinstall linux-tools-generic linux-tools-$(uname-r)

# FlameGraph 火焰图工具
git clone --depth1 https://github.com/brendangregg/FlameGraph.git

二、Ftrace：内核函数追踪利器

Ftrace（Function Tracer）是 Linux 内核内置的轻量级追踪框架，无需重新编译内核、无需插入模块，即可实时窥探内核内部正在发生的一切。

2.1 核心 Tracer 类型

2.2 function 追踪器：函数调用记录

最基础的用法——追踪某个内核函数是否被调用：

cd /sys/kernel/debug/tracing

# 清空历史状态
echo nop > current_tracer
echo> set_ftrace_filter
echo> trace

# 设置追踪目标：schedule 调度函数
echo schedule > set_ftrace_filter

# 启用 function 追踪器
echofunction> current_tracer
echo1> tracing_on

# 让系统运行一会儿
sleep2

# 关闭追踪
echo0> tracing_on

# 查看结果
cat trace |head-20

输出示例：

# tracer: function
#
#          TASKID-CPU    TIMESTAMP  FUNCTION
#           PID-CPU     TIMESTAMP  FUNCTION
#              |  |         |         |
         bash-3145  [007]  1234.567: schedule <- __schedule
         bash-3145  [007]  1234.568: schedule <- __schedule
      kworker-123   [002]  1234.569: schedule <- __schedule

FUNCTION 列后面的 <- 表示该函数是被哪个父函数调用的，这其实就是调用栈的一部分。

2.3 function_graph 追踪器：调用关系图

这是本文的重点。function_graph 追踪器能在函数的入口和出口都添加探测点，从而绘制出完整的函数调用关系图（包含嵌套层次和执行耗时）：

cd /sys/kernel/debug/tracing

# 重置
echo nop > current_tracer
echo> trace

# 设置目标函数
echo do_sys_open > set_graph_function

# 启用 function_graph 追踪器
echo function_graph > current_tracer
echo1> tracing_on

# 在另一个终端触发系统调用
cat /etc/hosts > /dev/null

# 关闭并查看
echo0> tracing_on
cat trace |head-40

输出示例（缩进表示调用层次，+ 表示耗时超过 10 微秒）：

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
  1)               |  do_sys_open() {
  1)               |    getname() {
  1)               |      getname_flags() {
  1)               |        kmem_cache_alloc() {
  1)   0.206 us    |          _cond_resched();
  1)   0.724 us    |        }
  1)   0.169 us    |        should_failslab();
  1)   1.792 us    |      }
  1)               |      __check_object_size() {
  1)   0.167 us    |        check_stack_object();
  1)   0.207 us    |        __virt_addr_valid();
  1)   0.212 us    |        __check_heap_object();
  1)   1.286 us    |      }
  1)   3.744 us    |    }
  1)   4.134 us    |  }

从这段输出中可以清晰地看到：

• do_sys_open
   调用了 getname
• getname
   调用了 getname_flags
• getname_flags
   调用了 kmem_cache_alloc 和 __check_object_size
• 每个函数的执行耗时一目了然

2.4 控制追踪深度

内核函数调用层次可能非常深，输出量巨大。可以通过 max_graph_depth 限制追踪深度：

# 只追踪 2 层调用
echo2> max_graph_depth

2.5 过滤特定进程

只追踪某个 PID 的调用：

echo$$> set_ftrace_pid    # 追踪当前 shell 进程
echo1> tracing_on
ls /tmp                      # 触发系统调用
echo0> tracing_on
cat trace

三、trace-cmd：Ftrace 的瑞士军刀

手工操作 Ftrace 需要 echo 多个文件，步骤繁琐且数据无法持久化。trace-cmd 是 Ftrace 的命令行封装，一条命令即可完成记录、分析和导出。

3.1 手工 Ftrace vs trace-cmd

3.2 核心命令

# 记录 trace 数据（生成 trace.dat）
trace-cmd record

# 解析并输出文本
trace-cmd report

# 查看当前 ftrace 状态
trace-cmd show

# 重置 ftrace 配置
trace-cmd reset

# 列出可用的 tracer / event
trace-cmd list

3.3 实战示例

追踪特定函数的调用链：

# 追踪 vfs_read 的完整调用图
trace-cmd record -p function_graph -g vfs_read cat /etc/hosts

# 查看结果
trace-cmd report |cut-c66-

追踪运行中进程的系统调用：

# 追踪 PID 1234 的调度事件，持续 10 秒
trace-cmd record -e sched:sched_switch -e sched:sched_wakeup -P1234sleep10

# 查看结果
trace-cmd report |grep sched_switch

多事件联合追踪：

# 同时记录调度、中断、网络事件
trace-cmd record \
-e sched:sched_switch \
-e irq:irq_handler_entry \
-e irq:softirq_entry \
-e net:netif_receive_skb \
-b20480\
sleep10

3.4 record 命令常用选项

四、KernelShark：图形化时间线分析

KernelShark 是 trace-cmd 输出文件的可视化前端，由 Ftrace 核心维护者 Steven Rostedt 发起。它能将多核、多事件的时间线直观呈现，是分析跨核心调度问题的利器。

4.1 启动与界面

# 记录数据
trace-cmd record -e'sched:*'-e'irq:*'sleep5

# 用 KernelShark 打开
kernelshark trace.dat

界面结构：

┌─────────────────────────────────────────────────────────┐
│ 文件  编辑  过滤  工具  帮助                              │
├─────────────────────────────────────────────────────────┤
│ ⏵ CPU 0  ████▓▓░░████▓▓░░   sched_switch, irq_handler  │
│ ⏵ CPU 1  ░░████▓▓░░████▓▓   sched_switch, kworker      │
│ ⏵ CPU 2  ▓▓░░████▓▓░░████   sched_wakeup, net_rx       │
│ ⏵ CPU 3  ████░░▓▓████░░▓▓   softirq_entry, tcp_v4_rcv  │
├─────────────────────────────────────────────────────────┤
│ 时间轴：  |-------|-------|-------|-------|             │
├─────────────────────────────────────────────────────────┤
│ Event 详情：                                             │
│ CPU: 2  Time: 1234.567890                               │
│ Event: net:netif_receive_skb                             │
└─────────────────────────────────────────────────────────┘

4.2 核心功能

4.3 典型分析流程

五、Perf：内核性能采样利器

Perf 是 Linux 内核性能分析的全能工具，支持硬件事件、软件事件和动态追踪，开销远低于 Ftrace 的 function_graph 模式，适合在生产环境中使用。

5.1 基本用法

# 全系统采样 30 秒（含调用栈）
perf record -a-g -- sleep30

# 查看交互式报告
perf report

5.2 追踪特定内核函数

# 追踪 do_sys_open 的调用
perf record -e probe:do_sys_open -a-g -- sleep10

# 追踪所有系统调用
perf record -e syscalls:sys_enter_* -a-g -- sleep10

5.3 perf ftrace 子命令

Perf 也封装了 Ftrace 的 function 和 function_graph 追踪器：

# 使用 function 追踪器
perf ftrace -T do_nanosleep -asleep10

# 使用 function_graph 追踪器
perf ftrace -G do_nanosleep -asleep10

5.4 生成调用关系图

# 采样并生成 dot 图
perf record -g -- sleep10
perf script | c++filt | perf2dot > callgraph.dot
dot -Tsvg callgraph.dot > callgraph.svg

六、FlameGraph：壮观的火焰图

FlameGraph 由 Brendan Gregg 开发，能将 profiling 数据可视化为直观的火焰图。它不是直接绘制调用关系图，而是将调用栈的采样分布以"火焰"的形式展现，热点函数一目了然。

6.1 从 Perf 数据生成火焰图

# 1. Perf 采样
perf record -F99-a-g -- sleep30

# 2. 导出采样数据
perf script > perf.stacks

# 3. 折叠调用栈
./FlameGraph/stackcollapse-perf.pl perf.stacks > perf.folded

# 4. 生成火焰图
./FlameGraph/flamegraph.pl perf.folded > flame.svg

6.2 从 Ftrace 数据生成火焰图

# 1. trace-cmd 记录
trace-cmd record -p function_graph -g do_sys_open sleep5

# 2. 导出并转换
trace-cmd report | ./FlameGraph/stackcollapse.pl > folded.txt

# 3. 生成火焰图
./FlameGraph/flamegraph.pl folded.txt > ftrace-flame.svg

6.3 火焰图解读

            ┌──────────────┐
            │  hot_func()  │  ← 顶层：当前执行的函数
       ┌────┴──────┬───────┴──┐
       │ parent_a()│ parent_b()│  ← 中层：调用者
  ┌────┴───┐  ┌───┴────┐  ┌───┴───┐
  │entry_1 │  │entry_2 │  │entry_3│  ← 底层：入口函数
  └────────┘  └────────┘  └───────┘
  ◄──────── 横轴：采样占比（越宽 = 耗时越多）────────►

• 纵轴
  ：调用栈深度，越往上越底层（被调用的函数）
• 横轴
  ：采样占比，越宽表示该函数被采样到的次数越多
• 颜色
  ：无特殊含义，仅用于区分不同模块
• 平顶
  （plateaus）：如果顶部出现宽阔的平坦区域，可能存在性能瓶颈

七、工具对比与选择

工具选择建议

八、实战案例：追踪系统调用的内核路径

以一个完整的例子收尾——追踪 open() 系统调用在内核中的完整执行路径：

8.1 使用 Ftrace 直接追踪

cd /sys/kernel/debug/tracing

echo nop > current_tracer
echo> trace
echo do_sys_open > set_graph_function
echo function_graph > current_tracer
echo1> tracing_on

cat /etc/hosts > /dev/null

echo0> tracing_on
cat trace

8.2 使用 trace-cmd 一键完成

trace-cmd record -p function_graph -g do_sys_open -Fcat /etc/hosts
trace-cmd report |cut-c66-

8.3 使用 Perf + FlameGraph

# Perf 采样
perf record -F99-g -- cat /etc/hosts

# 生成火焰图
perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > open-flame.svg

三种方式各有优势：Ftrace 给出最完整的调用树，trace-cmd 便于持久化和多事件关联分析，Perf + FlameGraph 则在性能热点定位上最为直观。

九、总结

本文系统介绍了动态分析 Linux 内核函数调用关系的四大工具：

1. Ftrace
   ：内核内置的追踪框架，function_graph 追踪器能输出完整的函数调用关系图，是理解内核执行路径的首选
2. trace-cmd
   ：Ftrace 的命令行封装，解决了手工操作繁琐和数据持久化的问题
3. KernelShark
   ：图形化时间线分析工具，在多核调度分析中表现优异
4. Perf + FlameGraph
   ：低开销的采样方案配合火焰图可视化，是生产环境性能分析的黄金组合

掌握这些工具后，面对任何内核行为——无论是系统调用的执行路径、中断处理的延迟来源，还是调度器的决策过程——都能做到"有迹可循，有图可查"。

延伸阅读： gcov 和 kgcov 分别支持用户态和内核态的代码行级别覆盖率分析，是函数级分析的进一步深入。