1

Why does perf stat -a show a clock speed three times lower than my CPU is rated for?

I don't think power management is an issue, because I made sure the test ran for a whole second to allow the cpu frequency to rise to maximum.

# 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
  • Note: the CPU does not always run at peak speed. As of right now, my 3.8GHz CPU is running at 0.56GHz – Stan Strum Feb 8 '18 at 18:00
  • sure, but if you provided an entirely cpu-bound task, you would generally hope to see it crank up to 3.8Ghz. And I wouldn't expect it to take more than, say, a tenth of a second to do so. I haven't noticed power management being that intrusive before. – sourcejedi Feb 8 '18 at 18:56
  • I struggled a bit in wording the question. My assumption seeing Ghz as a comment next to cycles, was that it would represent total cycles over the measurement period. The answer (below) is that perf is allowing for programs running on more than on cpu, and it instead shows more of a per-cpu average. So it's a bit more complex that I expected, in order to better match what people probably intuitively expect when they see Ghz. – sourcejedi Feb 8 '18 at 19:12
  • that's actually very odd. I didn't think even just reading /dev/zero would do that. Very interesting! – Stan Strum Feb 8 '18 at 20:55
  • * perf is allowing for programs running on more than one cpu, sorry. IDGI, what specifically seems very odd to you? I was trying to work out why a specific metric looked flat wrong to me... with something that black and white, I was already expecting there would be some solid reasons why my assumptions were not justified, and learning these would educate me. – sourcejedi Feb 8 '18 at 21:54
1

The Ghz value in perf stat -a does not show the cycles per second. 4,719,000 cycles divided by 0.0016 seconds is 2.9Ghz, not 0.76Ghz.

I guess what perf shows is an average of the cycles per second on each cpu core. Dividing 2.9Ghz by 0.76Ghz gives 3.8. This is not quite a whole number of cpus, but it's about right. I notice it exactly matches the strange "CPUs utilized" figure above.


Compare perf stat without -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 also, the cycles reported by perf stat -a don't exactly represent productive computation. perf record -a followed by perf report showed the top hotspot as follows:

# 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
...

I.e., although the cpu frequency is being lowered on idle cores, the cycles counted by perf appear also appear to include a large number "spent" while the kernel has halted the CPU and entered a cpu idle state.

(Or at least the kernel was trying to put the cpu in a low-power idle state. I don't know if perf interrupts the cpu often enough to completely interfere with idling).

  • In case perf does not document how it computes those figures, it would be interesting to read its source code to find out a definite answer. – dhag Feb 8 '18 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.