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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: 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: Wed, 29 May 2013 07:55:18 +0200
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com>
On Wed, May 29, 2013 at 12:56:50AM -0400, Carlos O'Donell wrote:
> Community,
>
> I'd like to drive some consensus around the idea of using
> environment variables to tune runtime behaviour in glibc.
>
> e.g.
>
> LD_BIND_NOW=1 ./application
>
> or
>
> GLIBC_PTHREAD_MUTEX=elision ./application
>
> I would really appreciate any feedback from the senior members
> of the project. This is an issue I'd like to see come to some
> kind of consensus.
>
As tunables are concerned key word here is tradeoff. If it is clear
which choice is best, adding tunable is mistake.
Tunables could be appropriate where we must ask user what is more
important. Which malloc to use when one is 20% faster but causes 5% more fragmentation?
When performance is concerned I am for auto tuning without env variables
unless performance depends on external factors. We can internally
collect more data than external app so we should get better result.
Here I could imagine to introduce a cache file that preserves profile of
applications across runs.