This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, Torvald Riegel <triegel at redhat dot com>
- Date: Fri, 05 Jun 2015 01:23:45 -0300
- Subject: Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- Authentication-results: sourceware.org; auth=none
- References: <orvbf5ffyt dot fsf at livre dot home> <20150603152448 dot GC32684 at spoyarek dot pnq dot redhat dot com> <5570819F dot 3070902 at redhat dot com>
On Jun 4, 2015, "Carlos O'Donell" <carlos@redhat.com> wrote:
> I agree with Siddhesh and Torvald, it's not a good enough solution.
Again, good enough for what?
It is undisputably enough to fix the performance regression that in
certain cases introduced new deadlocks to the pile of other possible
deadlocks that variants of the testcase could exercise. It fixes a
small problem, and it's a trivial patch.
Sure, it doesn't fix a much larger preexisting problem, that's being
misrepresented as a TLS issue, but that is actually a far more pervasive
dynamic loader problem. I have no interest or time in tackling that.
Sure, if you guys want to leave the regression unfixed until someone
figures out some way to fix a larger but mostly unrelated problem, it's
your choice.
But if this larger fix does not contain the very change I'm proposing,
tls_get_addr on variables assigned static TLS will remain much slower
than needed, because there's absolutely no need to take a lock when it
is already decided whether the module should use static or dynamic TLS.
So what is this simple regression fix waiting for to get installed,
again?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer