Improving Multiple-CMP Systems Using Token Coherence

Abstract

Improvements in semiconductor technology now enable Chip Multiprocessors (CMPs). As many future computer systems will use one or more CMPs and support shared memory, such systems will have caches that must be kept coherent.Coherence is a particular challenge for Multiple-CMP (M-CMP) systems. One approach is to use a hierarchical protocol that explicitly separates the intra-CMP coherence protocol from the inter-CMP protocol, but couples them hierarchically to maintain coherence. However, hierarchical protocols are complex, leading to subtle, difficult-to-verify race conditions. Furthermore, most previous hierarchical protocols use directories at one or both levels, incurring indirections-and thus extra latency-for sharing misses, which are common in commercial workloads.In contrast, this paper exploits the separation of correctness substrate and performance policy in the recentlyproposed token coherence protocol to develop the first M-CMP coherence protocol that is flat for correctness, but hierarchical for performance. Via model checking studies, we show that flat correctness eases verification. Via simulation with micro-benchmarks, we make new protocol variants more robust under contention. Finally, via simulation with commercial workloads on a commercial operating system, we show that new protocol variants can be 10-50% faster than a hierarchical directory protocol. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of the University of Pennsylvania's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to pubs-permissions@ieee.org. By choosing to view this document, you agree to all provisions of the copyright laws protecting it. Author(s)Michael

A Low Overhead Fault Tolerant Coherence Protocol for CMP Architectures

“…We have implemented our protocol using a full system simulator and we have presented results comparing it to a similar cache coherence protocol previously proposed [10] which does not support any fault tolerance but is tuned for performance in CMPs. We have shown that in the fault free scenario the overhead introduced by our proposal is between 5% and 11% when no backup buffer is used, and that using a backup buffer able to store just one cache line in each L1 cache is enough to reduce it to insignificant levels for 4, 8 and 16 way CMPs.…”

“…We have implemented the proposed fault tolerant coherence protocol using the detailed memory model provided by GEMS simulator (Ruby) to evaluate its overhead compared to the TOKENCMP [10] protocol and to check its effectiveness dealing with message losses. TOKENCMP is a token based coherence protocol without fault tolerance provision but that has been optimized for performance in CMPs.…”

“…TOKENCMP [10] is a performance policy which targets hierarchical multiple CMP systems. It uses a distributed arbitration scheme for persistent requests, which are issued after a single retry to optimize the access to contended lines.…”

Token tenure: PATCHing token counting using directory-based cache coherence

“…Several mechanisms for guaranteeing forward progress in token counting protocols have been proposed [7,20,23,24]. Token coherence uses persistent requests [20,23] to ensure forward progress. A processor invokes a persistent request after its transient requests have repeatedly failed to collect sufficient tokens during a timeout interval.…”

Exploit Temporal Locality of Shared Data in SRC Enabled CMP

“…To avoid indirections for cache-to-cache misses of directory protocol and interconnect ordering of snooping protocol, token protocol [8,9] directly send broadcast on un-ordered interconnect, avoiding indirection for cache-to-cache miss in directory-based protocol. Unfortunately, token protocol broadcasts request to maximal destination set, which will incur heavy network traffic.…”