This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, stli at linux dot vnet dot ibm dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 18 Sep 2015 12:04:43 -0500
- Subject: Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
- Authentication-results: sourceware.org; auth=none
- References: <55F33220 dot 8050105 at linux dot vnet dot ibm dot com> <20150917043712 dot GA6834 at vapier dot lan> <55FACCF4 dot 1050200 at linux dot vnet dot ibm dot com> <20150917175102 dot 39DD32C3B22 at topped-with-meat dot com> <1442513371 dot 10636 dot 2 dot camel at oc7878010663> <20150917181945 dot E92852C3B40 at topped-with-meat dot com> <1442514665 dot 2348 dot 38 dot camel at reserved-bit dot com> <20150917194823 dot D23452C3B40 at topped-with-meat dot com> <87twqskcsb dot fsf at tassilo dot jf dot intel dot com> <20150918063251 dot GA2213 at vapier dot lan> <20150918160648 dot GH1747 at two dot firstfloor dot org>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Fri, 2015-09-18 at 18:06 +0200, Andi Kleen wrote:
> On Fri, Sep 18, 2015 at 02:32:51AM -0400, Mike Frysinger wrote:
> > On 17 Sep 2015 13:32, Andi Kleen wrote:
> > > Roland McGrath <roland@hack.frob.com> writes:
> > > > The main point is to separate the internal API infrastructure that will be
> > > > used pervasively across the source tree and set the terms for how we
> > > > describe a tunable (i.e. naming, types, et al) from the "back end"
> > > > implementation of any particular scheme for getting values into the
> > > > system.
> > >
> > > I don't see how such a complicated procedure is needed to add simple
> > > tunables. It seems just an elaborate way to say "I can't make up my mind"?
> >
> > glibc is known for its stability and strong guarantees of not breaking
> > ABIs. describing something as simple seems to brush that off -- we don't
> > want to introduce knobs hastily that we are going to regret and be stuck
>
> This has been discussed since at least two years now.
> There's nothing hasty about the existing procedure. In fact "glacially
> slow" would be a more appropiate description.
>
> > with forever. perhaps this particular discussion has been dragging on a
> > bit, but glibc isn't really the place for experimentation (which is then
> > released directly to users) and for seeing what sticks purely by throwing
> > things against the wall. i'd rather we be overly conservative.
>
> Does that argue for never changing anything?
>
> I don't see how you can even test anything without "releasing it to
> users".
>
I have to agree with Andi on this. What happened to release early,
release often, get stakeholder feedback, adjust, repeat? How do we get
stake holder feed back without releasing code?
In the this specific case we have at least 3 hardware platforms that
support Transactional Memory and TLE. That is at least 7 platform
targets.
GLIBC has released the TLE code. That anyone can enable.
Real hardward, software in a supported community release, real
customers.
Now we are at the stake holder feed back and adjust stage.
So we have a modest proposal to tune (enable / disable) TLE to help
customers deal with the software already gave them.
I agree that we should have a more systematic approach to "tunables",
and we are willing to pitch in to that effort.
But I do not agree that the current situation is so broken and untenable
that we have to stop all progress to design an as yet to be defined
perfect solution.
Carlos has suggested a incremental approach based on systematizing the
environment variable name-space. Which is simple and pragmatic while
moving things in a direction where additional management tooling and
internal frameworks can be developed in parallel.
If Roland still strongly disagrees with this then he should explain in
detail what is problems are with the current situation. And why Carlos'
modest proposal should not be pursued as a starting point