标签: perf

更准确地说，perf 工具如何将 PMU 事件与函数关联起来，我已经意识到，当内核 perf 子系统记录事件计数器时，它还会记录程序计数器 (PC)，因此它可以将计数与函数关联起来。

然而，要真正获得细粒度结果，您需要以非常高的速率对计数器进行采样，否则您可能会将计数器与一组函数相关联。但是读取计数器并将采样数据（计数器、PC、调用堆栈）写入 perf mmap 空间是非常侵入性的。

我在一些资料中读到，这种采样仅在 PMU 计数器溢出时发生，但这可能非常粗糙，除非我将计数器设置为非常快地溢出

我在这里缺少什么？

我有 Docker for Mac 和 LinuxKit 内核版本4.9.125-linuxkit。

perf在主机上不可用。我尝试将其安装在我的 Ubuntu 容器之一上，但无法获取内核linux-tools的版本控制包4.9.125。所以当我尝试运行 perf 时，我只是得到

WARNING: perf not found for kernel 4.9.125

有没有办法perf在我的 LinuxKit/Hyperkit 主机上运行？如果可以，如何运行？

当我使用 perf 进行分析时，_PyEval_EvalFrameDefaultCPU 使用率位于顶部。

但我不知道那是什么。我怎样才能避免这个功能？

在后处理期间如何perf确定每个加载图像（例如共享库）的加载地址。例如，perf report使用此信息使每个符号地址相对于每个加载图像的开头。如下图所示 ( unwind: _int_malloc...)：

它是否存储在elf二进制或分析输出中的某个位置（即perf.data）？

L3-misses我使用以下命令在简单的基准测试中提取导致用户级别的回溯evince：

sudo perf record -d --call-graph dwarf -c 10000 -e mem_load_uops_retired.l3_miss:uppp /opt/evince-3.28.4/bin/evince

很明显，采样周期相当大（连续采样之间有 10000 个事件）。对于这个实验， 的输出perf script有一些与此类似的样本：

EvJobScheduler 27529 26441.375932:      10000 mem_load_uops_retired.l3_miss:uppp:     7fffcd5d8ec0         5080022 N/A|SNP N/A|TLB N/A|LCK N/A
    7ffff17bec7f bits_image_fetch_separable_convolution_affine+0x2df (inlined)
    7ffff17bec7f bits_image_fetch_separable_convolution_affine_pad_x8r8g8b8+0x2df (/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
    7ffff17d1fd1 general_composite_rect+0x301 (/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0)
  ffffffffffffffff [unknown] ([unknown])

在回溯的底部，有一个名为 的符号[unknown]，看起来没问题。但随后就呼叫了线路general_composite_rect()。这个回溯OK吗？

AFAIK，回溯中的第一个调用者应该是类似_start()或 的东西__GI___clone()。但回溯不是这种形式。怎么了？

有什么办法可以解决这个问题吗？截断的（部分）回溯可靠吗？

我perf曾经用perf record ./application. perf report向我展示了有关它的各种事情。如何显示运行应用程序所需的总时间以及运行特定“符号”/功能的总时间？perf 似乎经常显示百分比，但我想要原始时间，并且它想要“包容性”时间，即包括孩子。

Ubuntu Linux 18.04 上的 perf v4.15.18

下面是一个代码块，perf record 标记为造成所有 L1-dcache 未命中的 10%，但该块完全是 zmm 寄存器之间的移动。这是 perf 命令字符串：

perf record -e L1-dcache-load-misses -c 10000 -a -- ./Program_to_Test.exe

代码块：

Round:
vmulpd zmm1,zmm0,zmm28
VCVTTPD2QQ zmm0{k7},zmm1
VCVTUQQ2PD zmm2{k7},zmm0
vsubpd zmm3,zmm1,zmm2
vmulpd zmm4,zmm3,zmm27
VCVTTPD2QQ zmm5{k7}{z},zmm4

VPCMPGTQ k2,zmm5,zmm26
VPCMPEQQ k3 {k7},zmm5,zmm26
KADDQ k1,k2,k3

VCVTQQ2PD zmm2{k7},zmm0
VDIVPD zmm1{k7},zmm2,zmm28 ; Divide by 100
VPXORQ zmm2{k7},zmm2,zmm2
vmovupd zmm2,zmm1
VADDPD zmm2{k1},zmm1,zmm25

对于该代码块，我使用其他 L1 度量（例如 l1d.replacement）得到了类似的结果。

我的问题是，一个仅是 zmm 寄存器移动的块如何会产生 L1 缓存未命中？我认为寄存器根本不会进入内存。事实上，最后一次内存访问是在该代码块之上的10条指令；其他9条指令都是寄存器到寄存器指令。

为了测量程序中缓存未命中的影响，我想要计算缓存未命中对用于实际计算的周期造成的延迟。\n我用它来perf stat测量周期、L1 负载、L1 未命中、LLC 负载和 LLC - 我的程序中遗漏了。这是一个示例输出：

               467\xe2\x80\xaf769,70 msec task-clock                #    1,000 CPUs utilized          \n        1\xe2\x80\xaf234\xe2\x80\xaf063\xe2\x80\xaf672\xe2\x80\xaf432      cycles                    #    2,638 GHz                      (62,50%)\n          572\xe2\x80\xaf761\xe2\x80\xaf379\xe2\x80\xaf098      instructions              #    0,46  insn per cycle           (75,00%)\n          129\xe2\x80\xaf143\xe2\x80\xaf035\xe2\x80\xaf219      branches                  #  276,083 M/sec                    (75,00%)\n            6\xe2\x80\xaf457\xe2\x80\xaf141\xe2\x80\xaf079      branch-misses             #    5,00% of all branches          (75,00%)\n          195\xe2\x80\xaf360\xe2\x80\xaf583\xe2\x80\xaf052      L1-dcache-loads           #  417,643 M/sec                    (75,00%)\n           33\xe2\x80\xaf224\xe2\x80\xaf066\xe2\x80\xaf301      L1-dcache-load-misses     #   17,01% of all L1-dcache hits    (75,00%)\n           20\xe2\x80\xaf620\xe2\x80\xaf655\xe2\x80\xaf322      LLC-loads                 #   44,083 M/sec                    (50,00%)\n            6\xe2\x80\xaf030\xe2\x80\xaf530\xe2\x80\xaf728      LLC-load-misses           #   29,25% of all LL-cache hits     (50,00%)\n

那么我的问题是：\n如何将缓存未命中数转换为“丢失”时钟周期数？ …

我很难解释英特尔性能事件报告。

考虑以下主要读/写内存的简单程序：

#include <stdint.h>\n#include <stdio.h>\n\nvolatile uint32_t a;\nvolatile uint32_t b;\n\nint main() {\n  printf("&a=%p\\n&b=%p\\n", &a, &b);\n  for(size_t i = 0; i < 1000000000LL; i++) {\n    a ^= (uint32_t) i;\n    b += (uint32_t) i;\n    b ^= a;\n  }\n  return 0;\n}\n

我用gcc -O2以下命令编译它并运行perf：

#include <stdint.h>\n#include <stdio.h>\n\nvolatile uint32_t a;\nvolatile uint32_t b;\n\nint main() {\n  printf("&a=%p\\n&b=%p\\n", &a, &b);\n  for(size_t i = 0; i < 1000000000LL; i++) {\n    a ^= (uint32_t) i;\n    b += (uint32_t) i;\n    b ^= a;\n  }\n …

我试图用zap_pte_rangemm/memory.c 跟踪函数perf.但功能没有列在perf probe -F.那么有没有办法动态追踪这个功能？即明确添加跟踪点并重新编译内核？

perf probe -a zap_pte_range

得到:

没有找到构建ID为33b15ec444475ee7806331034772f61666fa6719的[kernel.kallsyms],继续没有符号

无法在内核中找到符号zap_pte_range

错误:无法添加事件.