This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 02/11] Add external interface changes: new lock types for pthread_mutex_t
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>, Torvald Riegel <triegel at redhat dot com>
- Date: Wed, 26 Jun 2013 18:22:34 -0400
- Subject: Re: [PATCH 02/11] Add external interface changes: new lock types for pthread_mutex_t
- References: <1372098290-29147-1-git-send-email-andi at firstfloor dot org> <1372098290-29147-3-git-send-email-andi at firstfloor dot org> <51C91BF1 dot 3020200 at redhat dot com> <20130625045518 dot GX6123 at two dot firstfloor dot org>
On 06/25/2013 12:55 AM, Andi Kleen wrote:
> On Tue, Jun 25, 2013 at 12:26:25AM -0400, Carlos O'Donell wrote:
>> Andi,
>>
>> This patch should get split into two parts.
>>
>> One part public, which goes into a second patch set.
>>
>> One part private.
>
> Can you please explain this more.
>
> Is that for reviewing purposes?
Yes.
It makes the review much easier if we split this into two parts.
Nobody can argue against an implementation of elision that has no
ABI or API changes, and is enabled with --enable-elision=yes.
That is our minimum first step.
Once we get that in we move into step two where we look at exactly
the minimum needed to make it useful to users.
We're working against the clock here for 2.18 so we need to make
each step easy to review, ack, and commit.
> Or some attempt to remove even the last tuning interfaces, to make
> elision completely untunable at runtime?
No. I have no objection to runtime tuning. In fact I think it is
essential, but for the purposes of getting core functionality in
place it clutters the review.
> If it's for reviewing purposes only I will do it.
> If it's the later I will not.
OK.
> As explained earlier tuning and experimentation is very important.
Certainly, and the discussion will not stop here.
> Even shipping 2.18 without the environment variables
> is very questionable. At some point it will stop making
> any sense at all, and we're nearly already over that point.
The only thing that will fix this is work.
Lets work hard for the next two days and see where we get.
Cheers,
Carlos.