1 / 20

Steal-on-abort Improving Transactional Memory Performance through Dynamic Transaction Reordering

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

fulton-watts
Download Presentation

Steal-on-abort Improving Transactional Memory Performance through Dynamic Transaction Reordering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Steal-on-abortImproving Transactional Memory Performance through Dynamic Transaction Reordering Mohammad Ansari University of Manchester

  2. 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

  3. 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

  4. 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 • … T1 T2 …

  5. 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.

  6. 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

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

  8. Threads with Job Deques

  9. Work Stealing in Action

  10. Steal-on-Abort in Action

  11. 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

  12. Time Spent in Aborted Transactions

  13. Performance

  14. Repeat Conflict Distribution

  15. Overhead Analysis

  16. 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

  17. Repeat Conflict Distribution (log scale)

  18. SOA: Example • T1 conflicts with T2 • T1 aborts • T3 starts T1 T2

  19. Job 0 Job 1 Job 2 Job 3 Threads with Job Deques Thread A currentJob currentJob mainDeque

  20. Threads with Job Deques Thread A Thread B currentJob currentJob currentJob Job 4 mainDeque mainDeque Job 5 Job 6 Job 7

More Related