我正在尝试使用 docker 中的 Linux perf 命令来分析 ffmpeg。在第一次运行中，输出很好，“perf report”显示的所有函数名称都很好。在第二次运行中，它仅显示地址而不是函数名称。我正在使用一个在 docker 中运行 ffmpeg 两次的脚本。
脚本中使用的命令是：
perf record ffmpeg -y -i input.mp4 -c:v libx264 -b:v 1500k output1.mp4
sleep 5
perf record ffmpeg -y -i input.mp4 -c:v libx264 -b:v 1500k output1.mp4
运行脚本的命令：
docker run -it --privileged -v $(pwd):/cwd myDocker:someTag /cwd/my_script.sh
我注意到在第二次运行时，它在 perf.data 中找不到 libx264 库。
“perf report”的输出如下所示。非常感谢任何形式的帮助。
输出1：
# Overhead Command Shared Object Symbol
# ........ ....... .................. .........................................................
#
6.35% ffmpeg libx264.so.148 [.] x264_cabac_block_residual_rd_internal_ssse3_lzcnt
3.91% ffmpeg libx264.so.148 [.] x264_cabac_encode_decision_bmi2
3.70% ffmpeg ffmpeg [.] …据我了解，Linux的Performance Counters子系统使用该perf record命令对CPU和硬件计数器（例如高速缓存未命中）执行基于样本的分析。
如何指定采样率perf record？我在手册页上能看到的最接近的是有些隐晦的选项“ -c，--count =要采样的事件周期”，但尚不清楚这是指周期持续时间还是速率倒数周期（如果是后者，则期望的单位）。
在移动Android设备上对应用程序进行采样的“良好”采样率是多少？什么比率太低而无用，什么比率太高？
您可能已经阅读过这个问题： 如何在我的程序中获得性能以查找符号
1）我的问题是：
当我使用 perf report 时，它给出了这样的结果：
# Overhead Command Shared Object Symbol
# . .
#
99.59% test test [.] 0x000003d4
0.21% test [kernel.kallsyms] [k] __do_fault
0.10% test [kernel.kallsyms] [k] run_timer_softirq
0.10% test [kernel.kallsyms] [k] __update_cpu_load
0.01% test [kernel.kallsyms] [k] set_task_comm
0.00% test [kernel.kallsyms] [k] intel_pmu_enable_all
也就是说：perf 可以在内核中找到符号，但在我的程序中找不到符号。
我的程序在这里：
void longa()
{
int i,j;
for(i = 0; i < 1000000; i++)
j=i; //am I silly or crazy? I feel boring and desperate.
}
void foo2()
{
int i; …我想监视最后一级缓存中的缓存请求编号.我写了一个Linux模块,根据这里的教程获取这些信息.
它可以编译和运行,但输出结果总是0.换句话说,当我使用时rdmsr,它总是给我edx = 0,eax = 0.我甚至尝试了教程中的演示代码,输出仍为0.
我坚持这个问题整整一个星期.谁能帮助我指出我在程序中犯的错误？
我知道有一些现有程序在做同样的事情,但我必须知道如何自己编写代码,因为我想在Xen管理程序中监视缓存请求.我不能在Xen中使用这些工具,除非我将这些工具合并到Xen的管理程序中,这似乎更有用.
/*
* Record the cache miss rate of Intel Sandybridge cpu
* To confirm the event is correctly set!
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
/*4 Performance Counters Selector for %ecx in insn wrmsr*/
#define PERFEVTSEL0 0x186
#define PERFEVTSEL1 0x187
#define PERFEVTSEL2 0x188
#define PERFEVTSEL3 0x189
/*4 MSR Performance Counter for the above selector*/
#define PMC0 …我安装了perf，但是当我尝试使用它时会显示此消息
内核地址映射（/ proc / {kallsyms，modules}）受限制。在运行“性能记录”之前，请检查/ proc / sys / kernel / kptr_restrict。
由于找不到合适的kallsyms或vmlinux，因此无法解析内核样本。
内核模块中的样本也无法解析。
还尝试了GTK，但它显示此消息
已请求GTK浏览器，但找不到libperf-gtk.so
我该怎么办？
我使用命令使用perf stat采取基于时间的测量:
$ perf stat -x, -I 100 -oout.txt -e cache-misses:u find / -name file
采集的样本并不总是增加.有些措施低于前一个措施.这是一个例子:
0.100225621,1103127,cache-misses:u
0.200583165,1098697,cache-misses:u
0.300825858,1093229,cache-misses:u
0.401061818,1307353,cache-misses:u
0.501293039,1271823,cache-misses:u
0.601531048,968170,cache-misses:u
0.701913069,986001,cache-misses:u
0.802181430,1080398,cache-misses:u
0.902453753,1312237,cache-misses:u
1.002721050,1276197,cache-misses:u
1.102988175,1263220,cache-misses:u
1.203292647,1201003,cache-misses:u
1.228879941,275942,cache-misses:u
第一个指标是1103127,而第二个指标是1098697,低于前一个指标.
它是一个性能缺陷还是有任何解释？
这两个工具都是 Linux 性能和分析探测工具。我发现“perf”看起来更强大，因为它可以追溯到内核调用级别。所以我的问题是，有了“perf”，是否还需要学习和保留“gprof”/
我的意思是，有没有什么工作只能用 gprof 才能完成，而 perf 却不能很好地工作？
PAPI_L1_LDMpapi和L1-dcache-load-missesperf有什么区别？
我使用了相同的设置，例如此处的帖子。
因此，结果我得到了木瓜籽：
PAPI_L1_DCM: 515 <- L1 data cache miss (probably L1D_READ_MISSES_ALL + L1D_READ_MISSES_RETRIED?)
PAPI_L1_ICM: 300 <- L1 Instruction cache miss
PAPI_L1_LDM: 441 <- L1 Load data miss
PAPI_L1_TCM: 815 <- L1 Total cache miss
不幸的PAPI_L1_DCA是，这台机器不支持。
对于perf（仅在用户空间中，因为papi仅测量用户空间，而没有内核空间）：调用： perf stat -B -e L1-dcache-load-misses:u,cache-misses:u ./perf
16,539 L1-dcache-load-misses
128 cache-misses:u
16,539似乎更合理N=1000000。装入数据丢失（在papi中为PAPI_L1_LDM）和数据缓存未命中（在papi中为PAPI_L1_DCM）之间有什么区别？为什么这些数字在papi和perf中有所不同？是cache-misses:u在PERF有关L2缓存缺失？
编辑：硬件（至强E5-2600 v3系列，Haswell-EP 12核）
我正在尝试perf在我的设备上使用 AMD cpu，但我真的找不到任何关于如何cache-misses从 AMD获取的信息。我读到你需要写-e rNNN，NNN事件的十六进制代码在哪里，但我没有找到任何表格或其他东西来查看这些代码。你能帮我解决这个问题吗，因为互联网上似乎根本没有任何信息！实际上，在手册中perf有一些链接，但它们无效:(
我试图了解“perf”输出中“cycles”事件的复用和缩放。
以下是 perf 工具的输出：
144094.487583 task-clock (msec) # 1.017 CPUs utilized
539912613776 instructions # 1.09 insn per cycle (83.42%)
496622866196 cycles # 3.447 GHz (83.48%)
340952514 cache-misses # 10.354 % of all cache refs (83.32%)
3292972064 cache-references # 22.854 M/sec (83.26%)
144081.898558 cpu-clock (msec) # 1.017 CPUs utilized
4189372 page-faults # 0.029 M/sec
0 major-faults # 0.000 K/sec
4189372 minor-faults # 0.029 M/sec
8614431755 L1-dcache-load-misses # 5.52% of all L1-dcache hits (83.28%)
156079653667 L1-dcache-loads # 1083.223 M/sec (66.77%)
141.622640316 seconds …