I'm experimenting with perf on a 4 socket Ivy Bridge system running Centos7 and having a hard time understanding some of the output.
A typical case is the following really simple C program
main() {
while (1) {
}
}
The following is the assembly code
main():
push %rbp
mov %rsp,%rbp
jmp 4
I name the executable sf and run perf for 10 seconds with the following performance counters
perf stat -e cpu-clock,major-faults,minor-faults,context-switches,cpu-migrations,instructions,cycles,stalled-cycles-frontend,mem-stores sf
and get the following results
9064.316086 cpu-clock (msec) # 1.000 CPUs utilized
0 major-faults # 0.000 K/sec
109 minor-faults # 0.012 K/sec
5 context-switches # 0.001 K/sec
1 cpu-migrations # 0.000 K/sec
25,983,671,864 instructions # 1.00 insn per cycle
# 0.50 stalled cycles per insn
26,018,167,454 cycles # 2.870 GHz
13,024,243,875 stalled-cycles-frontend # 50.06% frontend cycles idle
6,171,784 mem-stores # 0.681 M/sec
9.065339662 seconds time elapsed
How can there be so many mem-stores, which increase the longer I run? How can the IPC only be 1.00 and why are we stalling in the frontend when all its doing is some register activity and maybe in the worst case going to the L1?
I would expect the IPC to be at least 2 and closer to 3 and I wouldn't expect any memory stores. By the way, I had the whole machine to myself when I ran this.
My conclusion is that perf can't be trusted. Is this correct and if so are there alternatives to perf for getting correct hardware performance data?
