This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 12 Jun 2013 09:49:48 +0200
- Subject: Re: [RFC] Lock elision implementation guidelines
- References: <1360527652 dot 3065 dot 11521 dot camel at triegel dot csb> <1370618459 dot 16968 dot 11300 dot camel at triegel dot csb> <20130610114346 dot GA1384 at linux dot vnet dot ibm dot com> <877gi06yc1 dot fsf at tassilo dot jf dot intel dot com>
- Reply-to: vogt at linux dot vnet dot ibm dot com
On Tue, Jun 11, 2013 at 04:07:26PM -0700, Andi Kleen wrote:
> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> >
> > The attached program suffers from a massive performance loss
> > caused by lock elision.
>
> FWIW with TSX the difference between elision/no elision for your
> test is within the measurement inaccuracy.
It probably depends on the hardware implementation details of the
HTM system. The idea of the test program was to "break" a HTM
that aborts a transaction that writes a memory cell if that cell
is read afterwards from another transaction or outside a
transaction. This is the case for the zEC12, but I don't know the
details of TSX very well, and I only have access to a
z/architecture machine. Is there any document available where I
can look up the TSX implementation details?
(And although the test program does suffer from a substantial
slowdown on the zEC12, the explanation for that might be different
from what I thought.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany