This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFCv2] Dynamic lock elision support
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Wed, 02 Sep 2015 17:02:37 -0500
- 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> <55E763A1 dot 3060908 at redhat dot com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Wed, 2015-09-02 at 17:01 -0400, Carlos O'Donell wrote:
> 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.
>
I also prefer a 1:1 structure but suggest an overlay of reasonable
prefix naming standard/practice to make possible/practical the tooling
you suggest below.
> 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.
>