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

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

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.

> 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.

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).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany