This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFCv2] Dynamic lock elision support
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Wed, 2 Sep 2015 17:01:21 -0400
- 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> <55E74E47 dot 5030707 at linaro dot org>
On 09/02/2015 03:30 PM, Adhemerval Zanella wrote:
> 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
As long as the documentation in the manual says tunables are supported only for
a single release, and are not backwards compatible, then I'm happy, because we
can eventually revisit this decision.
I don't see any real value in having grouped tunnables, because the user still
has to know all of them and clear all of them. And now instead of having either
a simple 1:1 of tunable:envvar, or ALL:1 as Roland suggested, we have some mix
that the user has to learn.
I still recommend one tunable per env var.
We might have a tool provided by glibcto do this would help
e.g. glibc-tune --clear, glibc-tune --list
e.g. glibc-tune --set GLIBC_PTHREAD_ELISION_DISABLE=yes
Cheers,
Carlos.