Lock elision test results
Dominik Vogt
vogt@linux.vnet.ibm.com
Tue Jul 9 05:50:00 GMT 2013
On Fri, Jul 05, 2013 at 06:21:01PM -0700, Andi Kleen wrote:
> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> >
> > What I do not understand is why thread 1 starts aborting
> > transactions at all. After all there is no conflict in the
> > write sets of both threads. The only aborts should occur because
> > of interrupts. If once the lock is used unfortunate timing
> > conditions force the code to not switch back to elision (because
> > one of the thread always uses the lock and forces the other one
> > to lock too), that would explain the observed behaviour. But
> > frankly that looks to unlikely to me, unless I'm missing some
> > important facts.
>
> You'll probably need a hardware profiler to track this down
> (assuming you have appropriate events and some way to profile them)
As far as I know, I can only do hardware sampling, i.e. check cpu
state every 100 cycles or so (but not much more often that that).
Sometimes this is good enough to pin down a problem, but I do not
get decent statistics of abort reasons. Event tracing has to be
disabled because it aborts transactions. :-(
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
More information about the Libc-alpha
mailing list