perf_event源码分析(二)——cmd_report

__cmd_report()分析了perf_session_open()、perf_session_read_header()等过程,涉及事件处理、线程与进程映射、内核及用户模块解析。通过perf_event__process_event()、perf_event__process_mmap()、perf_event__process_comm()处理不同类型的事件,如PERF_RECORD_MMAP用于映射解析,PERF_RECORD_COMM更新线程信息,PERF_RECORD_SAMPLE用于采样事件处理,加载DSO符号。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

__cmd_report() => perf_session_open(),打开perf.data=>perf_session_read_header()根据perf.data的头部初始化session->evlist链表上的各个事件。

perf_session__process_events()首先把0号进程封装成一个thread结构体th->comm=”swapper”,初始化th->mg,并将这个thread结构体放到session->threads红黑树上。

接下来,到perf.data的data_offset处,fetch_mapped_event()得到一个perf_event,perf_session__process_event()处理这个事件,++session->hists->stats.nr_events[0]以及nr_events[event->header.type],对于内核事件,perf_session__parse_sample()根据session->sample_type解析事件类型,确定perf_sample结构体内容(用户事件处理:perf_session__process_user

google-perftools 简介 google-perftools 是一款针对 C/C++ 程序的性能分析工具,它是一个遵守 BSD 协议的开源项目。使用该工具可以对 CPU 时间片、内存等系统资源的分配和使用进行分析,本文将重点介绍如何进行 CPU 时间片的剖析。 google-perftools 对一个程序的 CPU 性能剖析包括以下几个步骤。 1. 编译目标程序,加入对 google-perftools 库的依赖。 2. 运行目标程序,并用某种方式启动 / 终止剖析函数并产生剖析结果。 3. 运行剖结果转换工具,将不可读的结果数据转化成某种格式的文档(例如 pdf,txt,gv 等)。 安装 您可以在 google-perftools 的网站 (http://code.google.com/p/google-perftools/downloads/list) 上下载最新版的安装包。为完成步骤 3 的工作,您还需要一个将剖析结果转化为程序员可读文档的工具,例如 gv(http://www.gnu.org/software/gv/)。 编译与运行 您需要在原有的编译选项中加入对 libprofiler.so 的引用,这样在目标程序运行时会加载工具的动态库。例如本例中作者的系统中,libprofiler.so 安装在"/usr/lib"目录下,所以需要在 makefile 文件中的编译选项加入“-L/usr/lib -lprofiler”。 google-perftools 需要在目标代码的开始和结尾点分别调用剖析模块的启动和终止函数,这样在目标程序运行时就可以对这段时间内程序实际占用的 CPU 时间片进行统计和分析。工具的启动和终止可以采用以下两种方式。 a. 使用调试工具 gdb 在程序中手动运行性能工具的启动 / 终止函数。 gdb 是 Linux 上广泛使用的调试工具,它提供了强大的命令行功能,使我们可以在程序运行时插入断点并在断点处执行其他函数。具体的文档请参照 http://www.gnu.org/software/gdb/,本文中将只对用到的几个基本功能进行简单介绍。使用以下几个功能就可以满足我们性能调试的基本需求,具体使用请参见下文示例。 命令 功能 ctrl+c 暂停程序的运行 c 继续程序的运行 b 添加函数断点(参数可以是源代码中的行号或者一个函数名) p 打印某个量的值或者执行一个函数调用 b. 在目标代码中直接加入性能工具函数的调用,该方法就是在程序代码中直接加入调试函数的调用。 两种方式都需要对目标程序重新编译,加入对性能工具的库依赖。对于前者,他的好处是使用比较灵活,但工具的启动和终止依赖于程序员的手动操作,常常需要一些暂停函数(比如休眠 sleep)的支持才能达到控制程序的目的,因此精度可能受到影响。对于后者,它需要对目标代码的进行修改,需要处理函数声明等问题,但得到的结果精度较高,缺点是每次重新设置启动点都需要重新编译,灵活度不高,读者可以根据自己的实际需求采用有效的方式。 示例详解 该程序是一个简单的例子,文中有两处耗时的无用操作,并且者间有一定的调用关系。 清单 1. 示例程序 void consumeSomeCPUTime1(int input){ int i = 0; input++; while(i++ < 10000){ i--; i++; i--; i++; } }; void consumeSomeCPUTime2(int input){ input++; consumeSomeCPUTime1(input); int i = 0; while(i++ < 10000){ i--; i++; i--; i++; } }; int stupidComputing(int a, int b){ int i = 0; while( i++ < 10000){ consumeSomeCPUTime1(i); } int j = 0; while(j++ < 5000){ consumeSomeCPUTime2(j); } return a+b; }; int smartComputing(int a, int b){ return a+b; }; void main(){ int i = 0; printf("reached the start point of performance bottle neck\n"); sleep(5); //ProfilerStart("CPUProfile"); while( i++ MyProfile.pdf 转换后产生的结果文档如下图。图中的数字和框体的大小代表了的某个函数的运行时间占整个剖析时间的比例。由代码的逻辑可知,stupidComputing,stupidComputing2 都是费时操作并且它们和 consumeSomeCPUTime 存在着一定的调用关系。 图 1. 剖析结果 结束语 本文介绍了一个 Linux 平台上的性能剖析工具 google-perftools,并结合实例向读者展示了如何使用该工具配置、使用及分析性能瓶颈。
<think>嗯,用户想了解ftrace和perf工具的组合使用方法及其在性能分析中的应用。这是一个关于Linux系统性能分析的深度技术问题。 用户应该是系统工程师或内核开发者,需要具体的技术实现方案。从问题表述看,用户对这两个工具已有基础认知,现在需要知道如何整合使用。 参考站内资料,ftrace主要提供内核函数级追踪能力,通过debugfs接口控制;perf则是更全面的性能分析工具,支持硬件事件统计和调用栈分析。两者组合能覆盖从硬件事件到软件调用的完整分析链路。 考虑设计分步骤的联合使用方案: 首先用perf top快速定位热点函数,再用ftrace深入追踪特定函数调用路径。当发现异常调度行为时,可以用perf sched分析调度延迟,同时用ftrace追踪相关内核函数执行情况。 对于内存管理问题,perf mem可以监控缺页异常率,而ftrace能详细追踪do_page_fault的完整调用链。在IO分析场景,perf可以统计块设备层延迟分布,ftrace则能记录具体bio请求的生命周期。 需要特别注意工具间的数据关联方法,比如通过统一的traceID匹配事件。还要提醒用户注意内核版本差异带来的功能限制。 最后考虑补充几个典型问题:如何解决符号表缺失问题,容器环境下的特殊配置,以及如何自动化分析流程。这些应该都是用户后续可能遇到的实践难点。</think>ftrace 和 perf 是 Linux 系统性能分析中互补性极强的工具,组合使用可以提供从硬件事件到内核函数调用的完整洞察。以下是核心组合策略及应用场景: --- ### **1. 定位热点:perf top/stat → ftrace 深度追踪** * **perf 定位范围** 先用 `perf top` 或 `perf stat` 找出 CPU 占用高的函数或硬件事件(如缓存未命中、分支预测失败): ```bash perf top -g # 实时查看函数热点及调用栈 perf stat -e cache-misses # 统计指定硬件事件 ``` * **ftrace 深入内核逻辑** 针对 `perf` 发现的热点函数(如 `do_page_fault`),用 ftrace 追踪其调用关系和耗时: ```bash echo function_graph > /sys/kernel/debug/tracing/current_tracer echo do_page_fault > /sys/kernel/debug/tracing/set_graph_function echo 1 > /sys/kernel/debug/tracing/tracing_on # 运行负载复现问题 echo 0 > /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace > ftrace.log ``` **输出分析**:查看 `do_page_fault` 的子函数调用耗时,定位延迟根源(如 `__alloc_pages` 慢)[^4]。 --- ### **2. 调度分析:perf sched + ftrace 事件追踪** * **perf sched 分析调度延迟** 检查任务切换、CPU 迁移导致的延迟: ```bash perf sched record -C 1 # 记录 CPU1 调度事件 perf sched latency --sort max # 显示最大延迟任务 ``` * **ftrace 关联内核事件** 结合 `sched_switch`、`sched_wakeup` 事件追踪具体调度过程: ```bash echo 'sched:*' > /sys/kernel/debug/tracing/set_event trace-cmd record -e sched_switch,sched_wakeup -P 1234 # 追踪 PID=1234 的任务 trace-cmd report ``` **场景**:分析实时任务因 I/O 中断被打断时,`perf sched` 发现高延迟,`ftrace` 定位到中断处理函数 `handle_irq_event` 占用过长 CPU 时间[^2]。 --- ### **3. 内存分析:perf mem + ftrace 缺页追踪** * **perf mem 监控内存访问** 分析内存负载(LLC 未命中、DRAM 访问): ```bash perf mem record -a -- sleep 5 # 采样内存访问事件 perf report --sort=mem ``` * **ftrace 追踪缺页路径** 当 `perf` 发现高缺页率时,用 ftrace 记录缺页完整调用链: ```bash trace-cmd record -p function_graph -l handle_mm_fault -g do_page_fault ``` **输出关键**:观察 `__handle_mm_fault` 中是否频繁调用 `filemap_fault`(文件映射缺页)或 `do_swap_page`(换页),判断内存压力来源[^4]。 --- ### **4. I/O 分析:perf 块层统计 + ftrace 请求追踪** * **perf 监控块设备层** 统计 I/O 延迟分布: ```bash perf trace -e block:block_rq_issue,block:block_rq_complete ``` * **ftrace 记录 bio 生命周期** 追踪具体 I/O 请求在内核栈的流转: ```bash echo block:block_bio_queue > /sys/kernel/debug/tracing/set_event echo block:block_getrq >> /sys/kernel/debug/tracing/set_event ``` **关联分析**:当 `perf` 发现 `block_rq_complete` 延迟突增时,`ftrace` 可定位到 `blk_mq_end_request` 前是否因 `scsi_queue_rq` 等待过久。 --- ### **关键组合优势** | **工具** | **优势场景** | **组合价值** | |----------|------------------------------|----------------------------------| | **perf** | 硬件事件统计、调用栈采样 | 快速定位瓶颈范围 | | **ftrace** | 函数级追踪、自定义事件触发 | 深入内核逻辑,分析事件因果链 | | **协同** | 数据交叉验证 | `perf` 发现异常 → `ftrace` 解释根因 | --- ### **典型问题** 1. **如何关联 perf 和 ftrace 的时间戳?** 需在两者启用统一时钟源(如 `tsc`),通过 `perf script` 输出事件时间戳与 ftrace 日志手动对齐。 2. **容器中如何使用 ftrace?** 需在宿主机启用容器 PID 命名空间追踪: `trace-cmd record -e sched_switch -P $(docker inspect --format '{{.State.Pid}}' <容器ID>)` 3. **符号缺失怎么办?** 确保安装调试符号包(如 `linux-image-$(uname -r)-dbgsym`),并在 perf 命令添加 `--kallsyms=/proc/kallsyms`。 > **最佳实践**:先用 `perf` 缩小问题范围,再用 `ftrace` 深入特定路径。对于复杂场景(如内存回收+调度延迟),可同时记录 perf 数据和 ftrace 日志,通过时间轴工具(如 Trace Compass)关联分析[^1][^4]。 ---
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值