Attaché: Towards Ideal Memory Compression by Mitigating Metadata Bandwidth Overheads

Abstract

Compression is seen as a simple technique to increase the effective cache capacity. Unfortunately, compression techniques either incur tag area overheads or restrict data placement to only include neighboring compressed cache blocks to mitigate tag area overheads. Ideally, we should be able to place arbitrary compressed cache blocks without any placement restrictions and tag area overheads. This paper proposes Touché, a framework that enables storing multiple arbitrary compressed cache blocks within a physical cacheline without any tag area overheads. The Touché framework consists of three components. The first component, called the "Signature" (SIGN) engine, creates shortened signatures from the tag addresses of compressed blocks. Due to this, the SIGN engine can store multiple signatures in each tag entry. On a cache access, the physical cacheline is accessed only if there is a signature match (which has a negligible probability of false positive). The second component, called the "Tag Appended Data" (TADA) mechanism, stores the full tag addresses with data. TADA enables Touché to detect false positive signature matches by ensuring that the actual tag address is available for comparison. The third component, called the "Superblock Marker" (SMARK) mechanism, uses a unique marker in the tag entry to indicate the occurrence of compressed cache blocks from neighboring physical addresses in the same cacheline. Touché is completely hardware-based and achieves an average speedup of 12% (ideal 13%) when compared to an uncompressed baseline.

L 2 C: Combining Lossy and Lossless Compression on Memory and I/O

“…Finally, managing the metadata needed for locating and handling the compressed data is also challenging as it may add considerable memory bandwidth overheads [28,29]. One approach is to employ a metadata table and a cache of it, as in [9,10,25], which is updated with the TLB and adds a few bytes of bandwidth overhead at every TLB miss.…”

“…One approach is to employ a metadata table and a cache of it, as in [9,10,25], which is updated with the TLB and adds a few bytes of bandwidth overhead at every TLB miss. Techniques like Attache [28] aim to further reduce the metadata cost by embedding the metadata directly in the compressed block.…”

“…Compression metadata has been identified as a significant source of memory traffic [28]. To evaluate this factor, our simulations include both the traffic of regular page table information (via TLB misses) and the additional transfer of essential compression metadata.…”

MemSZ

“…Others, like in our work, avoid data compaction, allocating the worst-case storage required for the uncompressed data and focus only on memory bandwidth [29,59]. Finally, managing the metadata needed for locating and handling the compressed data is also challenging as it may add considerable memory bandwidth overheads [21,36]. MemSZ uses a metadata table and a cache of it, as in [48], which is updated with the translation lookaside buffer (TLB) and adds a few bytes of bandwidth overhead at every TLB miss; still, techniques like Attaché could be used to further reduce the metadata cost [36].…”

Avr

“…Others, like in our work, avoid data compaction, allocating the worst case storage required for the uncompressed data and focus only on memory bandwidth [44]. Finally, managing the metadata needed for locating and handling the compressed data is also challenging as it may add considerable memory bandwidth overheads [12,20]. AVR uses a metadata table and a cache of it, as in [31], which is updated with the TLB and adds a few bytes of bandwidth overhead at every TLB miss; still techniques like Attache [20] could be used to further reduce the metadata cost.…”