[RFCv2] Dynamic lock elision support

[Adhemerval Zanella]

On 02-09-2015 15:58, Carlos O'Donell wrote:
> On 08/31/2015 03:24 PM, Paul E. Murphy wrote:
>> Narrowing my focus here, we should have a runtime
>> mechanism to disable elision for those applications
>> which experience significant degradation from the
>> non-optional nature of this feature.
>>
>> I think we can table the discussion of runtime
>> tunable parameters as it is highly dependent on the
>> framework which emerges.
>>
>> In the meantime, there is a need to turn this
>> off for select workloads. It would be preferable
>> to add this in such a way that it can be easily
>> merged into the tunables framework when it
>> does evolve.
> 
> Is this theoretical or do you have such customer workloads,
> I'm not talking about the synthetic benchmarks you have, where
> default pthread mutexes cause the application to experience
> significant performance loss?
> 
> If you are proposing that your patch is sufficiently important
> to bypass the tunables discussion and get accepted right away
> then you need to give sufficient detail for the community to
> accept that we need to move quickly because users are having
> problems.
> 
> Otherwise I think that Siddhesh's present work should get
> reviewed by you, and others, get merged, and represent the
> basis for an internal tunables API that enables per-env-var
> tunables.
> 
> In summary, we can add "yet one more env var" for you, but
> you have to justify it.
> 

Based on Siddhesh initial proposal [1], IMHO best approach can be divide in
functionalities or libraries areas, such as:

* GLIBC_MALLOC for malloc related tunables (all current one, such as mmap trim, etc.)
* GLIBC_THREAD for libpthread one, such as PI-aware locks, TLE, stack size, etc.
* etc.

So in the TLE case for instance, we can use GLIBC_THREAD as the base and
add it in general case (instead of replicate the logic in every architecture).

[1] https://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior

> Cheers,
> Carlos.
>