Arnaldo,
I think the -n option of perf report shows bogus number of samples.
I believe it does not print the number of samples but rather the
number of events if I understand the code in hist_entry__snprintf().
I think that's useless, the number of samples is more useful.
$ perf report -h
usage: perf report [<options>] <command>
-i, --input <file> input file name
-v, --verbose be more verbose (show symbol address, etc)
-D, --dump-raw-trace dump raw trace in ASCII
-k, --vmlinux <file> vmlinux pathname
--kallsyms <file>
kallsyms pathname
-f, --force don't complain, do it
-m, --modules load module symbols - WARNING: use only with
-k and LIVE kernel
-n, --show-nr-samples
Show a column with the number of samples
$ perf record -e cycles ./repmov
$ perf report -D | fgrep RECORD_SAMPLE | wc -l
86346
$ ./perf report -n
# Events: 86K cycles
#
# Overhead Samples Command Shared Object Symbol
# ........ .......... ....... ................. .........................
#
98.92%238206388334 repmov repmov [.] main
0.08% 189506224 repmov [kernel.kallsyms] [k] perf_ctx_adjust_freq
0.06% 147582706 repmov [kernel.kallsyms] [k] perf_event_task_tick
It should be easy to reproduce with any other program.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
