Re: [RFC] Dynamic lock elision support

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

Adhemerval, thanks for pointing me to that wiki. I would find it helpful
to resummarize any shortcomings of [1] as a newcomer to the project. In
the spirit of cracking this nut, (to state the obvious) there are two
RFC's here:

1. Introduce a tuning framework
2. Introduce tuning bits for elision

I suspect there is agreement with the need for item 1, but not with how.

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.

Adding to the requirements, would a common syntax for tunable environment
variables be desirable?

I think we should be starting to lay the framework. Converging the use of
the many disparate env variables used throughout glibc is a topic in itself.


[1] http://patchwork.sourceware.org/patch/4358/

On 08/19/2015 09:14 AM, Adhemerval Zanella wrote:
> Siddhesh is working on some tunables for GLIBC [1] and on last cauldron
> he has exposed his ideas, although the framework itself was not really
> ready.
>
> I also like the idea of exposing the LE tunables now through environment
> variables.  I think we should now aim to define which will be parameters
> that are platform neutral and later the arch-maintainer can work on each
> parameter it will require for their platform.
>
> [1] https://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior
>
> On 18-08-2015 18:58, 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.
>>
>>
>> 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
>>>>