This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
without ifunc.

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.



-- -- Speaking for myself only.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]