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: Roland McGrath <roland at hack dot frob dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Siddhesh Poyarekar <sid at reserved-bit dot com>, munroesj at linux dot vnet dot ibm 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>, vapier at gentoo dot org
- Date: Thu, 17 Sep 2015 14:57:01 -0700 (PDT)
- 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>
> 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"?
It's called modularity.
> Please make a decision. This whole train wreck is going on for far too
> long now. And tunables are badly needed.
Decision here are made by consensus. It often takes a while. Technical
preparations that make it easier for more people to deliberate effectively
can help achieve consensus.
> An "internal API" doesn't help any user.
It is the only reasonable way forward, since one-off hacks are not feasible
to maintain or audit.
> I thought we had a consensus earlier when I was told to implement
> environment variables with opt-in config file. Is that now already
> forgotten?
That describes a back end implementation that I would not object to. I
think it likely that when we do reach consensus on something, it will be
something like that. There has never been consensus on the notion of
implementing any one-off hacks without a coherent internal API
infrastructure for all tunables.
> > I stand by my core positions.
>
> Nobody can figure out what your core positions are, they don't
> actually describe any way to solve the problem.
I'm not responding to this ad hominem statement that bears no relation to
any technical subject (and is not accurate in its characterization anyway).