Re: Consensus: Tuning runtime behaviour with environment variables.

[Rich Felker <dalias at aerifal dot cx>]

On Fri, May 31, 2013 at 05:43:14PM -0300, Alexandre Oliva wrote:
> On May 29, 2013, OndÅej BÃlka <neleai@seznam.cz> wrote:
> 
> > When performance is concerned I am for auto tuning without env variables
> > unless performance depends on external factors.
> 
> Here's one case where I've long entertained adding an env var to
> configure libc's internal behavior: the thread local storage
> optimizations I implemented years ago attempt to assign even the thread
> local area of dlopened libraries to the static tls segment, so that they
> can be accessed more efficiently.

This does not make access more efficient. While the static linker can
optimize TLS references in .o files from general/local dynamic to
initial-exec or local-exec model, TLS access in dynamic-loadable
libraries must always use one of the dynamic models. Shared libraries
which are not meant to be dynamic-loaded can be built to use the
initial-exec model, but allowing them to be dynamically loaded if and
only if the user configured for additional static TLS space to be
reserved sounds like a bad idea.

With that said, in musl all dynamic-loaded libraries' TLS is allocated
as part of the static TLS block for new threads, and dlopen allocates
sufficient new TLS space for all already-existing threads before
allowing the library to be loaded. But this is not a performance
optimization for the sake of efficient access. It's done as the only
way of guaranteeing that sufficient virtual address space and commit
charge are reserved, so that the program cannot later crash due to
failed lazy TLS allocation. It's also the only way I could find to
make __tls_get_addr async-signal-safe; otherwise, accessing TLS for
the first time from a signal handler could be dangerous, as it seems
to presently be in glibc...

An option to duplicate the TLS allocation strategy of musl in glibc
for the sake of high-robustness deployments could make an interesting
tunable, but I'm not sure how easy it would be to add.

Rich