Proactive transaction scheduling for contention management

Blake, Geoffrey; Dreslinski, Ronald G.; Mudge, Trevor

doi:10.1145/1669112.1669133

Cited by 53 publications

(40 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Prior work has observed that it is often beneficial to structure code as a collection of transactional tasks, and schedule them across threads using a variety of hardware and software techniques [5,6,8,9,19,21,61,77]. Prior transactional schedulers focus on limiting concurrency, not spatial task mapping.…”

Section: A Scheduling In Speculative Parallelismmentioning

confidence: 99%

“…ATS [77], CAR-STM [20], and Steal-on-Abort [5] serialize aborted transactions after the transaction they conflicted with, avoiding repeated conflicts. PTS [8], BFGTS [9], Shrink [21], and HARP [6] instead predict conflicts by observing the readand write-sets of prior transactions, and serialize transactions that are predicted to conflict. Unlike predictive schemes, we avoid conflicts by leveraging program hints.…”

Section: A Scheduling In Speculative Parallelismmentioning

confidence: 99%

“…Prior work has observed that it is beneficial to structure transactional code into tasks instead, and has proposed transactional task schedulers that limit concurrency to reduce aborts under high contention [5,6,8,9,19,21,35,61,77]. Limiting concurrency suffices for small systems, but scaling to hundreds of cores also requires solving the spatial mapping problem: speculative tasks must be mapped across the system to minimize data movement.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Data-centric execution of speculative parallel programs

Jeffrey

Subramanian

Abeydeera

et al. 2016

2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)

View full text Add to dashboard Cite

Abstract-Multicore systems must exploit locality to scale, scheduling tasks to minimize data movement. While localityaware parallelism is well studied in non-speculative systems, it has received little attention in speculative systems (e.g., HTM or TLS), which hinders their scalability.We present spatial hints, a technique that leverages program knowledge to reveal and exploit locality in speculative parallel programs. A hint is an abstract integer, given when a speculative task is created, that denotes the data that the task is likely to access. We show it is easy to modify programs to convey locality through hints. We design simple hardware techniques that allow a state-of-the-art, tiled speculative architecture to exploit hints by: (i) running tasks likely to access the same data on the same tile, (ii) serializing tasks likely to conflict, and (iii) balancing tasks across tiles in a locality-aware fashion. We also show that programs can often be restructured to make hints more effective.Together, these techniques make speculative parallelism practical on large-scale systems: at 256 cores, hints achieve nearlinear scalability on nine challenging applications, improving performance over hint-oblivious scheduling by 3.3× gmean and by up to 16×. Hints also make speculation far more efficient, reducing wasted work by 6.4× and traffic by 3.5× on average.

show abstract

Section: A Scheduling In Speculative Parallelismmentioning

confidence: 99%

Section: A Scheduling In Speculative Parallelismmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Data-centric execution of speculative parallel programs

Jeffrey

Subramanian

Abeydeera

et al. 2016

2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)

View full text Add to dashboard Cite

show abstract

“…Such repair is limited to simple cases such as counters. Other proposals learn repeated conflicts and avoid scheduling conflicting transactions in parallel [5] or take checkpoints to reduce the rollback extent [25]. Enforcing strict memory consistency models through outof-window speculation has received much attention (e.g., [6,10,13,21,26]).…”

Section: Related Workmentioning

confidence: 99%

OmniOrder: Directory-based conflict serialization of transactions

Qian¹,

Sahelices²,

Torrellas³

2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

View full text Add to dashboard Cite

Effective execution of atomic blocks of instructions (also called transactions) can enhance the performance and programmability of multiprocessors. Atomic blocks can be demarcated in software as in Transactional Memory (TM) or dynamically generated by the hardware as in aggressive implementations of strict memory consistency. In most current designs, when two atomic blocks conflict, one is squashed -a performance loss that is often unnecessary.To avoid this waste, this paper presents OmniOrder, the first design that efficiently executes conflicting atomic blocks concurrently in a directory-based coherence environment. The idea is to keep only non-speculative data in the caches and, when the cache coherence protocol transfers a line, include in the message the history of speculative updates to the line. The coherence protocol transitions are unmodified. We evaluate OmniOrder with 64-core simulations. In a TM environment, OmniOrder reduces the execution time of the STAMP applications by an average of 18.4% over a scheme that squashes on conflict. In an environment with SC enforcement with speculation, we run 11 programs that implement concurrent algorithms. OmniOrder reduces the programs' execution time by an average of 15.3% relative to a scheme that squashes on conflict. Finally, OmniOrder's communication overhead of transferring the history of speculative updates is negligible.

show abstract

“…Contention management can be proactive. The ATS [29], BFGTS [30] and PTS [30] schemes implement either low overhead counters or sophisticated filters to track and predict conflicts between transactions, thereby mitigating aborts by serializing transactions with a high probability to conflict. The basic idea of PUNO is orthogonal and complementary to these proactive contention management mechanisms.…”

Section: Related Workmentioning

confidence: 99%

Mitigating the Mismatch between the Coherence Protocol and Conflict Detection in Hardware Transactional Memory

Zhao¹,

Chen

Draper³

2014

2014 IEEE 28th International Parallel and Distributed Processing Symposium

View full text Add to dashboard Cite

Hardware Transactional Memory (HTM) usually piggybacks onto the cache coherence protocol to detect data access conflicts between transactions. We identify an intrinsic mismatch between the typical coherence scheme and transaction execution, which causes a sizable amount of unnecessary transaction aborts. This pathological behavior is called false aborting and increases the amount of wasted computation and on-chip communication. For the TM applications we studied, 41% of the transactional write requests incur false aborting. To combat false aborting, we propose Predictive Unicast and Notification (PUNO), a novel hardware mechanism to 1) replace the inefficient coherence multicast with a unicast scheme to prevent transactions from being disrupted unnecessarily and 2) restrain transaction polling through proactive notification. PUNO reduces transaction aborts by 61% and network traffic by 32% in workloads representative of future TM applications with a VLSI implementation area overhead of 0.41%.

show abstract

Proactive transaction scheduling for contention management

Cited by 53 publications

References 23 publications

Data-centric execution of speculative parallel programs

Data-centric execution of speculative parallel programs

OmniOrder: Directory-based conflict serialization of transactions

Mitigating the Mismatch between the Coherence Protocol and Conflict Detection in Hardware Transactional Memory

Contact Info

Product

Resources

About