-
Jim Cromie authored
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.comSigned-off-by:Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Jim Cromie <jim.cromie@gmail.com> Signed-off-by:
19f47402
