This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: Rich Felker <dalias at aerifal dot cx>
- To: libc-alpha at sourceware dot org
- Date: Fri, 31 May 2013 23:11:51 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <20130529055518 dot GA23030 at domone dot kolej dot mff dot cuni dot cz> <ormwraq3rx dot fsf at livre dot home>
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