LLC Hash 终极推导笔记

基于 d = (a+c) mod 24 的物理对齐，在 LLC 内部完美重构地址均匀性的推导过程。

一、 物理限制与数学解构

设原始连续块地址为 X。Memory Controller 产生两个核心变量：

• a = X mod 24 (物理 Bank 索引)
• b = floor(X / 24) (Bank 内行列偏移)

MC 内部生成 c = Hash(b)，并送出受污染的 Bank ID：

二、 基础数学还原 (Base Math Reconstruction)

要在 LLC 内部剥离 c 重构 a，只需执行 d - c，并加上 24 避免负数取模：

这实现了连续地址拷贝下 100% 完美的 64 Set 轮询。

三、 封神之战 —— 全位宽折叠魔法

在应对 Stride 时，我们不使用保守的 b[3] 起手，而是暴力引入包含 b[0] 的全位宽异或。为什么宏观上依然 100% 均匀？

• 交织规格是 24 Bank，b 的翻转时机永远在 X = 24, 48, 72... 边界上。
• 24 是 8 的整数倍！
• 用低位异或，只会让地址在每 8 个 Set 的内部集合中发生两两互换。

因为边界完美对齐 8，地址被绝对禁锢在局部 8-Set 闭环中，绝不发生跨区跳跃空洞。从而达成了微观极速抗 Stride、宏观绝对均匀的终极目标。

经典案例：Stride 下的损耗溯源与架构深挖

第一步：拆解 2048B 步长的“空洞”

在 Cache Line 为 512B 的前提下，Stride = 2048B 意味着：每次地址跳跃的块步长（Block Stride） = 2048 / 512 = 4。

所以，原始块地址 X 的变化序列是：0, 4, 8, 12, 16 ...

在我们代码的策略中，第一步是基础还原（base_set_id）。它完美消除了 24 Bank 的干扰，等于直接对 X 取模 64。
既然 X 永远是 4 的倍数，那么 base_set_id 的结果永远只能是 0, 4, 8, 12 ... 60。64 个 Set 中只有 16 个 Set 在干活，剩下的 48 个 Set 完全是瞎子，命中率为 0。

第二步：拯救空洞的“高位折叠”为什么慢了？

为了填补空洞，我们引入高位地址 XOR 异或：high_entropy = (b >> 6) & 63。
关键损耗点：b >> 6 变化得太慢了！

• b 是由 X / 24 产生的。
• X 每次加 4，那么 b 每次只增加 4 / 24 = 1/6。
• 要想让 b >> 6 增加 1，b 必须跨过 64 的整数倍。
• 需要多少笔请求才能让 b 增加 64？答案是：64 × 6 = 384 笔请求！

第三步：算一笔精确到个位的账 (1024笔请求)

第四步：推导 75% 得分的由来

• 理想状态： 1024 笔 / 64 Set = 每 Set 命中 16 次。
• 实际偏差： 32个Set超载(多8次=256)；16个Set饥饿(少16次=256)。
• 均匀度得分： 100% × (1 - 256 / 1024) = 75.00%

---

架构设计的终极反转：从 b[3] 到全位宽折叠

第五步：工业界的权衡 —— 为什么要加低位抽头？

既然用低位 XOR 会打碎连续轮询，为什么还要加进来？答案是：保住了“宏观均匀度”，但牺牲微观顺序。
为什么保守策略从 b[3] 开始？
在连续访问下：b[0] 翻转需 24 笔，b[1] 需 48 笔，b[2] 需 96 笔，b[3] 需 192 笔！
192 刚好是 64 的 3 倍。用 b[3] 做 XOR，在翻转前能完美遍历 64 个 Set 整整 3 圈。总命中数绝对均匀！

第六步：打破盲区 —— 引入 b[0] 与 8 块拼图魔法

完美的 8 块拼图解密：
当把全位宽 b[5:0] 引入异或，b 会经历 0, 1, 2 阶段。

第七步：为什么能这么巧？

因为 24 Bank 是 8 的整数倍！
b 翻转永远对齐在 8 的倍数上。低位异或只会让地址在每 8 个 Set 内部打乱重组，绝不跨界。从而造就了全频段抗 Stride 的神级策略！