This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TSX lock elision for glibc v10
- From: Andi Kleen <andi at firstfloor dot org>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Torvald Riegel <triegel at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org
- Date: Fri, 14 Jun 2013 19:47:11 +0200
- Subject: Re: TSX lock elision for glibc v10
- References: <1370969416-8337-1-git-send-email-andi at firstfloor dot org> <1371140799 dot 16968 dot 19087 dot camel at triegel dot csb> <20130613193514 dot GE29800 at brightrain dot aerifal dot cx> <20130613200843 dot GM6123 at two dot firstfloor dot org> <1371219304 dot 16968 dot 20195 dot camel at triegel dot csb> <20130614155330 dot GI29800 at brightrain dot aerifal dot cx>
> 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.