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

[Andi Kleen <andi at firstfloor dot org>]

Dominik Vogt <vogt@linux.vnet.ibm.com> writes:

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

Since z transactions and TSX are somewhat different I think it's
expected that the elision code for both diverges. I don't see that as a
bad thing -- these are critical fast paths and should be as optimized as
possible for the specific CPU, just like memcpy and other hot functions.

So feel free to do these changes to the z code alone.

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

We reserved some fixed values for abort codes in the optimization guide
(you can see that as a kind of ABI)

0xff lock busy.
0xfe lock_is_locked (not used in pthread)
0xfd nested trylock
0xf0...0xfc reserved

This also again has the advantage that it can be profiled.

I've been recently considered reserving another code for "abort one
time, do not adapt", there are some use cases for this in glibc
(e.g. the dynamic linker which always aborts once)

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only