RFC: S/390 Transactional memory support - save/restore of FPRs

[Torvald Riegel]

On Wed, 2013-05-22 at 11:03 +0200, Andreas Krebbel wrote:
> On 21/05/13 16:28, Torvald Riegel wrote:
> > On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote:
> > You could also start with supporting s390 HTM through the transactional
> > language constructs we already support (__transaction_atomic etc.) and
> > libitm.  The advantage would be that you can reuse quite a few bits of
> > existing machinery (e.g., different fallbacks when the HTM can't execute
> > a certain transaction, some analyses on the compilation side); however,
> > this doesn't give programmers as much control as if using the HTM
> > directly, and it requires a function call on begin and commit when using
> > the current libitm ABI.
> > 
> > (I know that this is kind of a side note, because you seem to be looking
> > for a way to expose this at the granularity of HTM begin/commit builtins
> > (e.g., to base lock elision implementations on top of it); but I think
> > that in the long run txnal language constructs are easier for many
> > users.)
> 
> The patch I have so far implements libitm HTM support for S/390 using the builtins.  Very much like
> it is done on x86.

Andi Kleen posted a patch a while ago with an optimization to the C code
that moved the xbegin() etc. into the ITM_beginTransaction.  It had some
small issues, and didn't yet made it into trunk AFAIK.

> > In libitm, it's probably easier to write custom assembly code for
> > ITM_beginTransaction that saves/restores all additional bits not
> > restored by the HTM explicitly through a partial SW setjmp.  This
> > approach at least worked well for AMD's ASF, which didn't even restore
> > all normal registers.
> 
> Ok. I'll have a look. I haven't done measurements with libitm so far. The experiments with the
> low-level builtins show that having a function call for starting and ending a transaction is a big
> hit already so I didn't invest much into optimizing the libitm variant for now.

For very small transactions, it can certainly be a problem; for example,
if one wants to optimize custom concurrent code with transactions.
OTOH, if the use case is lock elision in existing lock-based code, then
one would probably have function calls anyway for the lock operations,
and then one would compare performance against this case too.