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

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2013-01-16 at 19:49 +0100, Andi Kleen wrote:
> > Elsewhere in this thread Andi seemed to say that the HLE tunables are
> > just meant to be used for experiments, and not part of the standard ABI.
> 
> 
> Enabling/disabling elision per lock is part of the standard ABI.
> What's not part are the various retry configurables because the
> underlying algorithm may change later.

If the former are part of the standard ABI, these need to be
future-proof.  I don't think we have enough confidence yet to take this
step and change or extend the ABI.

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.

In general, I think that it's much better for the glibc project if it's
clear why a certain feature was implemented the way it is, what the
alternatives were, and why these alternatives were inferior.  Previously
you have complained about tuning magic numbers that don't have any docs
nor explanation attached to them; on an abstract level, we have the same
problem when somebody just drops a set of patches and doesn't discuss
the design and possible alternatives.

> > But how do we make sure programmers are aware of this?  The identifiers
> > above don't tell me that ELIDED can go away whereas PRIVATE will not.
> 
> Unlike the rest of NPTL elision has extensive documentation
> (see patch 10/10)

POSIX isn't extensive documentation?

(I agree we should improve the internal documentation, but that's
irrelevant for this discussion.)

> > Thus, I think we first need to have a clear understanding of what the
> > purpose of these flags/hints and the target audience / uses cases are.
> 
> See the manual in 10/10.

You know, the manual was the first thing I read when looking at this
patch set.  But except for perhaps listing the potential cases of HW
transaction aborts (which could count as partial use cases) and the
description of what the env var flags affect right now, this is not
discussed in the manual.  The manual explains what is in your patch, not
why this feature should be designed like in your patch, or how it is
meant to be used (ie, beyond describing the functionality you could
use).  So, this works for a manual, but does not suffice as explanation
of a feature for us.  Nor would it suffice as a tutorial or other docs
for users that go beyond a manual.

For example, who do you expect to use the env vars?  System
administrators?  How often are process-wide settings (env vars) actually
useful?  For the I/O case, this is something you could measure for
existing applications, without revealing anything specific to your
hardware.

Who do you expect to tune?  Expert programmers?  Everyone?

What of the functionality will have to remain stable, and which could
change in future?  Which things are tied to specific hardware behavior,
and which issues are likely to be similar across architectures?

And it doesn't help if you give short replies to these and similar
questions when those replies just suggest to essentially ignore issues
(e.g., when I

Also, just look at our discussion, and the questions raised by several
people.  I'd say it's highly unlikely that these questions came up
because these people didn't read your patches closely enough.  Please
try to be open towards the bigger picture here.


Torvald