This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Dynamic lock elision support
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Wed, 19 Aug 2015 23:11:47 +0530
- Subject: Re: [RFC] Dynamic lock elision support
- Authentication-results: sourceware.org; auth=none
- References: <55D358D8 dot 7020303 at linux dot vnet dot ibm dot com> <55D3615F dot 1020300 at linaro dot org> <55D3AA72 dot 7000901 at linux dot vnet dot ibm dot com> <55D48F62 dot 6010902 at linaro dot org> <55D4ADC7 dot 3050008 at linux dot vnet dot ibm dot com>
On Wed, Aug 19, 2015 at 11:24:39AM -0500, Paul E. Murphy wrote:
> As Siddhesh notes, there are already quite a few env variables which alter
> the behavior of libc and company. He does a good job of describing
> the requirements of such a framework. I see no reason why it can't
> be approached incrementally.
It will in fact be approached incrementally. I have patches on the
siddhesh/tunables branch that I need to fix up following our
discussion at the GNU Tools Cauldron and post on the list. I hope to
be able to do it before the end of the week.
> Adding to the requirements, would a common syntax for tunable environment
> variables be desirable?
The namespace requirements are frozen, but the open question currently
is how we read values for those tunable names. My initial draft made
environment variables out of those names, but the consensus in the
room last week leaned towards an alternate expression, perhaps a
single environment variable with a string value that is parsed to get
all tunable values. There could be other ideas, I'll think about it
once I get the initial framework in.
Siddhesh