Steal-on-abort Improving 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 … T2 T1 …

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

Performance

Repeat Conflict Distribution

Overhead Analysis

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)

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 AThread B Job 4 Job 5 Job 6 Job 7 currentJob mainDeque currentJob