Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-09-03 at 10:25 +0200, Dominik Vogt wrote:
> On Mon, Sep 02, 2013 at 01:59:55PM -0700, Andi Kleen wrote:
> > Testing untested patches is also not a good idea.
> 
> I know, but at the moment I have no opther option.
> 
> > If you don't have a TSX system please don't submit TSX patches.
> 
> Sorry, I cannot comply with that.  I need to submit these patches
> because they address issues that come up with the port for z, and
> it is much better to discuss the issues when they come up, even if
> I cannot test them.

Then please send them with an [RFC] tag and make clear that you haven't
tested them, and that they shouldn't get applied unless somebody else
has tested them.  Sending patches as a base for discussion is a good
thing though, thanks.

> > Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> > > The patch replaces XABORT with XEND in case a transaction needs to be manually
> > > aborted because the futex is locked when we have opened a transaction.  This
> > > approach is less invasive than aborting because it keeps outer transactions
> > > intact.  The transaction may still abort later, when the futex is acquired.
> > > Another advantage is that we do not throw our private abort code at the creator
> > > of the outermost transaction.
> > 
> > Nack. This is done intentionally to improve profiling.
> 
> Yes.  Please read the answer I wrote to patch number 5 why I think
> that determining control flow depending on abort codes is not a
> good idea.  As I understand there is no possiblity with Tsx to
> communicate data other than the abort code to the abort handler.
> As this extra information is necessary to change the control flow,
> the only way I see here is to use _xend(), at least in production
> code.

But _xend() won't help in the case where we need it: nested
transactions.  If nested, we will have to abort anyway (we can't commit
the enclosing transaction, but are doomed due to observing the lock in
acquired state), so we can't communicate stuff to the outside.

If we're the outermost transaction, then there's no problem with the
abort code because it will reach our handling code.

> I completely understand that the removed abort is a very useful
> tool for testing and analyses for Tsx, and if you have an idea how
> to fix the abort code misinterpretation problem without "breaking"
> profiling I'd like to hear it (because this discussion is also
> relevant for the z port).

I'd first like to hear why you think that the misinterpretation problem
is such a big problem, and that there cannot be an ABI for the codes.
Second, if there cannot be an ABI, why you think that the
misinterpretation would be so costly in terms of messing up the
adaptation that it must definitely be avoided.

Note that I don't want to put the whole work here on you, but apparently
you and Andi disagree about the consequences of abort code
misinterpretation, so I think it would be a good start of the discussion
if you could present your case first in more detail.