Searched hist:"19 f47402" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/tools/perf/ |
| H A D | builtin-stat.c | 19f47402 Wed Sep 07 18:14:01 CDT 2011 Jim Cromie <jim.cromie@gmail.com> perf stat: Fix +- nan% in --no-aggr runs
Without this patch, running:
$ sudo ./perf stat -r20 --no-aggr -a perl -e '$i++ for 1..100000'
I get computations like this:
CPU0 12.488247 task-clock # 1.224 CPUs utilized ( +- -nan% )
CPU1 12.488909 task-clock # 1.225 CPUs utilized ( +- -nan% )
CPU2 12.500221 task-clock # 1.226 CPUs utilized ( +- -nan% )
CPU3 12.481713 task-clock # 1.224 CPUs utilized ( +- -nan% )
but with patch, I get:
CPU0 8.233682 task-clock # 0.754 CPUs utilized ( +- 0.00% )
CPU1 8.226318 task-clock # 0.754 CPUs utilized ( +- 0.00% )
CPU2 8.210737 task-clock # 0.752 CPUs utilized ( +- 0.00% )
CPU3 8.201691 task-clock # 0.751 CPUs utilized ( +- 0.00% )
Note that without --no-aggr, I get non-0 statistics both before and after patch:
231.986022 task-clock # 4.030 CPUs utilized ( +- 0.97% )
212 context-switches # 0.001 M/sec ( +- 12.07% )
9 CPU-migrations # 0.000 M/sec ( +- 25.80% )
466 page-faults # 0.002 M/sec ( +- 3.23% )
174,318,593 cycles # 0.751 GHz ( +- 1.06% )
I couldnt see anything wrong in the caller, so fixed it in
stddev_stats(). ISTM that 0.00 is better than nan, since perf stat was
passed -A (--no-aggr) so no standard deviation should be expected, and
nan is suggestive of a deeper error.
When running with --no-aggr, perhaps we should suppress the statistics
printing entirely, or do so when they are 0.00.
Link: http://lkml.kernel.org/r/1315437244-3788-3-git-send-email-jim.cromie@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
19f47402 Wed Sep 07 18:14:01 CDT 2011 Jim Cromie <jim.cromie@gmail.com> perf stat: Fix +- nan% in --no-aggr runs
Without this patch, running:
$ sudo ./perf stat -r20 --no-aggr -a perl -e '$i++ for 1..100000'
I get computations like this:
CPU0 12.488247 task-clock # 1.224 CPUs utilized ( +- -nan% )
CPU1 12.488909 task-clock # 1.225 CPUs utilized ( +- -nan% )
CPU2 12.500221 task-clock # 1.226 CPUs utilized ( +- -nan% )
CPU3 12.481713 task-clock # 1.224 CPUs utilized ( +- -nan% )
but with patch, I get:
CPU0 8.233682 task-clock # 0.754 CPUs utilized ( +- 0.00% )
CPU1 8.226318 task-clock # 0.754 CPUs utilized ( +- 0.00% )
CPU2 8.210737 task-clock # 0.752 CPUs utilized ( +- 0.00% )
CPU3 8.201691 task-clock # 0.751 CPUs utilized ( +- 0.00% )
Note that without --no-aggr, I get non-0 statistics both before and after patch:
231.986022 task-clock # 4.030 CPUs utilized ( +- 0.97% )
212 context-switches # 0.001 M/sec ( +- 12.07% )
9 CPU-migrations # 0.000 M/sec ( +- 25.80% )
466 page-faults # 0.002 M/sec ( +- 3.23% )
174,318,593 cycles # 0.751 GHz ( +- 1.06% )
I couldnt see anything wrong in the caller, so fixed it in
stddev_stats(). ISTM that 0.00 is better than nan, since perf stat was
passed -A (--no-aggr) so no standard deviation should be expected, and
nan is suggestive of a deeper error.
When running with --no-aggr, perhaps we should suppress the statistics
printing entirely, or do so when they are 0.00.
Link: http://lkml.kernel.org/r/1315437244-3788-3-git-send-email-jim.cromie@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|