This is the mail archive of the libc-alpha@sourceware.org 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]

Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS


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


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