标签: perf

我最近在我的平台上安装了 Perf 工具，并想用它来分析我的平台。我开始分析一个独立的应用程序。我使用了下面的命令

性能启动./helloworld

“./helloworld”的性能计数器统计信息：

  4.555957 task-clock                #    0.000 CPUs utilized
         1 context-switches          #    0.219 K/sec
         0 cpu-migrations            #    0.000 K/sec
       124 page-faults               #    0.027 M/sec
       <not supported> cycles
       <not supported> stalled-cycles-frontend
       <not supported> stalled-cycles-backend
       <not supported> instructions
       <not supported> branches
       <not supported> branch-misses

       60.005519331 seconds time elapsed

现在我不确定应该如何解释这个输出。它是预期的输出吗？

另外，我应该如何处理此处提交的<不支持>，在运行命令之前我需要启用什么来支持此提交吗？

perf15 天以来我一直面临着一个相关问题。希望这里的大佬们能帮我解决这个问题。

我需要让perf工具在具有 ARM 架构的设备上运行。但是，在记录跟踪点事件然后运行./perf报告时，它显示共享对象名称为[unknown]，符号为00000，而对于软件和硬件事件，我没有遇到此问题。我已经交叉编译了perfmailine上可用的工具并将其移植到具有ARM架构的设备上。

在内核 3.4 的基于 ARM 的设备上输出。

./perf record -e kmem:kmalloc cal

[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.007 MB perf.data (~321 samples) ]

./perf report 

Overhead        Command          Shared Object                  Symbol
.......     .............      ..............               ...............
40.78%           cal                [unknown]                [.]00000000
31.6%            cal                [unknown]                [.]00000000

[...]

在 ubuntu 12.04 系统（内核 3.10）上它工作得很好。

x86 架构上的输出

./perf record -e kmem:kmalloc …

我想测量 C++ 原子 fetch_add 在不同设置下花费的时间。我写了这样的东西：

atomic<uint64_t> x(0);
for (uint64_t i = 0; i < REPS; i+=1g) {
  x.fetch_add(1);
} 

因此，如果REPS足够高，我认为能够对fetch_add发生的情况。首先，我需要验证大部分时间确实花费在 fetch_add 中，而不是循环开销等。所以我运行 perf 来做到这一点。

这是来自 objdump 的程序集：

400ed0:       b8 00 b4 c4 04          mov    $0x4c4b400,%eax
400ed5:       0f 1f 00                nopl   (%rax)
400ed8:       f0 83 05 7c 22 20 00    lock addl $0x1,0x20227c(%rip)
400edf:       01 
400ee0:       83 e8 01                sub    $0x1,%eax
400ee3:       75 f3                   jne    400ed8 <_Z10incrsharedv+0x8>

perf （对于周期事件）表示 100% 的周期进入，这与我所期望的或跳跃sub $0x1,%eax相反。lock addl $0x1,0x20227c(%rip) …

有谁知道为什么 perf 总是显示 _raw_spin_unlock_irqrestore 或其他一些自旋解锁功能？与 spin_lock 相比， spin_unlock 实现通常更简单。如果 spin_lock 上存在高竞争，那么 perf 不应该在 spin_lock 中显示结果吗？

我有一个在 aws ubuntu 实例上运行的 node.js 应用程序。我试图生成火焰图dtrace，linux perf tools但它们似乎都不起作用。这些是我遵循的步骤：

linux性能工具：https : //www.carlhopf.com/blog/2016/09/11/nodejs-cpu-profiling-production/

dtrace: https://nodejs.org/en/blog/uncategorized/profiling-node-js/

我已经--prof / --perf_basic_prof_only_functions为 linux perf 工具命令添加了启动应用程序的同时。

我从 dtrace stacks.out 文件得到的输出是：

CPU     ID                    FUNCTION:NAME
  0 330511                        :tick-60s 

安装dtrace如下：https : //askubuntu.com/questions/60940/how-do-i-install-dtrace

当我尝试将 linux perf 命令的输出转换为火焰图时得到的输出是

ERROR: No stack counts found

我不确定缺少什么以及为什么没有记录堆栈跟踪。 node version: 8.4.0 ubuntu : 14.04 我确实看到有Systemtap可用选项并且可以使用此命令：

stap -s 32 -D MAXBACKTRACE=100 -D MAXSTRINGLEN=4096 -D MAXMAPENTRIES=10240 \
    -D MAXACTION=10000 -D STP_OVERLOAD_THRESHOLD=5000000000 --all-modules \
    -ve 'global s; …

有明显一些Linux专柜perf一样syscall:sys_enter_select，但我的系统上perf list不显示任何人

其他人确实有这些计数器的证据在这里：http : //www.brendangregg.com/blog/2014-07-03/perf-counting.html

如果我运行perf top -e 'syscalls:sys_enter_*'它说：

Can't open event dir: Permission denied
invalid or unsupported event: 'syscalls:sys_enter_*'

其他事件类型（ 中的perf list）工作正常。

我需要做什么来访问系统调用计数器perf？我在 x86_64 上使用 Linux 内核和 perf 版本 3.10。

我正在寻找方法来了解进程或线程花时间等待的系统调用或子系统，即阻塞而不是安排在 CPU 上运行。

具体来说，如果我有一些未知的过程，或者一个我们只知道“它很慢”的过程，我希望能够学习以下内容：

• “它花费 80% 的时间在sys_write()fd 13 上，即 /some/file”
• “它花费了大量时间等待从网络套接字读取（）”
• “它在 epoll_wait() 中休眠，用于 fds [4,5,6] 上的活动，它们是 [file /boo]、[socket 10.1.1.:42]、[notifyfd blah]”

换句话说，当我的程序不在 CPU 上运行时，它在做什么？

这是一个惊人很难与回答perf，因为它不会出现有任何方式的记录系统调用从sys_enter持续时间sys_exit或以其他方式跟踪多久的事件。大概是由于其采样性质。

我知道一些针对 Linux 4.6 及更高版本的 eBPF 的实验性工作可能会有所帮助，Brendan Gregg 的off-cpu 工作。但在悲惨的运维世界中，支持 4.6 内核的独角兽却是难得一见的珍贵。

现实世界的选择是什么？

ftrace、systemtap 等在这里提供任何见解吗？

TL;DR我有一个循环需要 1 个周期才能在 Skylake 上执行（它执行 3 次加法 + 1 次增加/跳跃）。

当我展开它超过 2 次（无论多少）时，我的程序运行速度会慢 25%。这可能与对齐有关，但我不清楚是什么。

编辑：这个问题曾经询问为什么 uops 是由 DSB 而不是 MITE 提供的。这现在已经转移到这个问题上。

我试图对一个循环进行基准测试，该循环在我的 Skylake 上添加了 3 个。这个循环应该在一个周期内执行，因为 3 add + 1 increment 与条件跳转融合，一旦融合可以在一个周期内执行。正如预期的那样。

然而，在某些时候，我的 C 编译器试图展开该循环，从而产生更差的性能。我现在试图理解为什么展开循环的性能比非展开循环更差，因为我希望两者具有相同的性能，或者展开循环的速度可能会慢 15%以下。

这是我的 C 代码：

int main() {
  int a, b, c, d;

  #pragma unroll(2)
  for (unsigned long i = 0; i < 2000000000; i++) {
    asm volatile("" : "+r" (a), "+r" (b), "+r" (c), "+r" (d));
    a = …

我正在perf_event_opensyscall之上进行自定义实现。

实施旨在支持各种的PERF_TYPE_HARDWARE，PERF_TYPE_SOFTWARE和PERF_TYPE_HW_CACHE事件上的任何核心特定的线程。

在英特尔® 64 位和 IA-32 架构软件开发人员手册第 3B 卷中，我看到以下用于测试 CPU (Kaby Lake) 的内容：

到目前为止，我的理解是，可以同时监视（理论上）无限的PERF_TYPE_SOFTWARE事件，但同时监视有限的（没有多路复用）PERF_TYPE_HARDWARE和PERF_TYPE_HW_CACHE事件，因为每个事件都是通过 CPU 的 PMU 计数器的有限（如上面的手册中所见）数量来衡量的。

因此，对于启用了超线程的四核 Kaby Lake CPU，我假设最多可以同时监视4 个PERF_TYPE_HARDWARE/PERF_TYPE_HW_CACHE事件（如果仅使用 4 个线程，则最多可监视 8 个）。

对上述假设进行试验后，我发现虽然我最多可以成功监控 4 个PERF_TYPE_HARDWARE事件（8 个线程），但对于PERF_TYPE_HW_CACHE最多只能同时监控 2 个事件的事件，情况并非如此！

我还尝试仅使用 4 个线程，但同时监控的“PERF_TYPE_HARDWARE”事件的上限仍然为 4。禁用超线程也会发生同样的情况！

有人可能会问：为什么需要避免多路复用。首先，实现需要尽可能准确，避免多路复用的潜在盲点，其次，当超过“上限”时，所有事件值都为 0...

PERF_TYPE_HW_CACHE我针对的事件是：

CACHE_LLC_READ(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | PERF_HW_CACHE_OP_ID.PERF_COUNT_HW_CACHE_OP_READ.value << 8 | PERF_HW_CACHE_OP_RESULT_ID.PERF_COUNT_HW_CACHE_RESULT_ACCESS.value << 16),
CACHE_LLC_WRITE(PERF_HW_CACHE_TYPE_ID.PERF_COUNT_HW_CACHE_LL.value  | …

我将 nodejs 应用程序（作为服务器）部署为 Docker 容器，我想在调用其中的函数时计算已执行指令的数量。

以下是我如何找到容器的 PID：

$ pstree -p | grep node | grep npm
           |                 |-containerd-shim(114397)-+-npm(114414)-+-sh(114540)---node(114541)-+-{node}(114542)

然后，我需要知道 Docker ID：

$ docker ps | grep workload
root@node3:/home/m# docker ps | grep workload | grep npm
c7457f74536b        michelgokan/synthetic-workload-generator                   "npm start"              55 minutes ago      Up 55 minutes                           k8s_whatever_workload-5697bb48f9-gg8j5_default_896e5938-55f2-4875-bf6c-2bff2acbe0c6_0

现在，我知道父 PID 是 114397。所以我运行以下perf命令：

$ perf stat -p 114397 -e instructions,cycles,task-clock docker exec -it c7457f74536b curl 127.0.0.1:30005/workload/cpu
1000 CHKSM AND DIFFIEHELLMAN 60 OK!
 Performance counter stats for process id '114397':

         170057460 …