This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]