This is the mail archive of the
mailing list for the glibc project.
Re: static TLS exhausted on ppc64le
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: nd <nd at arm dot com>, Florian Weimer <fweimer at redhat dot com>, Dan Horák <dan at danny dot cz>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 30 Sep 2019 18:41:21 +0000
- Subject: Re: static TLS exhausted on ppc64le
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TMrqR8MXkz5sJ5VtO5DAPksxvwmcOO/pmJPyDnCfD6w=; b=j+DX3xlNwY2R4RlgtcFmyub7oNUq5eZwdOuNaCzYCQUzc3fvelpES0ZCtPat4OV44zk/29vj/mFbk6e7Th/eKCDq5z+6TSflXUUw3C2LCooIJeKQ/6FlQRr4eLumVNq9d9D+ojZXk0pWNbDJYsYaM+8caUQCy4kx6g2bmX6ZRTtxUanNbw8Lg/EXEYe08H6YuCx4o1iNaKQdu7iDblQTZQYEgMO/GVMAqSGh+TmH94wGrv/hi0ISr/BV6IKooWZVEgdvzhHWSYU9nZtI5OCgHR7JQ+jPCj0uT4FquxXAcnpVSp/9kcd3nawAuxHLZqUlDLTfYVS4v4cSWdUVoVORTw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eO44qv6jF6kDJutptp4ftO+OvZcbLayZpfXtBwSCYSyDo/iBPz9Lwx5AcRs30qjm22AP+bVszOwWP88E9272VziwCkcTxJoER7tLigKM+FX33MC2Gh/M7jRNbGRaQi0SKh1ous0phIkNHvhLmtrBxzFBDShSeBCW3JrfQfx0Ea6grqR/Ku3lwbZcQ+GYyrEg7SKzoKPjyIuLl32izH2rxmTl/fAp6Uj1TFsEsatF+nyOQcUynAOcyr9qDLJl2fFawCNUyNMVh0GoAMnz5Hd2HFblhR56ICdYWdOswqxegJvzvzCZr6uG/Z+DN0xysUvtaUGkAUosX7BXRm7KksfLYg==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20190930160631.GP9017@brightrain.aerifal.cx> <firstname.lastname@example.org> <20190930175016.GT9017@brightrain.aerifal.cx> <email@example.com>
On 30/09/2019 19:07, Carlos O'Donell wrote:
> On 9/30/19 1:50 PM, Rich Felker wrote:
>> I see. That's a shame, because if you have excess static TLS reserved,
>> using it for tlsdesc is actually really nice -- it makes the accesses
>> just as fast as initial-exec, but opportunistically, and falls back
>> gracefully if you run out. Waiting to hand it out to badly-behaved
>> libraries that are using initial-exec model only serves to reinforce
>> the bad behavior and discourages adoption of tlsdesc since the bad
>> behavior gets preferential treatment...
>> I think this analysis further supports my previous remarks that
>> initial-exec in dlopened libraries should be deprecated and EOL'd.
> We should dig deeper into the analysis here, and I just ran readelf for
> all the implicated libraries in the bug.
> The only *real* problem here is the implementation, only libc and libgomp
> use TLS IE in this case (and libgl in the wild).
> I think the best steps towards resolution are:
> * Stop ppc64le and aarch64 from using ALL of the static TLS for tlsdesc / tls opt hack.
> - Reserve at least 128 bytes for libgomp + libgl.
i think this is easy and reasonable:
_dl_try_allocate_static_tls can reserve 128 bytes
which is only used by _dl_allocate_static_tls.
(so the optimization is still applied to dynamically
loaded dsos, but there is guaranteed tls for small
number if IE libs)
> * Fix lazy tls loading to stop being lazy about allocation and allocate all memory
> required up front.
> - This allows libc to use GD instead of IE and not worry about touching tls vars
> early before init or the ordering of IE vs. GD.
> - Requires a non-default dlopen flag to get back old behaviour.
this sounds hard.
(and observable to users with many threads and many dsos with tls:
preallocation will use more memory and cause slower thread starts
than lazy allocation)
> * Switch glibc back to GD internally.
> * Switch x86_64 to tlsdesc (can be done at any time) to get perf back.
> Disallowing IE in DSOs is only going to get us angry users in a transitional period.
> The above plan will benefit ppc64le and aarch64 since they continue to
> have maximum performance for their usage of tlsdesc.
i'm ok with the plan, but i thin only the first part
is realistic in short term.