Embedded-TM: Energy and complexity-effective hardware transactional memory for embedded multicore systems

Abstract

We investigate how transactional memory can be adapted for embedded systems. We consider energy consumption and complexity to be driving concerns in the design of these systems and therefore adapt simple hardware transactional memory (HTM) schemes in our architectural design. We propose several different cache structures and contention management schemes to support HTM and evaluate them in terms of energy, performance, and complexity. We find that ignoring energy considerations can lead to poor design choices, particularly for resource-constrained embedded platforms. We conclude that with the right balance of energy efficiency and simplicity, HTM will become an attractive choice for future embedded system designs.

Introduction

High-end embedded systems are increasingly coming to resemble their general-purpose counterparts. Embedded systems such as smart phones, game consoles, “net-tops”, GPS-enabled automotive systems, and home entertainment centers are becoming ubiquitous. In the same way that smart phones are gradually usurping many of the functions of laptops, specialized high-end embedded systems will eventually displace many general-purpose systems. Eventually, such devices will affect every aspect of modern life, and their energy consumption profiles will have a broad economic impact.

Like their general-purpose counterparts, and for many of the same energy-related reasons, embedded systems are turning to multicore architectures. This switch has profound implications for software, which must now manage concurrent activities. It is well established that traditional synchronization mechanisms such as locks have substantial drawbacks. Transactional memory [21] has emerged as a promising alternative.

Here, we investigate how transactional memory can be adapted for embedded systems. We then describe different designs for our Embedded-TM architecture. Transactional memory for embedded systems makes different demands than transactional memory for general-purpose systems. The principal difference is the central importance of energy consumption: although embedded systems are becoming more sophisticated, they are and will continue to be energy-constrained, either because they run on batteries, or simply because energy consumption is increasingly a concern for systems at all levels. We are the first to use energy consumption as a guide for designing transactional memory mechanisms. While most of the earlier work on transactional memory has neglected the question of energy consumption, we claim that it should be one of the driving concerns in transactional memory design. Taking energy into account requires revisiting and revising many widely accepted assumptions, as well as widely accepted architectures.

Because embedded systems are energy-constrained, there is an overriding need for simplicity: many techniques suited for general-purpose systems, such as out-of-order instruction or hardware multithreading, are too complex and power-hungry for today’s embedded systems. Any realistic transactional memory design for embedded systems must make do by combining simple components. We are willing to propose minor changes to existing standards, but not (what we consider) radical changes.

The need for energy efficiency and simplicity makes software transactional memory (STM) unattractive. (Klein et al. [23] provide an analysis of the energy costs of a typical STM system.) For most embedded applications, it is unacceptable, both in terms of performance and energy consumption, to place a software “barrier” at each memory access. Indeed, embedded applications often run without an operating system. By contrast, we will see that a simple hardware transactional memory (HTM) can both enhance performance and conserve energy.

While hardware transactional memory makes fewer resource demands than software transactional memory, limitations on cache size and associativity bound transactions’ sizes and durations. While proposals exist for “unbounded” transactional memory [2], [33] that allow transactions to survive certain kinds of resource exhaustion, these schemes are much too complex to be considered for embedded systems. For most embedded systems, however, applications’ resource requirements are well understood, and transactions that exceed those expectations are likely to be rare. Nevertheless, it is important to understand how to structure caches for HTM in embedded systems to maximize transaction sizes without compromising performance or increasing energy consumption. We will describe several such designs.

We evaluate HTM designs using three criteria: energy, performance, and complexity. Sometimes these criteria reinforce one another, and sometimes not. Here, we investigate a sequence of HTM designs, starting from a simple baseline, and moving on to a sequence of redesigns, each intended to address a specific problem limiting energy efficiency and performance. Structuring the presentation of Embedded-TM as a sequence of redesigns makes it possible to quantify the contribution of each incremental improvement.

We take as the baseline Embedded-TM an HTM based on a simple cache architecture [13], [21] in which non-transactional data is stored in a large L1 cache, and a smaller, fully associative transactional cache stores the data accessed within a transaction. The principal drawback of this architecture is that the transactional cache consumes too much energy. As a first line of defense, we consider how to conserve energy by powering down the cache without adversely effecting performance.

Another drawback of the baseline Embedded-TM architecture is the limited size of the transactional cache. Any transaction whose data set cannot fit in that cache cannot complete, and must continue in a less-efficient serial mode described below. To alleviate this problem, we consider an alternative design in which both transactional and non-transactional data are kept together in the L1 cache. The L1 cache is substantially larger than the transactional cache, and eliminates the need to maintain coherence across two same-level caches.

While this design supports larger transactions, it is still limited by resource constraints. To keep energy consumption down, the L1 must have limited associativity, so a transaction unlucky enough to overflow a cache line must run in serial mode. We address this problem by introducing a small victim cache to catch transactional entries evicted from the main cache [15]. Although we are back to a two-cache architecture, the victim cache is needed only when the main cache overflows, so it can be small, and powered down for longer durations.

As often happens, alleviating one problem exposes another. Transactions can also be prevented from making progress by data conflicts that occur when two transactions access the same memory location, and at least one access is a write. The first approach we consider, called eager conflict resolution, works well when transactions have few data conflicts, but less well when transactions have many data conflicts.

We examine two approaches to the problem of high-conflict transactions: a brute-force approach where a transaction that fails to make progress is eventually restarted in serial mode, and a more complicated approach where conflicts are resolved in a “lazy” manner. Lazy conflict resolution postpones the decision on aborting transactions to a later time, when more data on detected conflicts is available, thus potentially increasing concurrency.

Each approach is successful in some circumstances. The brute-force approach is attractive for its simplicity and wide range of effectiveness, and it works moderately well most of the time. The lazy mode algorithm incurs a higher overhead cost, sometimes penalizing low-conflict transactions, but is effective for high-conflict transactions.

We use a cycle-accurate simulator to investigate how well each of these Embedded-TM designs works on a range of benchmarks, as well as how simple TM designs compare to locking. Confirming prior observations [13], we find that even simple TM designs outperform locking with respect to both energy and performance. Each of the successive designs we consider improves the energy-performance product of most benchmarks. This improvement is workload-dependent in the sense that it is possible to find some configuration of some benchmark where any particular design does not improve on its predecessor, but overall each successive redesign is an improvement.

These results confirm that ignoring energy considerations can lead to poor design choices, particularly for resource-constrained embedded platforms. As architectures progress, and the demands of embedded platforms evolve, the further design and evaluation of energy-efficient cache architectures for HTM remains a promising direction for further work.