Messages in this thread | | | Date | Tue, 20 Mar 2012 14:51:23 -0500 | Subject | Re: [PATCH 1/1] Fix number of events displayed in header | From | Ashay Rane <> |
| |
Hello,
The problem I am seeing is that the `perf record' output does not comform with the output of `perf stat'. For example, for `hackbench 10 process 1000', I see 19 x 10^9 cycles reported by `perf stat'. However, `perf report -n' prints "Events: 2K cycles" and `perf report -n --dso hackbench' prints "Events: 47 cycles".
The difference in the reported counts occurs for PMU events too.
$ perf stat -e cycles ./hackbench 10 process 1000 Running with 10*40 (== 400) tasks. Time: 4.039
Performance counter stats for './hackbench 10 process 1000':
19,060,433,134 cycles # 0.000 GHz
4.078210213 seconds time elapsed
$ perf record -e cycles ./hackbench 10 process 1000 Running with 10*40 (== 400) tasks. Time: 4.053 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.165 MB perf.data (~7205 samples) ]
$ perf report -n --stdio --dso hackbench # dso: hackbench # ======== # captured on: Mon Mar 12 15:14:57 2012 # hostname : iHitch # os release : 3.2.8-1-ARCH # perf version : 3.2-3 # arch : x86_64 # nrcpus online : 2 # nrcpus avail : 2 # cpudesc : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz # cpuid : GenuineIntel,6,23,10 # total memory : 2979384 kB # cmdline : /usr/bin/perf record -e cycles ./hackbench 10 process 1000 # event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, id = { 1611, 1612 } # HEADER_CPU_TOPOLOGY info available, use -I to display # HEADER_NUMA_TOPOLOGY info available, use -I to display # ======== # # Events: 47 cycles # # Overhead Samples Command Symbol # ........ .......... ......... ......... # 56.16% 24 hackbench receiver 40.21% 21 hackbench sender 3.63% 2 hackbench write@plt
# # (For a higher level overview, try: perf report --sort comm,dso) #
$
2012/3/20 Peter Zijlstra <a.p.zijlstra@chello.nl>: > On Tue, 2012-03-20 at 13:46 -0600, David Ahern wrote: >> >> Does not seem appropriate to change from number of sample events to >> period for all event types. This change assumes the event is cycles, >> cpu-clock or task-clock. > > I'm not seeing that assumption. That said, I don't see the point of the > change either.
| |