This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFCv2] Dynamic lock elision support
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Wed, 2 Sep 2015 16:30:15 -0300
- Subject: Re: [RFCv2] 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> <55E4A9E7 dot 3030700 at linux dot vnet dot ibm dot com> <55E746D2 dot 7070309 at redhat dot com>
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.
>