L2缓存‘更新时分配（allocate-on-update）’策略的基线实现咨询

目标L2缓存特性 #

• 非阻塞（Non-blocking）
• 写分配（Write-allocate）
• 写回（Write-back）
• 简化设定：仅支持整缓存行存储（每次存储操作均分配完整缓存行）
• 无额外复杂机制：无加载/存储缓冲区、无主动重排序、无地址别名（采用物理寻址）、无缓存一致性机制

缓存缺失处理策略 #

加载操作触发缺失时，有两种基础处理策略：

1. 缺失时分配（Allocate-on-miss）：实现简单但效率偏低
   • 缺失发生时立即分配缓存行
   • 当下层缓存返回数据时：
     • 仅在该行仍存在于缓存中时，才更新缓存内容
     • 响应待处理的加载请求
2. 更新时分配（Allocate-on-update）：实现复杂度更高
   • 缺失发生时不分配缓存行
   • 当下层缓存返回数据时：
     • 在缓存中分配对应行
     • 响应待处理的加载请求

核心问题 #

更新时分配策略的基线实现方案是什么？

最坏场景示例 #

考虑以下执行序列：

store 10 → mem[0x1000]   // 分配缓存行
...                      // 缓存行[0x1000]被驱逐
load  a  ← mem[0x1000]   // 缺失（不分配），向下层缓存发起请求
store 20 → mem[0x1000]   // 重新分配缓存行（简化设定下存储适配整行）
...                      // 缓存行[0x1000]再次被驱逐

                         // 之前请求的过期数据抵达
                         // 尝试更新[0x1000]=10
                         // 此时不应在缓存中分配该行
...
load  b ← mem[0x1000]    // 必须避免加载过期数据

当前挑战与标准解决方案 #

当前核心挑战是：即使缓存行已被驱逐，也要避免应用过期的更新操作（比如上述场景中，先发起的过时写操作[0x1000]=10的响应晚于后续的写操作20→[0x1000]）。需要高效追踪这类信息，但L2缓存采用全相联的“过期存储缓冲区”这类方案并不现实。

针对该问题的标准解决方案是为每个物理地址绑定单调递增的版本号，具体实现逻辑如下：

• 为每个物理地址维护一个版本号，初始值为0，每次该地址对应的缓存行被分配（包括首次分配或重新分配）时，版本号递增。
• 当加载缺失发起请求时，记录当前目标地址的版本号（若缓存中无该行，则记录当前的“预期版本号”为下一个递增后的值）。
• 当下层缓存返回数据时，先核对目标地址的当前版本号与请求时记录的版本号：
  • 若缓存中存在该行，仅当版本号匹配时，才用返回数据更新缓存。
  • 若缓存中无该行，仅当当前版本号与请求时记录的版本号一致（即期间无新的分配操作）时，才分配该行并写入数据。
• 缓存行被驱逐时，版本号与物理地址绑定保留，后续重新分配时继续递增。

这种方案通过轻量的版本号追踪，避免了过期数据覆盖最新缓存状态，且实现开销远低于全相联缓冲区，适配L2缓存的设计需求。

内容的提问来源于Stack Exchange，提问作者Konstantin Kazartsev