This is the mail archive of the
mailing list for the glibc project.
Dropping ifunc from lock elision
- From: Andi Kleen <andi at firstfloor dot org>
- To: libc-alpha at sourceware dot org
- Cc: hjl dot tools at gmail dot com
- Date: Mon, 7 Jan 2013 23:21:56 +0100
- Subject: Dropping ifunc from lock elision
I heard some people were unconfortable about the obscure ifunc
patches needed for the lock elision implementation, plus
the binutils requirements from this.
The main reason I added ifunc originally (before realizing
how hard it would be and HJ rescued me) was to avoid one check
in the lock fast path on systems without RTM.
The normal lock type has to check whether to upgrade a
default timed lock to an elided lock. That's essentially
checking a global variable. Also the elided code paths
have to check whether elision is available
(this lets programs that explicitely asked for elision gracefully
fall back if it is not available)
But pthread ifunc is very peculiar, because pthread is very
early initialized and there were various latent bugs that were
triggered. HJ fixed them for me. This caused these additional
"weird" patches and requirements for lock elision.
But I reevaluated the original assumption now and did
some microbenchmarks on the cost of having these additional
checks. In a cache hot situation for the global variable
I cannot measure any difference on modern Intel CPUs.
Even with cache cold I expect it to be reasonable.
Based on that data I will rework the lock elision patchkit
to not use ifunc or multiarch, but always have these checks
Of course merging the ifunc fixes is likely still a good
idea, but they won't be needed for lock elision now.
This will also make backporting much easier.
I would still urge code review of the currently posted patches.
The bulk of the code will not change. And I haven't seen
any feedback on the core code so far.
firstname.lastname@example.org -- Speaking for myself only.