A victim cache is a small, typically fully associative cache placed in the refill path of a CPU cache. It stores all the blocks evicted from that level of cache and was originally proposed in 1990. In modern architectures, this function is typically performed by Level 3 or Level 4 caches.
Overview
[edit]Victim caching is a hardware technique to improve performance of caches proposed by Norman Jouppi. As mentioned in his paper:[1]
Miss caching places a fully-associative cache between cache and its re-fill path. Misses in the cache that hit in the miss cache have a one cycle penalty, as opposed to a many cycle miss penalty without the miss cache. Victim Caching is an improvement to miss caching that loads the small fully-associative cache with victim of a miss and not the requested cache line. [1]
A victim cache is a hardware cache designed to reduce conflict misses and enhance hit latency for direct-mapped caches. It is utilized in the refill path of a Level 1 cache, where any cache-line evicted from the cache is cached in the victim cache. As a result, the victim cache is populated only when data is evicted from the Level 1 cache. When a miss occurs in the Level 1 cache, the missed entry is checked in the victim cache. If the access yields a hit, the contents of the Level 1 cache line and the corresponding victim cache line are swapped.
Though initially proposed by Jouppi to improve cache performance of a direct-mapped cache Level 1, modern day microprocessors with multi-level cache hierarchy employ Level 3 or Level 4 cache to act as victim cache for the cache lying above it in the memory hierarchy. Intel's Crystal Well[2] of its Haswell processors introduced an on-package Level 4 cache which serves as a victim cache to processor's Level 3 cache.[3] A 4–12 MB Level 3 cache is used as a victim cache in POWER5 (IBM) microprocessors.
Background
[edit]As hardware architecture and technology advanced, processor performance and frequency increased at a much faster rate than memory cycle times, resulting in a significant performance gap. The challenge of rising memory latency compared to processor speed has been addressed by incorporating high-speed cache memory.
Direct-mapped caches have faster access time than set-associative caches. However, in direct-mapped caches, when multiple cache blocks in memory map to the same cache line, they end up evicting each other whenever one of them is accessed. This issue, known as the cache-conflict problem, arises due to the limited associativity of the cache. Increasing cache associativity can mitigate this problem, but there are implementation complexities and limitations to how much associativity can be increased. To address the cache conflict problem within the constraints of limited cache associativity, a victim cache is often employed.
Implementation
[edit]The behavior of a victim cache in its respective interaction with the corresponding level cache is given below:
Cache Hit: No action
Cache Miss, Victim Hit: The block is in the victim cache and the one in the cache are replaced with each other. This new entry in victim cache becomes the most recently used block.
![](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Victim_Cache_Implementation_Example.svg/220px-Victim_Cache_Implementation_Example.svg.png)
Cache Miss, Victim Miss: The block is brought to cache from next level. The block evicted from the cache gets stored in Victim cache.
Example
[edit]Consider a direct-mapped L1 cache with blocks A, B pointing to the same set. It is linked to a 2 entry fully associative victim cache with blocks C, D in it.
The trace to be followed: A, B, A, B...
From the diagram, we can see that, in case of victim cache (VC) hit, blocks A and B are swapped. The least recently used block of VC remains as it is. Hence, it gives an illusion of associativity to the direct-mapped L1 cache, in turn reducing the conflict misses.
In case of two caches, L1 and L2 with exclusive cache policy (L2 does not cache same the memory locations as L1), L2 acts as the victim cache for L1.
Performance implications
[edit]While measuring performance improvement by using victim cache, Jouppi[1] assumed a Level-1 direct-mapped cache augmented with a fully associative cache. For the test suite used by him, on an average 39% of the Level-1 data cache misses are found to be conflict misses, while on an average 29% of the Level-1 instruction misses are found to be conflict misses.[1] Since conflict misses amount to large percentage of total misses, therefore providing additional associativity by augmenting the Level 1 cache with a victim cache is bound to improve total miss rate significantly.
Experimental results are deduced by considering a 32-Kb Direct-Mapped, 2-way and fully associative cache augmented with a 256 block (8 KB) victim cache and running on it 8 randomly selected SPEC95 Benchmarks.[4] While the results cannot be generalized for all benchmarks, adding a victim cache provides a miss rate reduction ranging from 10% to 100% for all the cache configuration.[4] The returns although seem to level off beyond victim cache size of 50 blocks, thus proving Jouppi's[1] observation that victim cache benefits reach a plateau after the first few victim blocks.[4]
Miss rate reduction for a 64 KB cache size are found to be significantly lower, proving that victim caching is not indefinitely scalable.[4]
While comparing various cache configuration it was found that in certain cases adding a small victim cache can give performance benefit equivalent to that observed by multiplying the cache size by 2.[4]
References
[edit]- ^ a b c d e Jouppi, N. P. (1990-05-01). Improving direct-mapped cache performance by the addition of a small fully-associative cache and prefetch buffers. 17th Annual International Symposium on Computer Architecture, 1990. Proceedings. pp. 364–373. doi:10.1109/ISCA.1990.134547. ISBN 0-8186-2047-1.
- ^ "Products (Formerly Crystal Well)". Intel® ARK (Product Specs). Retrieved 2016-11-16.
- ^ Shimpi, Anand Lal. "Intel Iris Pro 5200 Graphics Review: Core i7-4950HQ Tested". Retrieved 2016-11-16.
- ^ a b c d e Wasserman, Hal (Spring 1996), "Victim-Caching for Large Caches and Modern Workloads", Computer Science 252 Project, University of California, Berkeley