问题标签 [perf]

我正在尝试使用性能记录来记录 15 个硬件和跟踪点事件。

我想了解以下内容：

1. 基于事件的采样：从我理解的文档中，每当与该事件对应的 64 位计数器溢出时，性能记录就会采样。是对的吗？计数器会在 ~ 2^64 次此类事件后溢出吗？

2. 当我要测量的事件多于 PMU/计数器的数量时，我是否必须通过任何特定的开关才能使用多路复用。在存在多路复用的情况下溢出事件如何表现。

3. 开关“-c”的目的/用途是什么？我可以使用此开关使计数器溢出每个 n 事件吗？

请帮忙。

我必须分析我的多线程 C++ 应用程序并找到它的瓶颈。问题是：我需要查看挂钟配置文件。我用过oprofile和perf。没有人可以向我提供这样的信息。

我使用过perf record -g -e sched:sched_stat_sleep <cmd>但perf record属于 SIGFPE 异常。这让我很生气。

Valgrind不适合我，因为我使用fanotify_mark了未在此工具中实现的系统调用。

我不确定谷歌是否perftools可以进行挂钟分析 - 我在他们的文档中没有看到任何信息。

任何人都可以建议吗？谢谢你。

我正在使用perf工具来分析排序实用程序。我给出了以下命令。

我想将排序的输出重定向到/dev/nullperf 的输出到 perf_data 文件。

我怎样才能做到这一点 ？

我想为我的 Android 应用程序使用 __NR_perf_event_open 的系统调用。

该代码在 linux 上正常运行，但在 Android 上无法运行。

但是，fd 始终返回值 -1。当我使用“errno.h”时，它给出了错误信息：EBADF：bad file descriptor。

我想使用 perf 工具解释我的程序的一个有趣行为。

一些背景资料

我的机器有 4 个 NUMA 节点，我的主要应用程序正在机器上运行。使用 cpusets 我对机器进行分区，为应用程序提供 3 个节点，为系统提供 1 个节点。在同一台机器上运行单元测试（用于记录改进）时，我得到了我正在尝试使用 perf 工具进行调查的意外行为。

出乎意料的行为是，在应用程序正在运行的 NUMA 节点上（比如说 node2），我在 unittest 上获得了更好的时间，大约是 unittest 在具有系统的 NUMA 节点上运行时的两倍（比如说节点 3)。看起来像在 node2 的 CPU 上运行（一个不做自旋锁的 cpu）我得到比在另一个 numa 上运行更好的结果。

我正在尝试改进我的日志记录系统，因此测试正在进行的工作也由应用程序完成，将一些日志消息写入队列以便稍后转储到磁盘（不同的线程）。对队列的争用由自旋锁 (CAS) 控制。unitest 是一个具有 2 个循环的写入器线程：100 次，将 1000 条日志写入队列，RDTSC（我的选择）用于测量每个内部循环，然后打印统计信息。队列足够大，我得到一个标准偏差，内存操作减少到最低限度（没有 memcpy）。阅读器正在转储到另一个线程上的磁盘。

我尝试停止我的应用程序并再次运行测试。在这种情况下，我看到无论选择哪个 NUMA 节点来运行我的测试，我都会得到与在 node3 上运行类似的结果（慢），这意味着如果我在同一个 numa 上运行我的测试，正在运行的应用程序正在加速我的测试应用程序运行的节点。对我来说非常不直观。

使用以下 perf 工具命令获取一些数据

并使用命令进行分析

我提取了我看到的包含一些差异的内容。 不确定我是否应该怀疑 sched-、LLC-、branch-、TLB，因为我不知道相对差异是否解释了我看到的行为。

有什么更好的调查方法的建议吗？

我使用“perf record ./exe”，它会生成文件“perf.data”；但是，当我使用“性能报告”检查数据时，它什么也没显示，为什么？我的性能版本是“0.0.2.PERF”并使用 Open suse Linux Enterprise Server 11 (x86_64)。

当我在 Ubuntu 中做同样的事情时，它运行良好，Open suse 和 Ubuntu 之间有什么区别吗？

我的工作是使用perf. 包括缓存未命中、LLC-loads、LLC-load-misses、LLC-stores、LLC-store-misses 等等，我只得到总的统计数据。

有没有办法区分它们？

Is there any way to execute a block of code in C without suffering a Context Switch?

I have modified perf stat to sample the counters periodically. While this works, it ends up giving me some bad data points such as 0 cycles x instructions.

I believe that the reason for this happening is because of context switching.

Since my code always pulls cycle counter value before instruction counter, if a context switch were to happen after pulling the cycle counter value, and if the process I was profiling executed for some portion of the scheduling quanta, then when I finally pulled the instruction counter value, it would be 'one ahead' of the cycle counter value that I already pulled.

Is there any way to execute the code-block without allowing a context switch to take place?

我有一个基于 C++ 的程序正在运行，我的问题是我想知道：

• 调用次数最多的top10、top5、topX方法是什么
• 什么是最重的计算类或哪些线程需要最大时钟周期

在 Linux 下可以使用类似或类似valgrind的工具来做到这一点吗？perf

我不应该说这个应用程序使用了许多第三方库，但我对那些不感兴趣，因为我想要修改和改进的是应用程序本身的核心，所以我可以将所有可能的方法列表缩减为实现的方法只有通过“实际应用”。

一般来说，如何检测导致分支和性能损失最大的类或方法是什么？

Suppose that I choose perf events instructions, LLC-load-misses, LLC-store-misses. Suppose further that I test a program prog varying its input. Is valgrind supposed to give me the "same" functional results for the same input and the same counter? That is, if one value in perf goes up, the one in valgrind should always do the same? Is there any impact in valgrind being a simulation that I should be aware of during profiling my code?

EDIT: BTW, before people grill me for not experimenting myself, I have to say that I (kinda) have, the problem is that I have a Sandybridge processor, and perf has a "bug" that prevents me from measuring LLC-* events. There is a patch, but I don't feel like recompiling my kernel...