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: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Andi Kleen <andi at firstfloor dot org>, "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2013 10:33:49 +0200
- 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> <20130625173203 dot GL29800 at brightrain dot aerifal dot cx> <20130625204013 dot GS5643 at tassilo dot jf dot intel dot com> <1372197850 dot 964 dot 9938 dot camel at triegel dot csb> <20130626003555 dot GT5643 at tassilo dot jf dot intel dot com>
On Tue, 2013-06-25 at 17:35 -0700, Andi Kleen wrote:
> > And that's one of the contentious issues that still exist, and has been
> > noted in several reviews already (and not just recently...). In
> > particular, there's (1) the question of whether we want to have any
> > additional bits at all
>
> This was already discussed several months ago.
>
> Originally I didn't have bits, but separate lock types. Then I was advised
> to switch to bits, which I did.
But how you present new types doesn't change the question whether we
want to have any new types, or new modifier bits for types, at all.
> , and (2) the question whether these bits should
> > affect semantics, or be pure performance hints.
>
> Ok. Please discuss the topic then.
I really get the impression you're not reading reviews. At least you
seem to be ignoring mine. Have a look at my reply to your top-most
email in the v10 patch set:
http://sourceware.org/ml/libc-alpha/2013-06/msg00500.html
Look at point 2). There's 4 paragraphs just about this.
> And also please do it quickly,
> as you know there is a deadline this week, and if changes are needed
> I also need time to implement them.
I sent my v10 review 2 weeks ago. It's not my fault if you seem to
ignore it.
Also, we started to discuss this issue already in mid-January here:
http://sourceware.org/ml/libc-alpha/2013-01/msg00448.html
Thus, this isn't new at all.
> > Given that we don't have consensus about this, but can arguably get the
> > 90% without it (now that we have a solution for DEFAULT vs. NORMAL), it
>
> The initial goal is to let people test and evaluate it. If they can't
> turn it on/off they can't do that. So it would be more like 0%
That contradicts what you have been saying previously. You said that if
we can't use elision in existing binaries without recompilation, we
would cut off most of the uses (ie, no 90%). Now, we obviously cannot
use the new ELISION_NP and NO_ELISION_NP bits without recompilation, so
how can we get 0% when we don't provide those bits? One of the two
statements of yours must be wrong.
Also, we can turn elision on or off if we don't have those bits, just
not on a per-lock granularity.