This is the mail archive of the
mailing list for the glibc project.
Re: Failure to dlopen libgomp due to static TLS data
- From: Rich Felker <dalias at libc dot org>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>, libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: Thu, 12 Feb 2015 18:27:56 -0500
- Subject: Re: Failure to dlopen libgomp due to static TLS data
- Authentication-results: sourceware.org; auth=none
- References: <201502121519 dot t1CFJMAe018776 at d03av02 dot boulder dot ibm dot com> <20150212160959 dot GS23507 at brightrain dot aerifal dot cx> <20150212161145 dot GD1746 at tucnak dot redhat dot com> <20150212161617 dot GU23507 at brightrain dot aerifal dot cx> <54DCEF90 dot 6090700 at redhat dot com>
On Thu, Feb 12, 2015 at 06:23:12PM +0000, Andrew Haley wrote:
> On 02/12/2015 04:16 PM, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> >> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >>> This usage is supposed to be deprecated. Why isn't libgomp using
> >>> TLSDESC/gnu2 model?
> >> Because it is significantly slower.
> > Seems very unlikely. If storage is allocated in static TLS, TLSDESC is
> > almost indistinguishable from IE in performance, even when you run
> > artificial benchmarks that do nothing but hammer TLS access. When it
> > gets allocated in dynamic TLS, it's somewhat slower, but still
> > unlikely to matter for most usage IMO.
> The problem I'm seeing is that dynamic TLS is always used even when not
> necessary, and that hurts Java (which accesses TLS 128k times in the first
> 500ms or so of execution). According to lxo his patch fixes that.
Given those numbers, each access would need to be taking 38ns to
consume even 1% of the cpu time being spent. I would guess accesses
are closer to 5ns for TLSDESC in static area and 10-15ns for dynamic.
So I don't think this is a botteneck.