function_graph tracer 是 Linux ftrace 中最实用的函数级调用追踪机制，适合定位延迟、分析调用路径、验证执行流；生产中需通过 trace-cmd 配合 -g、--max-graph-depth、-P/-F 实现低开销、精准过滤与可溯分析。
function_graph tracer 是 Linux ftrace 中最实用的函数级调用追踪机制，适合定位延迟、分析调用路径、验证代码执行流。在生产环境使用时，核心目标是：低开销、快速启用/停用、精准过滤、结果可读可存档。trace-cmd 是其推荐配套工具，比 raw debugfs 操作更健壮、支持事件混合、能生成 HTML 报告。
基础安全启用（最小侵入）
生产系统禁用写入 /sys/kernel/debug/tracing 直接操作。应使用 trace-cmd 封装，避免手误触发全系统函数跟踪：
- 先检查是否启用：trace-cmd list -t | grep function_graph
- 仅跟踪指定进程（PID=1234）且限制深度（防栈爆炸）：
trace-cmd record -p function_graph -g 'do_sys_open' -P 1234 --max-graph-depth 8 -o open-trace.dat - 不加 -P 则默认跟踪所有 CPU，但生产中务必配合 -F（filter）或 -g（只抓特定函数）降低开销
关键函数过滤与深度控制
盲目开启 function_graph 会导致每微秒数万行日志、CPU 占用飙升。必须聚焦目标：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用 -g 指定入口函数（如 tcp_transmit_skb、__schedule、vfs_read），ftrace 自动展开其子调用
- 用 --max-graph-depth N（建议 5–10）截断深层嵌套，避免内核栈溢出或日志爆炸
- 排除高频干扰函数（如 tick_sched_do_timer）：
trace-cmd set_ftrace_filter -n 'tick_*' -n 'hrtimer_*'（-n 表示 negate）
低开销持续采样模板（适合线上巡检）
不记录完整 trace，而是周期性短时抓取，兼顾可观测性与稳定性：
- 每 5 分钟抓 3 秒，只录 sched 和 block 相关函数：
while true; do trace-cmd record -p function_graph -g '__schedule' -g 'submit_bio' -g 'blk_mq_dispatch_rq_list' -o /var/log/trace/$(date -u +%s).dat --max-graph-depth 6 -T 3; sleep 300; done & - 搭配 logrotate 管理磁盘空间，单个 trace 文件通常
- 用 trace-cmd report -F 命令快速查看最后一次抓取的火焰图结构
结果分析与交付（给开发/运维）
原始 trace.dat 不易阅读，需转换为协作格式：
- 生成带时间轴的文本报告：trace-cmd report open-trace.dat > open-report.txt
- 导出为火焰图（需 kernelshark 或第三方脚本）：
trace-cmd report -F open-trace.dat | stackcollapse-trace.pl | flamegraph.pl > open-flame.svg - 提取某次调用耗时明细（如 do_sys_open → vfs_open → path_openat）：
trace-cmd report open-trace.dat | awk '/do_sys_open/,/^$/' | grep -E '(do_sys_open|vfs_open|path_openat|entry)|duration/'
trace-cmd + function_graph 在生产中不是“打开就跑”，而是“明确目标、限制范围、定时轻量、结果可溯”。只要控制好 -g、--max-graph-depth、-P/-F 三个参数，就能在不影响服务的前提下获得高价值调用链证据。
