You need to enable JavaScript to run this app.
最新活动
大模型
产品
解决方案
定价
生态与合作
支持与服务
开发者
了解我们

冲突缓存缺失(Conflict Miss)究竟是什么?——容量缺失与冲突缺失的区别及实例场景判定

缓存缺失类型:强制、冲突与容量缺失的清晰区分

Hey there! Let's break this down step by step, starting with clear definitions, then tackling your specific example and questions.

First, Let's Lock Down the Core Definitions

To avoid confusion, let's start with standard, agreed-upon definitions (from classic computer architecture textbooks):

  • Compulsory Miss (Cold Start Miss): This happens when you access a memory block for the first time—the cache has never seen this block before, so you have to load it from memory. It's unavoidable, no matter how big or how your cache is structured.
  • Conflict Miss: This occurs in set-associative or direct-mapped caches when multiple memory blocks map to the same cache set, and that set's associativity (number of lines it can hold) isn't enough to keep all those blocks in cache at once. The key here: the cache has enough total capacity to hold your working set, but the mapping rule forces blocks to compete for space in a single set. Switching to a fully associative cache (where blocks can go anywhere) would eliminate these misses.
  • Capacity Miss: This happens when the cache's total capacity is too small to hold all the blocks your program needs (your working set). Even if you use a fully associative cache, you'll still have to replace blocks because there's just not enough space overall.

Your Example: What Type of Miss Is the Address 3 Access?

Let's walk through your scenario again: 4-set, 2-way associative cache, all addresses map to Set 1. Set 1 is full with blocks from Address 1 and 2, now you access Address 3.

First: This is a compulsory miss—Address 3 is being accessed for the first time, so the cache has no copy of it, and you have to load it from memory. The fact that you need to replace an existing block in Set 1 is a side effect of conflict, but the root cause of the miss itself is the first-time access.

That said, the need to replace a block here is due to conflict—if this were a fully associative cache, you could just put Address 3 in any empty set (since the total cache capacity is 8 lines, way more than your 3-block working set). But the miss type is determined by why you had to go to memory: first-time access = compulsory miss.

Later, if you revisit Address 1 (which was replaced by Address 3), that will be a conflict miss—Address 1 was already in cache before, but it got evicted because the set it maps to couldn't hold all three blocks at once.


Your Other Questions Answered

1. Do conflict misses affect all cache sets?

Nope! Conflict misses are isolated to specific sets. In your example, only Set 1 has this problem—your other 3 sets are completely empty and won't experience any conflict misses unless you start accessing addresses that map to them and fill their lines to capacity. Conflict misses only happen when a single set is being asked to hold more blocks than its associativity allows.

2. What's the key difference between capacity and conflict misses?

The litmus test is: Would the miss go away if you switched to a fully associative cache with the same total capacity?

  • If yes → it's a conflict miss (the problem was the mapping rule forcing blocks into the same set, not the total space).
  • If no → it's a capacity miss (the cache is just too small to hold your entire working set, no matter how you arrange the blocks).

3. How do capacity and conflict misses show up in your example?

  • Capacity misses are not present here: Your cache has 8 total lines, and your working set is only 3 blocks. Even a fully associative cache could hold all 3 blocks at once, so there's no capacity issue.
  • Conflict misses show up in follow-up accesses: After replacing Address 1 with Address 3, if you try to read Address 1 again, that's a conflict miss. The cache has enough total space to hold Address 1, 2, and 3—but because they all map to the same set, the set can't hold all three, so Address 1 got evicted.

内容的提问来源于stack exchange,提问作者Daniel Catalano

火山引擎 最新活动