All of lore.kernel.org
 help / color / mirror / Atom feed
From: max <massimiliano.ghilardi@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: RFC: Kernel lock elision for TSX
Date: Sun, 30 Jun 2013 23:45:43 +0200	[thread overview]
Message-ID: <51D0A707.6070803@gmail.com> (raw)

On Saturday, March 23, 2013 6:11:52 PM UTC+1, Linus Torvalds wrote:
 > On Fri, Mar 22, 2013 at 6:24 PM, Andi Kleen <andi@firstfloor.org> wrote:
 >
 > >
 > > Some questions and answers:
 > >
 > > - How much does it improve performance?
 >
 > > I cannot share any performance numbers at this point unfortunately.
 > > Also please keep in mind that the tuning is very preliminary and
 > > will be revised.
 >
 > If we don't know how much it helps, we can't judge whether it's worth
 > even discussing this patch. It adds enough complexity that it had
 > better be worth it, and without knowing the performance side, all we
 > can see are the negatives.
 >
 > Talk to your managers about this. Tell them that without performance
 > numbers, any patch-series like this is totally pointless.

Hello,

I don't know if the thread is still actual, but I have a Core i7 4770
as my home PC, which supports TSX. I bought it *exactly* to experiment
with hardware transactions.

I am willing to test and benchmark kernel patches, and since I do not
work for Intel I can tell all the quantitative performance differences
I find.

Obviously, they will be *my* results, not official Intel ones -
it's up to Andi Kleen or some other Intel guy to tell if they are ok
or not with this, but since CPUs with TSX are now available in shops,
non-disclosure about their performance seems a bit difficult to
enforce...

--

I can tell from my preliminary performance results that at least for
user-space RTM seems really fast. On my PC, the overhead of an empty
transaction is approximately 11 nanoseconds and a minimal transaction
reading and writing 2 or 3 memory addresses runs in approximately
15-20 nanoseconds.

I just hope I did not violate some non-disclosure condition attached
to the CPU guarantee certificate ;-)

I tested it both with GCC, using inline assembler and .byte directives,
and in Lisp (don't tell anybody), by writing a compiler module that
defines the XBEGIN, XTEST, XABORT and XEND primitives.

--

How can I help?

I would start with the patches already posted by Andi, but the ones
I found in LKML archives seem to belong to at least two different sets
of patches: xy/31 (September 2012) and xy/29 (March 2013) and I could
not find if the first ones are a prerequisite for the second.

Regards,

Massimiliano

             reply	other threads:[~2013-06-30 21:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-30 21:45 max [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-03-23  1:24 RFC: Kernel lock elision for TSX Andi Kleen
2013-03-23 17:11 ` Linus Torvalds
2013-03-23 18:00   ` Andi Kleen
2013-03-23 18:02     ` Andi Kleen
2013-03-24 14:17     ` Benjamin Herrenschmidt
2013-03-25  0:59       ` Michael Neuling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51D0A707.6070803@gmail.com \
    --to=massimiliano.ghilardi@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.