* Neil Horman <nhor...@tuxdriver.com> wrote:
> So, I apologize, you were right. I was running the test.sh script
> but perf was measuring itself. [...]
Ok, cool - one mystery less!
> Which overall looks alot more like I expect, save for the parallel
> ALU cases. It seems here that the parallel ALU changes actually
> hurt performance, which really seems counter-intuitive. I don't
> yet have any explination for that. I do note that we seem to have
> more stalls in the both case so perhaps the parallel chains call
> for a more agressive prefetch. Do you have any thoughts?
Note that with -ddd you 'overload' the PMU with more counters than
can be run at once, which introduces extra noise. Since you are
running the tests for 0.150 secs or so, the results are not very
representative:
734 dTLB-load-misses # 0.00% of all dTLB cache hits
( +- 8.40% ) [13.94%]
13,314,660 iTLB-loads # 280.759 M/sec
( +- 0.05% ) [12.97%]
with such low runtimes those results are very hard to trust.
So -ddd is typically used to pick up the most interesting PMU events
you want to see measured, and then use them like this:
-e dTLB-load-misses -e iTLB-loads
etc. For such short runtimes make sure the last column displays
close to 100%, so that the PMU results become trustable.
A nehalem+ PMU will allow 2-4 events to be measured in parallel,
plus generics like 'cycles', 'instructions' can be added 'for free'
because they get counted in a separate (fixed purpose) PMU register.
The last colum tells you what percentage of the runtime that
particular event was actually active. 100% (or empty last column)
means it was active all the time.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
