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: OndÅej BÃlka <neleai at seznam dot cz>
- 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 11:25:43 -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>
On 05/29/2013 01:55 AM, OndÅej BÃlka wrote:
> 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.
Fully agreed.
Added wording to the wiki about this.
> 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?
I have noted that you are in favour of tunables as long as the criteria
are clear.
> 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.
I'm glad you mentioned auto-tuning.
A useful use of a tunables API is to *help* developers write
auto-tuning algorithms. With a shared memory API you can attach
to the process and control library behaviour in realtime to examine
performance. Eventually the algorithm you write can be incorporated
into the library, and the tunable removed if we deem the auto-tuning
is the best choice (per your criteria above).
Cheers,
carlos.