Re: [PATCH] Add faster HTM fastpath for libitm TSX v2

2013-01-30 Thread Torvald Riegel
On Tue, 2013-01-29 at 20:19 +0100, Andi Kleen wrote: > > next time please reply to the points raised in a review if you disagree > > with them, and don't just ignore them. That speeds up the review. > > It was all in the previous email on the topic. This v2 patch did not incorporate all the chan

Re: [PATCH] Add faster HTM fastpath for libitm TSX v2

2013-01-29 Thread Andi Kleen
> next time please reply to the points raised in a review if you disagree > with them, and don't just ignore them. That speeds up the review. It was all in the previous email on the topic. > > // See gtm_thread::begin_transaction. > > -uint32_t GTM::htm_fastpath = 0; > > +uint32_t GTM::htm_fast

Re: [PATCH] Add faster HTM fastpath for libitm TSX v2

2013-01-29 Thread Torvald Riegel
On Thu, 2013-01-24 at 19:30 -0800, Andi Kleen wrote: > From: Andi Kleen > > The libitm TSX hardware transaction fast path currently does quite a bit of > unnecessary work (saving registers etc.) before even trying to start > a hardware transaction. This patch moves the initial attempt at a > tran

Re: [PATCH] Add faster HTM fastpath for libitm TSX v2

2013-01-25 Thread Andi Kleen
> Probably the attached (RFC) patch can be useful in this case. The > patch allows to specify the label for xbegin, so it is possible to > implement code like following (non-sensical) example: It can be actually implemented using asm goto. I have some macros for this. And the tree optimizers shou

Re: [PATCH] Add faster HTM fastpath for libitm TSX v2

2013-01-25 Thread Uros Bizjak
Hello! > The libitm TSX hardware transaction fast path currently does quite a bit of > unnecessary work (saving registers etc.) before even trying to start > a hardware transaction. This patch moves the initial attempt at a > transaction early into the assembler stub. Complicated work like retries