Self-Tuning Intel TSX Nuno Diegues and Paolo Romano HTDC 2014 PhD - - PowerPoint PPT Presentation

Self-Tuning Intel TSX

Nuno Diegues and Paolo Romano

HTDC 2014

PhD Thesis: Protocols and Abstractions for Efficient Transactional Systems

• Reduce aborts
• preserving consistency
• shared memory / distributed
• Efficient transactional indexation/search
• Energy-efficiency of TM systems
• More recently: how can we leverage on hardware

for efficient transactional systems

Using TSX

_xbegin

• // your transactional code
• _xend

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

• Data contention
• Forbidden

instructions

• Hardware buffers’

capacity

• Signals and faults

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

• Data contention
• Forbidden

instructions

• Hardware buffers’

capacity

• Signals and faults

Transparently Restarts

Using TSX

Best-effort nature we cannot rely exclusively on TSX

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code // retry policy if (shouldRetry) goto begin else acquire(lock)

• code:

// your transactional code

• if (shouldRetry)

_xend else release(lock)

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code // retry policy if (shouldRetry) goto begin else acquire(lock)

• code:

// your transactional code

• if (shouldRetry)

_xend else release(lock)

Transactions need to be aware of this

Summary of issues

• Lemming effect
• Number of attempts
• Retry policy
• Management of fall-back

Abort Code retry Transient Failure conflict Contention to Data capacity Exceeded Cache Capacity explicit _xabort invoked

• ther

…

Lemming Effect

begin: wait lock is free unsigned int status = _xbegin if (status == ok) goto code // retry policy if (shouldRetry) goto begin else acquire(lock)

• ...

Programming with HLE Afek et al. PPoPP 2013

• r

Number of attempts

1 2 4 2 4 6 12 14 16 speedup retries high contention low contention

Kmeans from STAMP

Number of attempts

1 2 4 2 4 6 12 14 16 speedup retries high contention low contention

Kmeans from STAMP G r a d i e n t D e s c e n t

• f
• r

e x p l

• r

a t i

• n

Retry policy

• How many attempts in hardware?
• Give up on capacity aborts?
• How to manage the fall-back?

Retry policy

1 2 3 1 2 3 4 5 6 7 8

speedup threads GCC (Possible) Self-Tuning

none-giveup-1 aux-giveup-3 wait-giveup-4 wait-stubborn-4 wait-stubborn-4 wait-half-8 wait-half-11 wait-stubborn-11

Retry policy

1 2 3 1 2 3 4 5 6 7 8

speedup threads GCC (Possible) Self-Tuning

none-giveup-1 aux-giveup-3 wait-giveup-4 wait-stubborn-4 wait-stubborn-4 wait-half-8 wait-half-11 wait-stubborn-11

R e i n f

• r

c e m e n t l e a r n i n g

• U

p p e r C

• n

fi d e n c e B

• u

n d

Self-Tuning TSX

atomic_begin

fetch atomic block's stats yes no

fetch last configuration Profile cycles Begin Tx procedure atomic_end

execute atomic block

End Tx Procedure

Re-optimize?

application logic

Profile cycles

Run grad() Run ucb()

changes next configuration yes no continue program govern retry management abort retry

Re-optimize?

gcc libitm gcc libitm

requires more work

Quick flavour on results

1 2 3 5 20 25 throughput (1000 txs/sec) execution time (sec) GCC Heuristic AdaptiveLocks Tuner

benchmark finished

Yada from STAMP

Quick flavour on results

1 2 3 4 1 2 3 4 5 6 7 8

“ideal” self-tuning

speedup

threads

Intruder from STAMP

Summary

• Best-effort HTMs need proper tuning
• No one-size fits all
• We used lightweight exploration/learning techniques
• Transparent to the programmer