Perf工具统计输出:多路复用和缩放“周期”

时间:2018-01-24 04:24:31

标签: linux performance linux-kernel tracing perf

我试图理解“perf”输出中“循环”事件的多路复用和缩放。

以下是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 time elapsed

我知道内核使用多路复用来为每个事件提供访问硬件的机会;因此最终输出是估计值。

“周期”事件显示(83.48%)。我想知道这个数字是如何得出的?

我在Intel(R)Xeon(R)CPU E5-2698 v4 @ 2.20GHz上运行“perf”。

2 个答案:

答案 0 :(得分:4)

彼得·科德斯的回答是正确的。

PMU事件非常复杂,计数器数量有限,某些事件特殊,某些逻辑事件可能由多个硬件事件组成,甚至事件之间可能存在冲突。

我相信Linux并不知道这些限制,它只是尝试从列表中激活事件 - 更精确的事件组。如果它无法激活所有事件,它将停止,并激活多路复用。每当多路复用定时器结束时,它将有效地旋转事件列表,现在开始激活第二个,然后是第三个,...... Linux不知道它仍然可以激活循环事件,因为它是特殊的。 / p>

通过在名称后面添加:D,几乎没有记录选项来固定某些事件以赋予它们优先权。我系统上的示例:

$ perf stat -e cycles -e instructions -e cache-misses -e cache-references -e  L1-dcache-load-misses -e L1-dcache-loads ...

   119.444.297.774      cycles:u                                                      (55,88%)
   130.133.371.858      instructions:u            #    1,09  insn per cycle                                              (67,81%)
        38.277.984      cache-misses:u            #    7,780 % of all cache refs      (72,92%)
       491.979.655      cache-references:u                                            (77,00%)
     3.892.617.942      L1-dcache-load-misses:u   #   15,57% of all L1-dcache hits    (82,19%)
    25.004.563.072      L1-dcache-loads:u                                             (43,85%)

固定指令和周期:

$ perf stat -e cycles:D -e instructions:D -e cache-misses -e cache-references -e  L1-dcache-load-misses -e L1-dcache-loads ...
   120.683.697.083      cycles:Du                                                   
   132.185.743.504      instructions:Du           #    1,10  insn per cycle                                            
        27.917.126      cache-misses:u            #    4,874 % of all cache refs      (61,14%)
       572.718.930      cache-references:u                                            (71,05%)
     3.942.313.927      L1-dcache-load-misses:u   #   15,39% of all L1-dcache hits    (80,38%)
    25.613.635.647      L1-dcache-loads:u                                             (51,37%)

导致与省略循环和指令相同的多路复用:

$ perf stat -e cache-misses -e cache-references -e  L1-dcache-load-misses -e L1-dcache-loads ...

    35.333.318      cache-misses:u            #    7,212 % of all cache refs      (62,44%)
   489.922.212      cache-references:u                                            (73,87%)
 3.990.504.529      L1-dcache-load-misses:u   #   15,40% of all L1-dcache hits    (84,99%)
25.918.321.845      L1-dcache-loads:u

请注意,您还可以对事件(-e \{event1,event2\})进行分组 - 这意味着事件总是一起读取 - 如果组合无法一起激活,则根本不会。

1:可以随时添加软件事件的例外情况。内核代码的相关部分位于kernel/events/core.c

答案 1 :(得分:2)

IDK为什么<?php $count = DB::table('referral_user')->where('referer_id')->count(); echo $count; ?> cycles有任何多路复用,因为CPU上有这两个事件的专用计数器,无法编程计算其他任何事件。

但是对于其他人来说,我很确定百分比是以 CPU时间的比例计算的。有一个硬件计数器计算该事件。

e.g。 instructions计算为程序运行的144094.487583 CPU毫秒的83.26%,或~119973.07 ms。总计数是从计算时间推断出来的。