Improving Performance by Reducing Aborts in Hardware Transactional Memory

Abstract

Abstract. The optimistic nature of Transactional Memory (TM) systems can lead to the concurrent execution of transactions that are later found to conflict. Conflicts degrade scalability, and may lead to aborts that increase wasted work, and degrade performance. A promising approach to reducing conflicts at runtime is dynamically, and transparently, reordering the execution of transactions upon discovery of conflicts. This approach has been explored in Software TMs (STMs), but not in Hardware TMs (HTMs). Furthermore, STM implementations of this approach cannot be ported to HTMs easily. This paper investigates the feasibility of such reordering in HTMs, and presents two designs that are scalable, independent of the on-chip interconnect, require only minor modifications to each core, and add no execution overhead if no conflicts occur. The evaluation takes LogTM-SE as a base line and considers benchmarks with different levels of contention (transactional conflicts). The results show that the preferred design increases HTM performance by up to 17% when contention is low, 57% when contention is high, and never degrades performance. Finally, the designs are orthogonal to LogTM-SE; they require no modification to cache structures, and continue to support transaction virtualization, open and closed unbounded nesting, paging, thread suspension, and thread migration.

Seer

“…Steal-On-Abort, although initially implemented in software, was later also proposed for an HTM simulator [2]. However, this work assumed hardware extensions to support enqueuing the serialized transactions in each core of the processor.…”

“…The positive side is that it works with currently available HTMs. In fact, this is the de facto technique used with commodity HTMs due to their best-effort nature: because no transaction is guarScheduler SW HW Imprecise Fine-Grained Information ATS [26] χ CAR-STM [11] χ χ Shrink [13] χ χ ProPS [24] χ χ SER [19] χ χ TxLinux [25] χ χ SOA [3,2] χ Seer χ Table 1: Comparison of TM schedulers in terms of: regulating an STM and/or HTM, working without precise information on which transaction caused the abort, and whether it uses multiple fine-grained locks to schedule transactions' execution. Seer, our proposal, is the only scheduler that provides all the following properties: 1) works with HTM; 2) does not require precise feedback on aborts; and 3) and adopts a fine-grained serialization mechanism.…”

Analysis, Classification and Comparison of Scheduling Techniques for Software Transactional Memories

“…The common feature of these techniques is that all of them require custom extensions to the hardware architecture in order to speed up operations executed by the scheduler. Similarly, Steal-On-Abort was later re-designed for HTM, and requires specific hardware extensions to support transaction queuing [52]. Unfortunately, the currently available HTM implementations do not offer specialized hardware as required by the above techniques.…”