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: Alexandre Oliva <aoliva at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Jaeger <aj at suse dot com>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, David Miller <davem at davemloft dot net>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Fri, 31 May 2013 17:43:14 -0300
- 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>
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.
The problem is that, unlike the transitive closure of DT_NEEDED dynamic
libraries for a program, that can all be loaded before computing the
total amount of tls they require, dlopened libraries are loaded
afterwards.
What I wanted to do was to introduce a tunable for glibc to reserve an
additional amount of space to the static TLS segment, so that TLS
segments in the dlopened modules could be assigned to the static
segment, and relocations to their thread-local variables could be
resolved to the most efficient implementation.
How else could we enable *users* to tune the amount of thread-local
storage to reserve in the static TLS segment for dlopened modules?
Note that I write users, not developers, because the developers of the
program may have no idea whatsoever about what plugins individual users
would use. Requiring developers to modify the program (e.g., so as to
add some extra note to the executable) is not a reasonable solution.
Also, since the static segment size has to be determined before control
is relinquished by the dynamic loader or the static executable start-up
code to the program, this is not the sort of tunable that could possibly
be set up by the program itself, say after reading a configuration file.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer