如何解决perf中的“不计数”问题？

PERF STAT -d ./sample.out 输出是：如何解决perf中的“不计数”问题？

Performance counter stats for './sample.out': 

      0.586266 task-clock (msec)   # 0.007 CPUs utilized   
       2 context-switches   # 0.003 M/sec     
       1 cpu-migrations   # 0.002 M/sec     
       116 page-faults    # 0.198 M/sec     
      7,35,790 cycles     # 1.255 GHz      [81.06%] 
    <not counted> stalled-cycles-frontend 
    <not supported> stalled-cycles-backend 
    <not counted> instructions    
    <not counted> branches     
    <not counted> branch-misses   
    <not supported> L1-dcache-loads:HG  
    <not counted> L1-dcache-load-misses:HG 
    <not counted> LLC-loads:HG    
    <not supported> LLC-load-misses:HG  

     0.088013919 seconds time elapsed

我了解为什么会从显示出来。但我即使是基本的计数器，如说明书，分行等。任何人都可以建议如何使其工作？

有趣的事情是：

须藤PERF STAT睡眠3

给出的输出：

Performance counter stats for 'sleep 3': 

      0.598484 task-clock (msec)   # 0.000 CPUs utilized   
       2 context-switches   # 0.003 M/sec     
       0 cpu-migrations   # 0.000 K/sec     
       181 page-faults    # 0.302 M/sec     
    <not counted> cycles     
    <not counted> stalled-cycles-frontend 
    <not supported> stalled-cycles-backend 
    <not counted> instructions    
    <not counted> branches     
    <not counted> branch-misses

须藤PERF STAT -C 1睡眠3

Performance counter stats for 'CPU(s) 1': 

     3002.640578 task-clock (msec)   # 1.001 CPUs utilized   [100.00%] 
       425 context-switches   # 0.142 K/sec     [100.00%] 
       9 cpu-migrations   # 0.003 K/sec     [100.00%] 
       5 page-faults    # 0.002 K/sec     
     7,82,97,019 cycles     # 0.026 GHz      [33.32%] 
     9,38,21,585 stalled-cycles-frontend # 119.83% frontend cycles idle [33.32%] 
    <not supported> stalled-cycles-backend 
     3,09,81,643 instructions    # 0.40 insns per cycle   
              # 3.03 stalled cycles per insn [33.32%] 
     70,15,390 branches     # 2.336 M/sec     [33.32%] 
      6,38,644 branch-misses    # 9.10% of all branches   [33.32%] 

     3.001075650 seconds time elapsed

这是为什么这个意外的工作。

谢谢

来源

2016-05-15 ANTHONY

-2

sudo perf stat -C 1 sleep 3型材一切上CPU 1，所有进程和内核代码发生。这就是为什么sudo是必需的。这也是为什么任务时钟大约为3002毫秒。

perf stat sleep 3（不需要sudo）配置文件只有sleep(1)进程本身。任务时钟在〜0.6 ms的CPU时间内进行测量。

sleep几乎没有做任何事情;大多数运行的指令都在动态链接器中。正如@ osgx的答案指出的那样，你错过了计数，因为perf在你的机器上没有足够的硬件计数器，所以它将它们复用。没有计数的计数器必须记录，而sleep正在睡眠，没有运行。

对于良好的效果，把你的微基准测试中运行至少有一百毫秒，优选〜1秒，持续良好的信噪比，这取决于柜台您计算的一个循环。

来源

2016-05-16 02:07:37

'PERF stat'不是统计抽样（HTTP： //lxr.free-electrons.com/source/tools/perf/builtin-stat.c?v=4.4 - “Builtin stat命令：给出关于任何工作负载，CPU或特定PID的**精确**性能计数器摘要概述“），它应该是hw pmu的普通计数模式，能够看到每一个事件。睡眠1和回声1都会执行很多系统调用（检查'strace sleep 1'或'ltrace sleep 1'），它们都有数十万个周期和指令。只有性能记录是统计抽样。您也可以在stat之后添加-vv标志以检查perf_events系统调用的“采样”字段。 – osgx

@osgx：我的意思是说，HW PMU本身是通过每隔50k条指令/周期/分支或其他方式触发中断来进行采样的，对吧？它不能在每个时钟周期触发中断。或者，即使对于从未翻转并触发中断的计数器，您是否能够在确切的计数后进行计数？ –

@osgx：无论如何，你的答案显然是正确的;感谢您纠正我的错误。我没有仔细观察'-C'输出以注意到它是多路复用计数器，这完全解释了OP的观察结果。 –

的perf stat -d很短节目的典型问题不在于统计抽样，但复（方括号内百分比表示[33%] - 此计数器计数只对33％左右的运行时间）。

你问你的PMU在一次监控事件太多，而PERF是无法映射所有必需的柜台在真实的硬件 - 在同一时间（PMU CPU的性能监控单元）。典型的PMU可能有类似于4个或7个或8个独立计数器的东西，但如果您启用了某些SMT技术（例如HT-HyperThreading），则数字可能会被二分为一。

当你问PERF数这么多的计数器（你有你的PERF的统计输出6个支持HW事件），它将把所有他们到更小的群体。当perf_events有机会改变它们时，例如在任务时钟周期（〜3 ms）时，内核会在某些时间点更改组。

您可以分割的较小的事件组碰上几个 - 任意数量的SW事件和每轮2-4 HW事件：

perf stat -e task-clock,page-faults,cycles,stalled-cycles-frontend 
perf stat -e task-clock,page-faults,cycles,instructions    
perf stat -e task-clock,page-faults,branches,branch-misses   
perf stat -e task-clock,page-faults,L1-dcache-load-misses:HG,LLC-loads:HG

来源

2016-06-03 06:12:15 osgx

如何解决perf中的“不计数”问题？

回答

相关问题