Re: static TLS exhausted on ppc64le

[Florian Weimer <fweimer at redhat dot com>]

* Szabolcs Nagy:

> On 30/09/2019 15:02, Dan Horák wrote:
>> Hi,
>> 
>> I would like to open a problem we have already met twice in Fedora. the
>> symptom is
>> 
>> "/lib64/libgomp.so.1: cannot allocate memory in static TLS block"
>> 
>> usually when loading a lot of libraries/modules into a Python
>> application. It happened on ppc64le and also on aarch64 systems.
>> 
>> We have 2 reports in Fedora bugzilla about with more details.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1722181
>> https://bugzilla.redhat.com/show_bug.cgi?id=1738752
>> 
>> We have already discussed that briefly with Florian and other members of
>> the Red Hat toolchain team, but outcome was in form of a recommendation
>> to reduce the usage of "static TLS" objects in the individual libraries.
>> But the open question still is - is there a fix for the TLS space
>> exhaustion? I believe it can easily become a more serious problem soon.
>
> (a workaround is preloading the problematic libs at startup time)
>
> i think it's a bug in libgomp.so.1, gcc should not build
> broken dsos by default (unless it can ensure they are never
> loaded dynamically):
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/configure.tgt;h=b88bf72fe3de3735929635c874b8da375c841b1d;hb=HEAD#l13

I like the simplicity of initial-exec TLS.

I think there was a change on POWER to use the static TLS reservation
for dynamic TLS, as an optimization.  Obviously, that's going to hurt
those cases where a library with initial-exec TLS is loaded late, even
if the static TLS reservation would ordinarily be large enough.

Thanks,
Florian