核心结论：Snoop Filter（SF）的有效跟踪容量应配置为全系统 RN-F 缓存总和的 1.5× ~ 2×。这一结论并非工程经验值的外推，而是由组相联结构下的泊松分布尾部概率严格导出。SF 的容量直接决定了全系统缓存的有效利用率上限。
1. 问题定义
多核 SoC 中，片上互联（Interconnect）依赖 Snoop Filter 作为分布式目录，追踪每一行缓存数据在全网各节点中的副本分布，从而将一致性维护从全向广播收敛为定向侦听。
目录的物理容量是有限的。当 SF 容量不足以覆盖所有活跃缓存行时，它必须主动击落（Back-Invalidate）节点中仍在使用的缓存副本。由此引出一个具有直接工程代价的架构问题：
SF 的容量应当如何确定？容量不足的后果是什么？是否存在一个量化上充分的容量下界？
本文从协议约束出发，建立概率模型，给出可量化的回答。
2. 协议前提：严格包含（Strict Inclusion）
基于目录的一致性协议要求 SF 满足严格包含（Strict Inclusion）：
若任一 RN-F 的缓存中持有某行数据，则 SF 的目录中必须存在该行的跟踪记录。
SF 是系统内各节点缓存状态的唯一真实来源。其直接推论是：
当 SF 因容量耗尽而需逐出一个条目时，即使对应 RN-F 仍在活跃使用该数据，SF 也必须通过
SnpCleanInvalid将该缓存副本强制击落（Back-Invalidate）。
由此得到本文的基本关系：
Snoop Filter 的物理容量，实质上划定了全系统 L1/L2 缓存有效利用率的上界。
换一个角度看：假设系统有 64 个核心，每核心配备 1MB L2 缓存，名义缓存总量 64MB。若 SF 无法容纳对应数量的跟踪条目，它将以冲突驱逐的方式持续击落（Back-Invalidate）缓存行——那 64MB 的名义容量在实际运行中无法被充分利用。
补充说明：早期目录协议中曾存在一种"溢出降级"策略：当 SF 满时，将对应地址标记为未跟踪，后续以全向广播兜底。该策略在现代高阶互联总线中已被废弃，原因是其引发的广播风暴对带宽和功耗的冲击不可接受。当前标准强制依赖主动 Back-Invalidate，容量不足的代价没有退路。
3. 组相联与哈希冲突：总容量充裕不等于不溢出
一个直接的直觉是令 SF 条目数大于等于全网缓存行总数。这个直觉忽略了一个关键实现约束：组相联（Set-Associative）结构。
将 SF 类比为一个停车场：
- 共 $S$ 个停车区（Set，组）；
- 每区 $A$ 个车位（Way，相联度），典型值为 16；
- 每辆车（缓存行）经哈希映射到唯一确定的组，不可跨组停泊。
由此产生一个反直觉的现象：
即使整个停车场存在大量空位，只要某个组已满（达到 A 辆车），后续映射至该组的车辆将无处停泊——必须从该组中逐出一辆。
这就是组溢出（Set Overflow）。问题由此从确定性容量比较转变为概率问题：给定 $S$ 个组，$N_{cache}$ 个缓存行经哈希均匀分配到各组，有多少个组会溢出？
4. 概率模型：从二项分布到泊松极限
设全系统活跃缓存行总数为 $N_{cache}$，SF 有 $S$ 个组，哈希函数足够均匀（每个缓存行落入任一组的概率 $p = 1/S$）。
4.1 二项分布
某个特定组收到恰好 $k$ 个缓存行，服从二项分布：
$$ X \sim B(N_{cache},\ 1/S), \qquad P(X=k) = \binom{N_{cache}}{k} p^k (1-p)^{N_{cache}-k} $$
4.2 泊松逼近
现代 SoC 规模下，$N_{cache}\to\infty$、$S\to\infty$、$p\to 0$，而期望 $\lambda = N_{cache}\cdot p$ 保持常数。由泊松极限定理：
$$ P(X=k) \to \frac{\lambda^k e^{-\lambda}}{k!}, \qquad \lambda = \frac{N_{cache}}{S} $$
4.3 参数化简：λ = A / R
引入两个架构参数：
- SF 总条目数 $N_{sf} = S \times A$，因此 $S = N_{sf}/A$；
- 超配比（Over-provisioning Ratio） $R = N_{sf} / N_{cache}$，因此 $N_{cache} = N_{sf}/R$。
代入 $\lambda$：
$$ \lambda = \frac{N_{cache}}{S} = \frac{N_{sf}/R}{N_{sf}/A} = \frac{A}{R} $$
关键性质：每组预期负载 $\lambda$ 仅依赖相联度 A 和超配比 R，与系统的绝对规模无关。这意味着容量选型结论可以跨规模复用，与核心数、缓存总量解耦。
4.4 溢出概率
一个相联度为 A 的组的物理容量上限为 A。当负载 $X > A$ 时发生溢出，触发 Back-Invalidate：
$$ \boxed{\ P(\text{溢出}) = P(X>A) = 1 - \sum_{k=0}^{A} \frac{\lambda^k e^{-\lambda}}{k!} = \texttt{poisson.sf}(A,\ \lambda=A/R)\ } $$
5. 数值结果：断崖曲线（A = 16）
将上述公式绘制为曲线（图 1），呈现一个显著特征：从 $R=1.0$ 到 $R=2.0$，组溢出率经历断崖式下跌。
图 1：组溢出概率 vs 超配比。A=16（实线），A=8/24 为对比。红色区域为危险区，绿色区域为 1.5×~2× 安全区。
精确数值（A=16）如下表，同时给出两个互补指标：
| 超配比 R | 每组负载 λ=A/R | 组溢出率 P(X>A) | 冲突驱逐行占比 E[(X−A)⁺]/λ | 评价 |
|---|---|---|---|---|
| 1.00 | 16.00 | 43.40% | 9.92% | 近半数组超载，不可用 |
| 1.25 | 12.80 | 15.05% | 3.09% | 溢出率仍偏高 |
| 1.50 | 10.67 | 4.46% | 0.90% | 工业界常用下限 |
| 1.75 | 9.14 | 1.28% | 0.26% | 性能余量充足 |
| 2.00 | 8.00 | 0.37% | 0.08% | 安全区 |
- 组溢出率 P(X>A)：超载组的比例，与上文公式一致，是核心指标；
- 冲突驱逐行占比 E[(X−A)⁺]/λ：实际被冲突踢出的缓存行比例，更贴近"缓存浪费"的直觉。
对 R=1.0 处数值的说明：当 $R=1.0$ 时，组溢出率为 43% 而非直觉中的个位数。原因在于此时平均负载恰好等于组容量（$\lambda=A=16$），泊松分布的离散性使得近半数组的负载落在容量线右侧。需注意 43% 是超载组的比例，不是被浪费的缓存比例——后者约为 9.9%（对应驱逐行占比）。两个数值都远高于个位数水平，R=1.0 在任何工程场景下均不可接受。
6. 溢出本质：泊松尾部的几何解释
将三条不同 R 值对应的泊松分布同时绘制（图 2），溢出的本质在几何上非常清晰：
图 2：每组负载的泊松分布。竖虚线为组容量 A=16，右侧阴影区域即溢出尾部（触发 Back-Invalidate）。
- R=1.0（λ=16）：分布中心恰好落在容量线上，右半侧大量概率质量溢出 → 尾部占比约 43%；
- R=1.5（λ=10.67）：分布主体已退至容量线左侧，仅余一小段尾部 → 4.46%；
- R=2.0（λ=8）：分布中心距容量线超过两个标准差，尾部几乎消失 → 0.37%。
超配的本质操作，是将整条泊松分布向左侧平移，直至尾部面积坍缩至可忽略的区间。
7. 选型法则：1.5× ~ 2×
综合曲线和数值分析，工业界通行的容量选型法则获得了严格的数学支撑：
SF 有效跟踪容量 = 全系统 RN-F 缓存总和的 1.5× ~ 2×。
各区间含义：
- 低于 1.0×：组溢出率超过 43%，系统处于不可用状态；
- 1.5×（下限）：组溢出率约 4.5%，冲突驱逐占比约 0.9%，性能代价可控；
- 2.0×（上限）：组溢出率约 0.4%，驱逐占比约 0.08%，进入安全区，面积增量可接受。
8. 容量不足的代价层级
$R = 1.0$ 看似"仅"浪费约 10% 的缓存容量，但真实代价分布在三个递进的层面。
8.1 第一层：诱导缺失（Induced Miss）
CPU 刚将热数据加载至 L1，SF 即因组冲突将其击落（Back-Invalidate）。后续访问时 L1/L2/L3 均未命中，必须重新从主存读取。这些本可避免的缺失即为诱导缺失。
8.2 第二层：CPI 恶化
量化估算模型：设理想 $CPI_{base}=1.0$，主存访问延迟 $T_{mem}=120$ cycles，每千条指令的诱导缺失数为 $\text{MPKI}_{induced}$：
$$ CPI_{actual} = CPI_{base} + \frac{\text{MPKI}{induced}}{1000} \times T{mem} $$
图 3：诱导缺失率对 CPI（左轴）与性能损失（右轴）的影响。
以 $R=1.0$ 场景为例，假设诱导缺失增加 8 MPKI：
$$ CPI_{actual} = 1.0 + \frac{8}{1000}\times 120 \approx 1.96 $$
仅 8 个额外 MPKI 的增量便导致 IPC 下降至基准的约 51%。这正是容量缺口的非线性放大效应：在命中率已处于高位的体系里，微小的缺失率增量会被主存延迟放大为显著的性能退化。
8.3 第三层：互联带宽倍增
正常缓存行读取在互联中产生约 2 个报文（请求 + 数据响应）。一旦触发 Back-Invalidate，单次访问的报文序列扩展为至少 4 个高优先级报文：SF 发出击落（Back-Invalidate）→ 节点响应击落 → 节点重新请求 → 内存返回数据。报文数量倍增叠加高优先级调度，将对 Mesh 互联造成显著的拥塞压力。
而根据第 2 节的讨论，旧的"未跟踪广播兜底"机制已被废弃——不存在容错退路，容量不足只能直接承受 Thrashing。
9. 结语
回顾本文的论证链路：
- SF 受严格包含约束，其容量构成全系统有效缓存的天花板；
- 由于组相联结构下的哈希冲突，总容量充裕不等于不溢出，溢出概率服从泊松尾部 $P(X>A)$，期望负载 $\lambda = A/R$；
- 将尾部概率压至可忽略区间，超配比需达到 1.5× ~ 2×；
- 容量不足的后果是缓存利用率下降 → CPI 恶化 → 互联带宽拥塞的递进式退化，且不存在协议层面的兜底机制。
SF 的容量选型是一笔值得严肃对待的架构账：在这块 SRAM 上过度压缩面积预算，所换取的成本节省往往远不足以弥补缓存缩水、性能退化和互联拥塞带来的系统级损失。
在 SoC 架构规划的早期阶段，SF 容量是一个值得被充分论证而非按默认值选型的参数。