Re: [PATCH 03/10] Add external interface changes: new lock typesfor pthread_mutex_t

[Torvald Riegel <triegel at redhat dot com>]

On Sat, 2013-01-19 at 00:53 +0100, Andi Kleen wrote:
> > If the former are part of the standard ABI, these need to be
> > future-proof. 
> 
> Enabling/disabling is part of the ABI and is very future-proof.

You have *not* shown that these flags are exactly the flags that we want
to expose in the long term.  (Just look at all my questions that you
didn't answer so far for examples why we can't be confident (eg, what
happens if we have several different HW implementations of elision
support in the future.)

> Internal algorithm tunables are not part of the ABI, as I see it.
> They are not future-proof.
> 
> If there was ever an ABI for those it would likely consist of making
> old obsolete ones noops as Carlos proposed. But I don't think it makes
> sense to really support programs doing that, it's mostly an test interface
> for people trying out their applications.
> 
> 
> > Thus, if we assume that we won't change the ABI, what can we accomplish
> > right now?  For example, is there a way to have a conservative HLE
> > adaptation mechanism that is very unlikely to cause significant
> > slow-downs when enabled by default?  Then we could exploit the new
> > hardware almost transparently.
> 
> Yes I think so, but it needs more testing with a large body of
> applications.  And to do the testing we need the tunables.

But then we can use the tunables that are not part of an ABI, and don't
need to expose the other parts (eg, per-lock bits) that you want to
include in the ABI.

So what are your suggestions to take this forward without ABI changes in
the first steps?  What can be accomplished, what are the trade-offs at
each step?

And perhaps you could just answer the others questions in my previous
emails too?


Torvald