This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Lock elision test results


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]