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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, 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 18:26:32 -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 05/31/2013 04:43 PM, 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.
>
> 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.
>
Thanks, added to growing list of use cases:
http://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior
Cheers,
Carlos.