Re: [PR19826] fix non-LE TLS in static programs

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec  6, 2016, Florian Weimer <fweimer@redhat.com> wrote:

> On 12/06/2016 10:30 AM, Alexandre Oliva wrote:
>> *nod*.  I think we could make malloc AS-Safe by having an alternate
>> arena to fallback to, if the preferred arena is already locked, and if
>> we realize we have to fallback to the alternate arena, we block signals
>> before locking it and unblock them once the allocation is done.  This
>> would probably be better than using an alternate allocator for the DTV
>> and for Static TLS and whatnot.

> We need a separate allocator for thread-local data to get predictable
> performance, especially in NUMA environments.

Sure, but that's not an argument against making malloc AS-Safe, is it?

There may be an argument for making malloc behave in a different way
within signal handlers, assuming allocations within them might end up
being frequently used by them in other threads as well, except when
allocating for TLS, because then we know the allocation is thread local.

>>> It's not just a problem for asynchronous signals, we do not have a way
>>> to report allocation failures, either.

>> Yeah, that's an essential consequence of deferred allocation of dynamic
>> TLS blocks and of per-thread DTV resizing.  We could avoid part of it by
>> always allocating TLS blocks statically, with some additional
>> synchronization at dlopen, but dealing with the DTV could be a lot more
>> interesting.

> But we know its size at dlopen time, right?  So we could perform the
> allocation then and just defer installing it.

Yeah, I suppose that may work.  It could even make TLS allocations more
efficient and thread-aware, say, by allocating pages and using the same
layout for the DTV and for corresponding TLS blocks for all threads.
I'm not sure how to make such allocations are placed efficiently in NUMA
settings, but that can be worked out.  Synchronization with threads
created or terminated while the creation is ongoing might be an
interesting nut to crack, especially in order to avoid priority
inversion, but my intuition suggests none of these issues are
insurmountable.

I'm just a bit worried about the overhead of allocating and deallocating
TLS blocks for all threads, in processes with thousands of threads, when
a temporarily loaded library brings in a TLS block that is to be
discarded shortly thereafter, when the library is unloaded.  I don't
know how common that is, or whether we want to discourage that, but it
would surely be a major change to the execution profile.  Not much more
different than the change I made years ago that turned formerly dynamic
TLS blocks into late-loaded static TLS ones, with similar consequences,
and I didn't see anyone complaining about that...  So maybe it's not
something to worry too much over, after all.  I suppose dynamic TLS not
promoted to static TLS has become such an uncommon case on platforms
that use TLS descriptors that it's nearly a corner case that those who
end up exercising it get what they deserve ;-) (though we could offer
means to adjust the initial static TLS block to enable undeserving users
to avoid this undesirable scenario :-)

Anyway...  This is all way outside the work I'm scoped to do, or my
responsibility to fixing the bugs I introduced, so I'll leave it to you
all and get my focus back on the things I'm supposed to be doing.

-- 
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