This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 02/11] Add external interface changes: new lock types for pthread_mutex_t


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]