[Patch] libitm: add HTM fastpath

[Torvald Riegel <triegel at redhat dot com>]

This patch adds support for using strongly-isolated HTMs with
serial-irrevocable mode as fallback.  Such HTMs can execute
uninstrumented code transactionally, and eventually aborted transactions
will cause no visible side effects.  Data conflicts with
nontransactional accesses lead to transactions being aborted.

To keep runtime overheads low, this is implemented as a fastpath that
gets executed early during transaction start and commit.  If the
uninstrumented code path is available, it will be used; otherwise, a
minimal TM method will be used, which is similar to the one used for
serial-irrevocable mode.  This method is in a new method group to
facilitate existing libitm infrastructure to switch between TM methods.

In case the HTM cannot execute a certain transaction due to
architectural limitations, or just to ensure forward progress,
transactions will switch to the fallback mode after a certain number of
aborts.  The fallback is serial-irrevocable mode, which is a simplistic
fallback but also simplifies the HTM fastpatch (ie, no complex hybrid
STM/HTM scheme is necessary).  Concurrent active hardware transactions
monitor the writer flag in gtm_rwlock, so a start of a
serial-irrevocable transaction will abort all of them and prevent
concurrent hardware transactions to run as long as the
serial-irrevocable transaction is present.

The fastpath is only compiled if the target architecture supports a
suitable HTM.  Right now, only support for Intel RTM is implemented, but
other strongly-isolated HTMs could use the fastpath as well.  RTM is
only used if the assembler supports the respective instructions.  The
fastpath is only enabled if the HTM method group is used and if the
current CPU at runtime supports the HTM.  The method group can be either
enabled explicitly (ITM_DEFAULT_METHOD=htm) or will be enabled by
default if more than one thread uses transaction and the CPU supports
the HTM.

Note that this is meant to be used in combination with the compiler
support for generating uninstrumented code paths, for which Aldy and/or
Richard will post a patch today.  Without uninstrumented code paths,
each transactional memory load and store will still result in a call to
a libitm function, which is not necessary when using an HTM and will
likely result in lower performance.

OK for trunk?


Torvald

Attachment: patch1
Description: Text document