This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Tue, 11 Jun 2013 11:00:16 -0700
- 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> <1370890159 dot 16968 dot 12558 dot camel at triegel dot csb> <20130611075118 dot GA3946 at linux dot vnet dot ibm dot com> <1370955941 dot 16968 dot 13163 dot camel at triegel dot csb>
Torvald Riegel <triegel@redhat.com> writes:
>
> Andi said that in his measurements, the overhead would be negligible.
> Could any of you share the actual numbers?
The original version used ifunc to patch in a separate
pthread_mutex_lock, but that caused various problems.
I measured it without it and there was no measurable difference (any
deltas were below the measurement inaccuracy).
Elision is a separate lock type.
By default when you run it on a system without elision support it will
use the standard non eliding lock type. The only extra cost here is the
upgrade check (move from timed to elided) which was non measurable.
The elided lock type has a check if elision is available and if yes an
extra tail call (tail calls are much cheaper than normal function
calls, but then even the later are not expensive on a modern system).
For a system with elision this path (until the check) would be only
taken if the application sets an elision lock type explicitely.
-Andi
--
ak@linux.intel.com -- Speaking for myself only