This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock elision test results
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 9 Jul 2013 07:50:18 +0200
- Subject: Re: Lock elision test results
- References: <20130614102653 dot GA21917 at linux dot vnet dot ibm dot com> <1372767484 dot 22198 dot 4505 dot camel at triegel dot csb> <20130703065355 dot GA4522 at linux dot vnet dot ibm dot com> <1372849432 dot 14172 dot 20 dot camel at triegel dot csb> <20130703120753 dot GA8416 at linux dot vnet dot ibm dot com> <1372857484 dot 14172 dot 195 dot camel at triegel dot csb> <20130704092941 dot GA12864 at linux dot vnet dot ibm dot com> <87vc4o4h6q dot fsf at tassilo dot jf dot intel dot com>
- Reply-to: libc-alpha at sourceware dot org
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