Re: TSX lock elision for glibc v10

[Andi Kleen <andi at firstfloor dot org>]

> I understand that Andi is strongly in favor of a way to force elision
> onto existing binaries, even when it breaks semantics, in order to be
> able to do widespread testing (presumably both for bugs and for
> performance).

Just to clarify, the patchkit as posted requires a config switch
to do so (so someone who just installs 2.18 without knowing 
anything about elision will not get)

But yes I want very wide testing for correctness and performance.

There are some real potential issues (like unlocking unlocked locks)
which I need feedback on from wider testing.

Plus of course also the performance.

> What if, instead of a directly tunable environment
> variable, we made a (not necessarily permanent) way to override the
> default via an LD_PRELOAD library? Basically, what the LD_PRELOAD
> library would do is redirect the old symbol versions (which treat 0 as
> PTHREAD_MUTEX_NORMAL) to the new ones (which would treat 0 as
> PTHREAD_MUTEX_DEFAULT). Of course this could be done with an
> environment variable too, but the reasons I prefer LD_PRELOAD is that:

I use LD_PRELOAD a lot for testing, but I don't really like it much
for production usages.

> 
> 1. It's _automatically_ forbidden under suid without any additional
> logic that could contain new bugs.

FWIW if suid is the main concern it would be possible to implement
logic to disable elision by default for suid (so unless the
program enables it explicitely per lock)

I don't think this would have a huge impact on existing programs,
as suid programs are relatively rare and typically small.


-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.