This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Andi Kleen <ak at linux dot jf dot intel dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 18:06:13 -0400
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <1372105055-31254-1-git-send-email-andi at firstfloor dot org> <51C8AB50 dot 80108 at redhat dot com> <20130624203147 dot GO5643 at tassilo dot jf dot intel dot com> <51C8B797 dot 7080503 at redhat dot com> <20130624232607 dot GT6123 at two dot firstfloor dot org> <51C9B7D0 dot 5000207 at redhat dot com> <20130625170656 dot GB6123 at two dot firstfloor dot org>
On 06/25/2013 01:06 PM, Andi Kleen wrote:
>> So I've done some more work on this last night.
>>
>> The problem with continuing down this path is that it creates an ABI
>> event by exposing NORMAL as a new external type.
>
> Can you explain why this is a problem?
The discussion around the new type might take more time
than we have before the 2.18 freeze.
> AFAIK glibc is adding new ABIs all the time, there was just a new
> one last week.
>
> commit 61dd6208fb1e59a423b6dfa712a3c896c34b2590
> Author: Siddhesh Poyarekar <siddhesh@redhat.com>
> Date: Sat Jun 15 12:24:15 2013 +0530
>
> New API to set default thread attributes
>
>
> Why are any additions I make suddenly such a big problem?
Two new symbols took months of work to iron out the details,
just go back and look at the long threads between Roland,
Siddhesh, and Rich.
Not to mention that these symbols are completely new and
don't interfere with existing programs in any way.
Your changes are to existing interfaces and we must be even
more careful there.
That is why I'm recommending starting with a base patch that
just adds elision for the default mutex type when we build
with --enable-elision=yes.
>>
>> I looked at the generated code for adding NORMAL as an internal type
>> and ran some crude benchmarks and the performance difference is in the
>> noise.
>>
>> What I'm trying to balance is:
>>
>> * Avoid ABI changes in this first pass.
>
>
> Sorry I don't think we will get anywhere with such a requirement
> The tuning bits per lock are not negotiable for me.
That's fine, you are entitled to your opion,
and we can discuss that as a second step.
I hope that you would agree that it would be better for
everyone if we could at least get elision support for
default via --enable-elision=yes?
I'd rather this, since it creates a smaller second patch
to review given that the core elision routines are
all already included.
> The NORMAL change I would be ok to remove again (if elision
> stays), but I assume that would make Rich et.al. unhappy.
>
> I'm also starting to get concerned by the constantly shifting requirements
That is entirely our fault, and I'm mostly to blame for that.
We haven't merged something of this complexity in a long time.
Please bear with us as we get better with the process.
Cheers,
Carlos.