Chapter 6: Allison Hamann, Chris Barile

From PG_Wiki
Jump to: navigation, search


Victim Cache

Victim caches were first proposed by Norman P. Jouppi in 1990. Victim caching implements a small, fully-associative cache between direct-mapped L1 memory and the next level of memory. The cache allows lines evicted from the L1 cache a “second-chance” by loading them into the victim cache. Victim caches decrease the overall conflict miss rate (Jouppi).

Direct-mapped caches can especially benefit from victim caching due to their large miss rates. Victim caching allows direct-mapped caches to still be used in order to take advantage of their speed while decreasing the miss rate to an even lower rate than the miss rate found in set-associative caches (Jouppi).

Handling Misses

Jouppi's illustration of victim caching.

The proposed victim cache is fully-associative and lies between the L1 memory and the next level of memory. While Jouppi proposed a victim cache with 1 to 5 entries, Naz et al. proposed that the victim caches should be 4 to 16 cache lines.[1][2] Regardless of the size, when a miss occurs in the L1 cache, the victim cache is then scanned for the wanted line. If a miss occurs in both the L1 and victim cache, the needed line is then pulled from the next level, and the line evicted from the L1 cache is then placed in the victim cache. If a miss occurs in the L1 cache but hits in the victim cache, the two lines are swapped between the two caches. Thus, this eliminates the majority of conflict misses that occur due to temporal locality.


Victim caching can be found in AMD's Opteron processor series produced specifically for servers and workstations. [3] Opteron processors use a victim cache that is capable of holding eight victim blocks. [4]

Sector Cache

One early cache organization technique was sector cache. It was used on the IBM 360/85, which was one of the earliest commercial CPUs[5]. Sector cache allowed for smaller tag sizes, which made searching in cache easier and quicker, without requiring cache lines to be excessively long.[5] It was also easier to build with the circuit technology of the time.[5] In testing during the design of the IBM 360/85, it was found to run at 81% of the maximum ideal efficiency calculated by IBM's designers.[6] Sector caches were later replaced by set associative caches, which were found to be more efficient.[5]


Sectors in cache are made of subsectors. Each subsector has a validity bit indicating whether or not it has been loaded with data.
The cache is divided into sectors, which correspond to logical sectors on the main storage device.[6] When sectors are needed, they are not loaded into cache all at once, but in smaller pieces known as subsectors.[6] Subsectors are similar to the lines in a direct mapped cache, and are only loaded into cache when needed. This prevents large amounts of data from having to be transferred for every memory reference. Subsectors have a validity bit that indicates whether they are loaded with data or not.[6]

Miss Handling

When a process requests data from a disk sector that is not in the cache, a cache sector is assigned to the sector on the main storage device where the requested data is stored.[6] Then the subsector where the data is located is loaded into the cache. The subsector's validity bit is then set to reflect that it has been loaded from the main storage.[6] When data from other subsectors within a loaded sector are requested, the system loads those subsectors into the cache sector and sets their validity bits.[6] Sectors are not removed from the cache until the system needs to reclaim the space to process another request.[6]


  4. Hennessy, John L., and David A. Patterson. Computer Architecture: A Quantitative Approach. Elsevier, Inc., 2012, p. B-14.
  5. 5.0 5.1 5.2 5.3 Rothman, Jeffrey B. and Alan Jay Smith. Sector Cache Design and Performance
  6. 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Liptay, J. S. Structural Aspects of the System/360 Model 85, Part II: The Cache.
Personal tools