Steal-on-abortImproving Transactional Memory Performance

through Dynamic Transaction Reordering

Mohammad Ansari

University of Manchester

Motivation

• Conflicts are bad• Reduce application performance/scalability• If abort occurs: waste computing resources• Conflicts should be minimised

• TM implementations assume conflicts are rare• Often optimise for commits• Making conflicts and aborts expensive

Motivation

• TM applications likely to have conflicts• TM aimed at ‘average programmer’

• Unlikely to have expertise to minimise conflicts• Exacerbated as number of cores rises

• It would be nice to automatically reduce conflicts• Improve performance transparently• No (or minimal) programmer effort

• Steal-on-abort (SOA)• Automatically attempts to reduce repeat conflicts

• Repeated conflict between two particular transactions

Repeat Conflicts: Example

• T1 and T2 execute concurrently

• T1 conflicts with T2

• T1 aborts

• T1 restarts (immediately)

• T1 conflicts with T2 again

• T1 aborts again

• T1 restarts (immediately)

• T1 conflicts with T2 again

• …

T2T1

…

SOA Motivation

• In general, difficult to predict first conflict/abort• Once observed, simple to avoid next conflict/abort

• Do not execute T1 & T2 concurrently

• Steal-on-abort design:• Prevent repeat conflict:

• On abort, abortee transaction stolen (hidden) by aborter• Abortee transaction released after aborter commits

• Additionally, attempt to improve performance:• Thread whose transaction is stolen obtains another

transaction to execute. May commit, improving performance.

SOA Trade-offs

• Advantages:• No offline processing required• Application-agnostic, no programmer input needed• Low overhead, only acts upon abort

• Disadvantages:• Unsuitable for invisible reads and writes

SOA Implementation

• Three components:• Threads with job deques• Work stealing between job deques• Steal-on-abort action

Threads with Job Deques

Work Stealing in Action

Steal-on-Abort in Action

Evaluation

• 4x dual-core (8-core) Opteron system• DSTM2 with Polka contention manager• Port of STAMP’s Vacation benchmark

• Parameters changed to induce high contention

• Results from average of 9 runs

Time Spent in Aborted Transactions

0

20

40

60

80

100

120

2 4 8

Threads

Wa

ste

d w

ork

(%

)

Non-SOA

SOA

Performance

0

2000

4000

6000

8000

10000

12000

14000

16000

1 2 4 8

Threads

Tra

nsa

ctio

ns/

seco

nd

Non-SOA

SOA

Repeat Conflict Distribution

0

100000

200000

300000

400000

500000

600000

700000

Non-SOA SOA

Was

ted

Wo

rk (

ms)

1

2

3

4

5

06-10.

11-100

101-1000

Overhead Analysis

0

20

40

60

80

100

120

Threads

Tim

e S

pen

t in

Tra

nsa

ctio

ns

(%)

Non-SOA

SOA

Non-SOA 93.3302 95.8282 96.9152 97.2005

SOA 94.3543 93.6388 94.8277 96.2473

1 2 4 8

Summary

• Conflicts hurt performance, may waste resources• Repeat conflicts can be a source of conflicts/aborts• Steal-on-abort attempts to reduce repeat conflicts

• Aborter steals abortee, releases once committed• Abortee’s thread acquires new transaction• Completely transparent, but requires visible accesses

• Evaluation• Performance, resource usage improvements• Low overhead

Repeat Conflict Distribution (log scale)

1

10

100

1000

10000

100000

1000000

Non-SOA SOA

Was

ted

Wo

rk (

ms)

1

2

3

4

5

06-10.

11-100

101-1000

SOA: Example

• T1 conflicts with T2

• T1 aborts

• T3 starts

T1 T2

T3

Threads with Job Deques

Thread A

Job 0

Job 1

Job 2

Job 3

currentJob

mainDeque

currentJob

Threads with Job Deques

Thread A Thread B

Job 4

Job 5

Job 6

Job 7

currentJob currentJob

mainDeque mainDeque

currentJob