[RFC] Lock elision implementation guidelines

[Dominik Vogt]

> Focus on PNT, allow E
> 
>     Enable LE conservatively. Provide tuning knobs that are not part of the
>     ABI.
>     Pro: Hopefully little harm done by LE implementation deficiencies (need
>     to be conservative with semantics, but performance tuning doesn't need to
>     perfect right away).
>     Con: No stable way to tune LE until a later time. 


The attached program suffers from a massive performance loss
caused by lock elision.  It runs two threads; the first one has a
repeated, big workload, while the second one just increases a
counter repeatedly.  Two mutexes are used.

(The test was run on a zEC12 with the elision patches ported to z
architecture.)

thread 1:
---------

for (...)
  lock A
  lock B
  increment a counter 1
  unlock A
  handle big workload
  increment counter 3
  unlock B

thread 2:
---------

forever
  lock A
  increment a counter 2
  lock B

(For completeness, there might be a third thread that runs at very
low frequency, and uses lock B to query counter 3.  That thread
might not need to be very responsive.  I.e. lock B is not
superfluous.)

In a real life test, the runtime of the program with elision is
almost identical to the runtime without elision and just locks.
But in the same time I get 1247 million increments of counter 2
without elision but just 660 million increments _with_ elision.

The explanation for this is that because of lock collisions the
mutex A is eventually switched to using a real lock instead of an
elided lock.  Thread 1 then elides lock B.  From this point I'm
not entirely sure what happens as I'm new to the nptl code.  But
either thread 2 waits on lock A until thread 1 releases lock B, or
as thread 2 tries to lock A, it aborts the transaction in thread
1.

The point is:  For certain program logic, lock elision can be
very bad for performance.

P.S.:  Test run with default tuning values; I think it switches
to real locks after three failed transactions, and back to
transactions after three real locks.  I'm quite sure that given
_any_ set of tuning parameters, I can write you a test program
that has similarly bad performance using elision.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nested-locks.c
Type: text/x-csrc
Size: 2362 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130610/bae2c3d7/attachment.bin>