Re: Lock elision test results

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

On Tue, Jul 02, 2013 at 02:18:04PM +0200, Torvald Riegel wrote:
> On Fri, 2013-06-14 at 12:26 +0200, Dominik Vogt wrote:
> > Test 2 (nested locks)
> > ======
> > 
> > Setup
> > -----
> > 
> > Three concurrent threads using pthread mutexes (m1, ..., m10) and
> > counters c1, ..., c10.  All static data structures are allocated
> > in separate cache lines.
> > 
> > all threads:
> > 
> >   barrier
> >   take start timestamp (only thread 1)
> >   repeat <n> times
> >     lock m1, increment c1
> >     lock m2, increment c2
> >     ...
> >     lock m10, increment c10
> >     unlock m10
> >     unlock m9
> >     ...
> >     unlock m1
> >   barrier
> >   take end timestamp (only thread 1)
> > 
> > Performance is measured in the inverse of the time taken on thread
> > 1.
> 
> See above, throughput vs. fairness.

The troughput varies by a factor of two or more in multiple test
runs, except for the test with elision enabled, where the results
vary only but about 10%.  I agree that in this case it is also
interesting to find out why performance of the test can vary that
much.  It must have something to do with internal timing of the
threads and possibly starvation of some thread(s).

> > Test execution
> > --------------
> > 
> > Identical to test 1.
> > 
> > Result
> > ------
> > 
> > (1) unpatched  : 100.00%
> > (2) old glibc  : 134.35%
> 
> What causes this difference between (1) and (2)?  If we get a 34%
> difference just for stock glibc, this seems to be a bigger problem for
> me than similar overheads if we turn on elision, which is still an
> experimental feature.

As interesting that may be, it's really not a question on my
agenda as it does not involve transactional memory.

> > (3) elision off:  56.45%
> > (4) elision on :  31.31%
> 
> We need more data to understand these results.  See above.

The result of (3) needs to be explained.  I suggest to look closer
at this effect with a more recent version of the elision patches.
I'll do that after 2.18 freeze when the elision patches change
less frequently.

The result of (4) does not really irritate me because the test is
designed for high contention.

> > The abort ratio in (4) in all threads is between 5% and 10%.
> 
> That's interesting because all threads seem to conflict with each other
> (ie, they increment the same counters).

When the abort ratio is calculated as (100 * aborts / num_tbegins)
you get lower values with nested locks because one abort can cancel
up to ten nested transactions.

Also, as soon as one thread X has acquired m1, the other threads
cannot get through to the code that uses the later locks, so X can
use elision with no risk of being disturbed by the other threads.
Therefore the answer to this question:

> How often was elision actually used?

does not help much.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany