This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Hunter <ahh at google dot com>, libc-alpha at sourceware dot org, iant at google dot com, ppluzhnikov at google dot com
- Date: Wed, 2 Oct 2013 19:07:21 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <523F2ED8 dot 8090909 at redhat dot com> <1379977289-21260-1-git-send-email-ahh at google dot com> <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <524C3467 dot 2030503 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310022203420 dot 22120 at digraph dot polyomino dot org dot uk> <524CA564 dot 8080908 at redhat dot com>
On Wed, Oct 02, 2013 at 06:59:48PM -0400, Carlos O'Donell wrote:
> > I'd like there to be consensus for TLS accesses never failing (i.e. all
> > dynamic allocation being done at thread creation time or dlopen time, when
> > it's possible to return an error status, and initial accesses doing no
> > more than associating a variable with memory from a pool where a
> > sufficient amount of memory is guaranteed to have been allocated at one of
> > those times), but while I don't think anyone has objected to that, I'm not
> > sure enough people have actually thought about it.
>
> You are right that we haven't really reached a consensus there.
>
> Won't such an decision undo the lazy allocation benefits?
The lazy allocation benefits are mostly a myth. Physical resources
need not be pre-allocated for all TLS as long as sufficient virtual
memory (and, for non-overcommit setups, commit charge) are reserved.
Most users of glibc are using it with kernel-level overcommit enabled.
Essentially, lazy TLS allocation amounts to a second _layer_ of
overcommit. In addition to just overcommitting physical memory, you're
overcommitting virtual address space -- it might turn out when
__tls_get_addr is called that there's not sufficient virtual address
space for the TLS. For users who have overcommit enabled, you get most
of the "benefit" of lazy TLS allocation just from overcommit; the only
case that's not covered, which might apply in some corner cases on
32-bit archs, is the case where you run out of virtual addresses due
to TLS for a huge number of threads that never actually use it. This
is where all discussion of trade-offs needs to take place.
For users who have explicitly turned off overcommit, lazy TLS
allocation is HIGHLY undesirable, since it's actually re-introducing a
level of overcommit that could make applications crash from OOM when
the user's explicit intent was to prevent this kind of crashing
scenario.
> Will this not increase the amount of memory used by each thread after a
> dlopen even if the thread in question never uses TLS from the loaded library?
Physical memory? No.
Virtual memory? Yes.
Commit charge? Yes, but this only matters if overcommit was disabled,
in which case, the user's intent is that the potentially-needed
storage be charged.
Hope this clarifies.
Rich