This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Dynamic lock elision support
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, Stefan Liebler <stli 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>
- Date: Fri, 28 Aug 2015 16:27:57 -0500
- 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>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2015-08-18 at 16:58 -0500, Paul E. Murphy wrote:
> Was any consensus reached regarding adding environment variables for
> tuneables? The only alternative I've seen floated is to use HWCAP bits to
> point to a separate variant of libpthread. It seemed more undesirable.
> I like Andi's approach, and am willing to rework and resubmit Andi's
> patchset for the remaining archs if there is agreement with his approach.
> I think we would all benefit from a runtime mechanism to transition
> into TLE while we work to best utilize this new tool.
How do we move this forward and who needs to be brought into the
> On 08/18/2015 11:46 AM, Adhemerval Zanella wrote:
> > Hi,
> > Andi Kleen has sent some patches to add tunables for lock elision with
> > NPTL algorithms:
> > http://patchwork.sourceware.org/patch/4358/
> > http://patchwork.sourceware.org/patch/4355/
> > http://patchwork.sourceware.org/patch/4356/
> > http://patchwork.sourceware.org/patch/4359/
> > http://patchwork.sourceware.org/patch/4357/
> > http://patchwork.sourceware.org/patch/4361/
> > http://patchwork.sourceware.org/patch/4360/
> > But he has not yet ping or followed up with these. I also would prefer
> > to add tunable to be as platform agnostic as possible, since we have
> > 3 architectures that support LE (x86, ppc, zarch). So I would suggest
> > you work on this options and/or adjust the patch on these.
> > Also, we may want to avoid a configure flag and enable LE support as
> > default for powerpc, but disable as default (enabled through env. vars
> > as Andi Kleen patchset).
> > On 18-08-2015 13:10, Paul E. Murphy wrote:
> >> Elided locks can have mixed overall performance in practice. That is, there is some non-trivial tuning a user might have to do to see the positive benefits. Additionally, when tuning the adaptive lock constants on PPC, my experimentation seems to correlate tuned values with both the number of hardware threads per core, and the behavior of the application.
> >> My initial thought is elision should be disabled by default, with an environment variable to toggle both support, and potentially override tuning constants.
> >> Paul