CloudCache: Expanding and shrinking private caches

Lee, Hyunjin; Cho, Sangyeun; Childers, Bruce R.

doi:10.1109/hpca.2011.5749731

Cited by 53 publications

(49 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In [32,42], the communication bottleneck to a central directory is mitigated by distributing hierarchical directories across the chip. More recent studies have focused on providing flexible sized clusters to best serve application demands [9,18,23,31,35]. LOCO provides an efficient mechanism for supporting flexible clusters while maintaining coherence and balancing cache utilization across clusters with IVR, unlike the complex hardware monitoring and remapping mechanisms required by prior techniques.…”

Section: Related Workmentioning

confidence: 99%

“…The clusters can be 1D or 2D meshes of any size, as shown in Figure 1. The size of the cluster depends on the applications' working sets and/or aggregate cache requirement [18,23,31,35], and is not the focus of this work. However, we do believe that HP C max should drive the cluster sizes, since any cache within HP C max hops can typically be accessed in 1 (X-only or Y-only) to 2 (X+Y) SMART-hops (which corresponds to 2 to 4 cycles low-load latency), as explained in Section 2.…”

Section: Background: Smart Nocmentioning

confidence: 99%

“…Prior approaches fundamentally boil down to keeping data as close as possible to the requesting core, like a private cache, but minimizing unnecessary replication. These Locality-Aware approaches include optimized page placement [3,10,14,15,19], line placement [12], intelligent replication [7,13,46] and clustering [9,18,31,35].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Locality-oblivious cache organization leveraging single-cycle multi-hop NoCs

Kwon

Krishna

Peh

2014

Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

Locality has always been a critical factor in on-chip data placement on CMPs as accessing further-away caches has in the past been more costly than accessing nearby ones. Substantial research on locality-aware designs have thus focused on keeping a copy of the data private. However, this complicates the problem of data tracking and search/invalidation; tracking the state of a line at all on-chip caches at a directory or performing full-chip broadcasts are both non-scalable and extremely expensive solutions. In this paper, we make the case for Locality-Oblivious Cache Organization (LOCO), a CMP cache organization that leverages the on-chip network to create virtual single-cycle paths between distant caches, thus redefining the notion of locality. LOCO is a clustered cache organization, supporting both homogeneous and heterogeneous cluster sizes, and provides near single-cycle accesses to data anywhere within the cluster, just like a private cache. Globally, LOCO dynamically creates a virtual mesh connecting all the clusters, and performs an efficient global data search and migration over this virtual mesh, without having to resort to full-chip broadcasts or perform expensive directory lookups. Trace-driven and full system simulations running SPLASH-2 and PARSEC benchmarks show that LOCO improves application run time by up to 44.5% over baseline private and shared cache.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Background: Smart Nocmentioning

confidence: 99%

See 1 more Smart Citation

Locality-oblivious cache organization leveraging single-cycle multi-hop NoCs

Kwon

Krishna

Peh

2014

Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

show abstract

“…Both private and shared LLCs have their advantages and drawbacks, so hybrid configurations have been proposed to exploit the benefits of both design choices, such as ESP-NUCA [17] and CloudCache [18]. CMP-NuRAPID [19] decouples tags and data to allow data placement and replication in any LLC bank.…”

Section: Related Workmentioning

confidence: 99%

Runtime home mapping for effective memory resource usage

Lodde

Flich

2014

Microprocessors and Microsystems

View full text Add to dashboard Cite

In tiled Chip Multiprocessors (CMPs) last-level cache (LLC) banks are usually shared but distributed among the tiles. A static mapping of cache blocks to the LLC banks leads to poor efficiency since a block may be mapped away from the tiles actually accessing it. Dynamic policies either rely on the static mapping of blocks to a set of banks (D-NUCA) or rely on the OS to dynamically load pages to statically mapped addresses (first-touch).In this paper, we propose Runtime Home Mapping (RHM), a new dynamic approach where the LLC home bank is determined at runtime by the memory controller when the block is fetched from main memory, trying to map each block as close as possible to the requestor thus speeding up execution time and lowering message latencies. Block migration and replication provide further improvements to basic RHM. Also, in a further optimization we eliminate the directory structure. All these optimizations involve specific NoC optimizations and co-designs. Results with PARSEC and SPLASH-2 applications show, when compared with alternative solutions, that RHM achieves a 41% and 35% average reduction in load and store latencies respectively compared to static mapping. This leads to an average reduction of 28% in applications execution.

show abstract

“…Some innovations also exists for implementing hybrid architectures by combining private LLC concepts and the distributed shared LLC concepts [21], [22], [23], [24], [25], [26].…”

Section: Cmp With Distributed Shared Cachementioning

confidence: 99%