Cooperative Cache Scrubbing
Total Page：16
File Type：pdf, Size：1020Kb
Cooperative Cache Scrubbing Jennifer B. Sartor Wim Heirman Ghent University Intel ExaScience Lab∗ Belgium Belgium Stephen M. Blackburn Lieven Eeckhout Kathryn S. McKinley Australian National University Ghent University Microsoft Research Australia Belgium Washington, USA ABSTRACT the memory wall translates into a power wall. More cores need big- Managing the limited resources of power and memory bandwidth ger memories to store all of their data, which requires more power. while improving performance on multicore hardware is challeng- The limits on total power due to packaging and temperature con- ing. In particular, more cores demand more memory bandwidth, strain system design and consequently, the fraction of total system and multi-threaded applications increasingly stress memory sys- power consumed by main memory is expected to grow. For some tems, leading to more energy consumption. However, we demon- large commercial servers, memory power already dominates total strate that not all memory traffic is necessary. For modern Java pro- system power [31]. grams, 10 to 60% of DRAM writes are useless, because the data on Software trends exacerbate memory bandwidth problems. these lines are dead - the program is guaranteed to never read them Evolving applications have seemingly insatiable memory needs again. Furthermore, reading memory only to immediately zero ini- with increasingly larger working set sizes and irregular memory tialize it wastes bandwidth. We propose a software/hardware coop- access patterns. Recent studies of managed and native programs on erative solution: the memory manager communicates dead and zero multicore processors show that memory bandwidth limits perfor- lines with cache scrubbing instructions. We show how scrubbing mance and scaling [21, 43, 55]. Two factors in managed languages instructions satisfy MESI cache coherence protocol invariants and pose both opportunities and challenges for memory bandwidth op- demonstrate them in a Java Virtual Machine and multicore simula- timization: (1) rapid object allocation and (2) zero initialization. tor. Scrubbing reduces average DRAM traffic by 59%, total DRAM (1) Many applications rapidly allocate short-lived objects, re- energy by 14%, and dynamic DRAM energy by 57% on a range lying on garbage collection or region memory managers to clean of configurations. Cooperative software/hardware cache scrubbing up. This programming style creates an object stream with excellent reduces memory bandwidth and improves energy efficiency, two temporal locality, which the allocator exploits to create spatial lo- critical problems in modern systems. cality [5, 6, 7]. Unfortunately, short-lived streams displace useful long-lived objects, leave dead objects on dirty cache lines, and in- crease bandwidth pressure. The memory system must write dirty Categories and Subject Descriptors lines back to memory as they are evicted, but many writes are use- C.0 [Computer Systems Organization]: General—Hard- less because they contain dead objects that the program is guaran- ware/software interfaces, instruction set design; D.3.4 [Pro- teed to never read again. Our measurements of Java benchmarks gramming Languages]: Processors—Memory management show that 10 to 60% of write backs are useless! (garbage collection), optimization, runtimes (2) Managed languages and safe C variants require zero initial- ization of all fresh allocation. With the widely used fetch-on-write cache policy, writes of zeroes produce useless reads from memory 1. INTRODUCTION that fetch cache lines, only to immediately over-write them with Historically, improvements in processor speeds have outpaced im- zeroes. Prior work shows memory traffic due to zeroing ranges provements in memory speeds and current trends exacerbate this between 10 and 45% [54]. memory wall. For example, as multicore processors add cores, they While prodigious object allocation and zero initialization present rarely include commensurate memory or bandwidth [43]. Today, challenges to the memory system, they also offer an opportunity. Because the memory manager identifies dead objects and zero ini- ∗Wim Heirman was a post-doctoral researcher at Ghent University tializes memory, software can communicate this semantic informa- while this work was being done. tion to hardware to better manage caches, avoid useless traffic to Permission to make digital or hard copies of all or part of this work for memory, and save energy. personal or classroom use is granted without fee provided that copies are not These observations motivate software/hardware cooperative made or distributed for profit or commercial advantage and that copies bear cache scrubbing. We leverage standard high-performance gener- this notice and the full citation on the first page. Copyrights for components ational garbage collectors, which allocate new objects in a region of this work owned by others than ACM must be honored. Abstracting with and periodically copy out all live objects, at which point the col- credit is permitted. To copy otherwise, or republish, to post on servers or to dead redistribute to lists, requires prior specific permission and/or a fee. Request lector guarantees that any remaining objects are – the pro- permissions from [email protected]. gram will never read from the region before writing to it. However, PACT’14, August 24–27, 2014, Edmonton, AB, Canada. any memory manager that identifies dead cache-line sized blocks, Copyright 2014 ACM 978-1-4503-2809-8/14/08 ...$15.00. including widely used region allocators in C programs [4], can http://dx.doi.org/10.1145/2628071.2628083. 15 use scrubbing to eliminate writes to DRAM. The memory man- 2. BACKGROUND AND MOTIVATION ager communicates dead regions to hardware. We explore three We first present background on the bandwidth bottleneck and mem- cache scrubbing instructions: clinvalidate invalidates the cache- ory management. We then characterize the opportunity due to use- line, clundirty unsets the dirty bit, and clclean unsets the dirty bit less write backs. In our Java benchmarks, from 10 to 60% of write and moves the cache line to the set’s least-recently-used (LRU) backs are useless, i.e., the garbage collector has determined that position. While clinvalidate is similar to PowerPC’s discontinued the data is dead before the cache writes it back. We then describe dcbi instruction [20], and ARM’s privileged cache invalidation in- why existing cache hint instructions are insufficient to solve this struction [3], clundirty and clclean are new contributions. We also problem. use clzero, which is based on existing cache zeroing instructions [20, 32, 47] to eliminate read traffic. We extend the widely used 2.1 Bandwidth and Allocation Wall MESI cache coherence protocol to handle these instructions and Much prior research shows that bandwidth is increasingly a per- show how they maintain MESI invariants [14, 20, 22, 24, 37, 41]. formance bottleneck as chip-multiprocessor machines scale up the After each collection, the memory manager issues one of the three number of cores, both in hardware and software [10, 21, 35, 40, scrubbing instructions for each dead cache line. During application 43, 55]. Rogers et al. show that the bandwidth wall between off- execution, the memory manager zero initializes memory regions chip memory and on-chip cores is a performance bottleneck and with clzero. can severely limit core scaling [43]. Molka et al. perform a de- To evaluate cache scrubbing, we modify Jikes RVM [2, 7], a tailed study on the Nehalem microarchitecture [40], showing that Java Virtual Machine (JVM), and the Sniper multicore simula- on the quad-core Intel X5570 processor, memory read bandwidth tor [11] and execute 11 single and multi-threaded Java applica- does not scale beyond two cores, while write bandwidth does not tions. Because memory systems hide write latencies relatively well, scale beyond one core. simulated performance improvements are modest, but consistent: On the software side, Zhao et al. show that allocation-intensive 4.6% on average across a range of configurations. However, scrub- Java programs pose an allocation wall which quickly satu- bing dramatically improves the efficiency of the memory system. rates memory bandwidth, limiting application scaling and perfor- Scrubbing and zeroing together reduce DRAM traffic by 59%, to- mance [55]. Languages with region allocators and garbage collec- tal DRAM energy by 14%, and dynamic DRAM energy by 57%, tion encourage rapid allocation of short-lived objects, which some- on average. Across the three scrubbing instructions, we find that times interact poorly with cache memory designs. Scrubbing ad- clclean, which suppresses the write back and puts the cache line in dresses this issue by communicating language semantics down to the LRU position, performs best. hardware. While we focus on managed languages, prior work by Isen et al. identifies and reduces useless write backs in explicitly managed 2.2 Memory Management sequential C programs [23]. They require a map of the live/free The best performing memory managers for explicit and managed status of blocks of allocated memory, which hardware stores af- languages have converged on a similar regime. Explicit memory ter software communicates the information. Their approach is not managers use region allocators when possible [4, 21] and high- practical since (1) it requires a 100 KB hardware lookup table and a performance garbage collectors use generational collectors with a mark bit on every cache line, (2) it exacerbates limitations