Por que 'perf stat -a' mostra o clock (Ghz) menor do que a minha cpu está classificada?

Question

Por que perf stat -a mostra uma velocidade de clock três vezes menor do que a minha CPU está classificada?

Eu não acho que o gerenciamento de energia é um problema, porque eu me certifiquei de que o teste fosse executado por um segundo inteiro para permitir que a frequência da CPU subisse ao máximo.

# time perf stat -a -r 500  mount --make-rprivate /mnt/a

 Performance counter stats for 'system wide' (500 runs):

          6.217301      cpu-clock (msec)          #    3.782 CPUs utilized            ( +-  0.63% )
                 6      context-switches          #    0.998 K/sec                    ( +-  1.31% )
                 0      cpu-migrations            #    0.018 K/sec                    ( +- 15.14% )
               122      page-faults               #    0.020 M/sec                    ( +-  0.04% )
         4,719,129      cycles                    #    0.759 GHz                      ( +-  1.93% )
         3,998,374      instructions              #    0.85  insn per cycle           ( +-  0.44% )
           805,593      branches                  #  129.573 M/sec                    ( +-  0.44% )
            22,548      branch-misses             #    2.80% of all branches          ( +-  0.26% )

       0.001644054 seconds time elapsed                                          ( +-  0.62% )


real    0m1.152s
user    0m0.386s
sys 0m0.824s

# rpm -q perf
perf-4.14.16-300.fc27.x86_64

    

Answer 1

O valor de Ghz em perf stat -a não mostra os ciclos por segundo. 4.719.000 ciclos divididos por 0,0016 segundos são 2,9 GHz, não 0,76 Ghz.

Eu acho que perf mostra uma média dos ciclos por segundo em cada núcleo da cpu . Dividindo 2.9Ghz por 0.76Ghz dá 3.8. Este não é um número inteiro de CPUs, mas está certo. Eu percebo que isso corresponde exatamente à figura estranha "CPUs utilizadas" acima.

Comparar perf stat sem -a :

# time perf stat -r 500  mount --make-rprivate /mnt/a

 Performance counter stats for 'mount --make-rprivate /mnt/a' (500 runs):
      1.323450      task-clock (msec)         #    0.812 CPUs utilized            ( +-  0.84% )
             0      context-switches          #    0.008 K/sec                    ( +- 44.54% )
             0      cpu-migrations            #    0.000 K/sec                  
           122      page-faults               #    0.092 M/sec                    ( +-  0.04% )
     2,668,696      cycles                    #    2.016 GHz                      ( +-  0.28% )
     3,090,908      instructions              #    1.16  insn per cycle           ( +-  0.04% )
       611,827      branches                  #  462.297 M/sec                    ( +-  0.03% )
        20,252      branch-misses             #    3.31% of all branches          ( +-  0.09% )

   0.001630517 seconds time elapsed                                          ( +-  0.82% )


real    0m1.089s
user    0m0.378s
sys 0m0.715s

Note também que os ciclos relatados por perf stat -a não representam exatamente o cálculo produtivo. perf record -a seguido por perf report mostrou o melhor ponto de acesso da seguinte forma:

# perf record -a sh -c "for i in {1..500}; do mount --make-rprivate /mnt/a; done"
...
# perf report
...
  19.40%  swapper          [kernel.kallsyms]           [k] intel_idle
...

Ou seja, embora a freqüência cpu esteja sendo reduzida em núcleos ociosos, os ciclos contados por perf aparecem também parecem incluir um grande número "gasto" enquanto o kernel parou a CPU e digitou um cpu estado ocioso.

(Ou pelo menos o kernel estava tentando colocar a cpu em um estado ocioso de baixa energia. Eu não sei se perf interrompe a cpu com freqüência suficiente para interferir completamente com a ociosidade) .