这篇论文提出的是 Alecto（2025 HPCA）：

TLDR：

现有预取器选择算法存在两个核心限制：输入 demand request 分配不精确，选择粒度太粗
提出 DDRA（Dynamic Demand Request Allocation）原则——将 demand request 动态分配给合适的预取器，让每个预取器只接收属于自己擅长领域的训练数据
基于 DDRA 原则设计 Alecto 框架，通过 Allocation Table（按 PC 索引的状态机）实现细粒度预取器识别，并将预取器选择与 demand request 分配过程集成，同时利用 Sandbox Table 过滤重复预取请求

背景和动机

商用处理器通常混合使用多种预取器（stream、stride、spatial、temporal）来覆盖不同的访存模式。然而多个预取器共享硬件资源（prefetch table、prefetch queue、cache space、DRAM 带宽），会产生冲突，互相干扰。为此，已有多种预取器选择/协调算法被提出，但存在两个核心限制：

Limitation 1: 输入 demand request 分配不精确。 现有方案主要控制预取器的输出（开关、激进度、输出优先级），但不阻止不相关的 demand request 去训练不合适的预取器。这导致预取器表被不恰当的 demand request 污染，有用的表项被替换，prefetcher table miss rate 上升。

Limitation 2: 预取器选择粒度太粗。 现有方案对所有 demand request 使用统一的选择规则，无法区分不同 PC 产生的不同访存模式。例如 Fig.2 中 459.GemsFDTD 的两个 PC 交织产生 spatial 和 stream 两种模式，粗粒度规则无法正确分辨。

Insight

核心观察：对于大多数 cache 预取算法，预取请求的生成与训练过程内在关联——控制哪些 demand request 能被预取器访问，就间接控制了预取器的输出。 因此，与其在输出端做选择/过滤，不如在输入端做精准分配。

具体来说：

来自同一 PC 的 demand request 通常呈现一致的访存模式，因此可以按 PC 粒度判断每个预取器的适用性
利用历史 prefetching accuracy 作为判断预取器是否适合某条 memory access instruction 的依据
将预取器选择集成到 demand request 分配过程中（而不是分离的两个阶段），实现 selection 和 allocation 的统一

核心设计

Alecto 的核心设计包括三个方面：

Fine-grained Prefetcher Identification：通过 Allocation Table 按 PC 粒度记录每个预取器的状态，识别适合/不适合的预取器
Dynamic Demand Request Allocation：根据识别结果，只将 demand request 路由给合适的预取器，不合适的预取器不接收训练数据
Duplicate Prefetch Filtering：扩展 Sandbox Table 作为 prefetch filter，过滤重复预取请求

1. Allocation Table 与状态机

Allocation Table 按 PC 地址索引，为每个 PC 的每个预取器维护一个状态。三种状态：

UI (Un-Identified)：预取器适用性未确定。采用保守策略，分配 demand request 但限制预取度为保守值 c
IA_m (Identified and Aggressive)：预取器被识别为高效。分配 demand request 并提升预取度为 c+m+1（m 从 0 到 M）
IB_n (Identified and Blocked)：预取器被识别为不适合。关闭 demand request 流，暂时屏蔽 n 个 epoch（n 从 -N 到 0）

状态转移由两个阈值驱动：

PB (Proficiency Boundary)：accuracy >= PB 则提升为 IA
DB (Deficiency Boundary)：accuracy < DB 则降级为 IB

关键设计点：IB 状态不是永久屏蔽，而是暂时屏蔽 N 个 epoch 后重新评估（因为 PC 的访存模式可能随时间变化）

2. Dynamic Demand Request Allocation

当 demand request 进入 Allocation Table 时：

查找该 PC 对应的各预取器状态
UI 和 IA_m 状态的预取器：生成 identifier，包含预取器编号和预取度
IB_n 状态的预取器：不生成 identifier，即不分配 demand request

预取度管理：UI 状态预取 c 条 cache line 到本级 cache；IA_m 状态预取 c 条到本级，额外 m+1 条到下级 cache，从而在提升 coverage 的同时管理 cache 空间。

3. Runtime Metrics Gathering（Sample Table + Sandbox Table）

Sample Table（按 PC 地址索引）：记录每个预取器发出的预取请求数（IssuedByP1）和被后续 demand 确认命中的数量（ConfirmedP1），用于计算 accuracy
Sandbox Table（按访存地址索引）：记录最近发出的预取请求及其来源 PC，当 demand request 命中时反馈给 Sample Table
Demand Counter：每 100 次 demand access 触发一次 epoch 状态转移
Dead Counter：饱和计数器，检测 IA 状态的预取器长期不产生预取请求的死锁情况，超过阈值（150）则重置为 UI

4. Duplicate Prefetch Filtering

Sandbox Table 兼做 prefetch filter：预取请求发出前查询 Sandbox Table，若地址已存在（tag hit）则丢弃该请求，避免重复预取。这一机制不需要额外存储开销。

5. Temporal Prefetching 优化

Alecto 的 DDRA 机制天然适合优化 temporal prefetcher 的元数据存储利用率。通过状态机事件过滤三类不需要训练 temporal prefetcher 的 demand request：

Non-temporal PC（由事件 3 过滤）
同时被 non-temporal prefetcher 处理的 PC（由事件 1 或更高级 cache 过滤）
Rare recurrence PC（由事件 3 过滤）

相比 Triangel 等专用方案，Alecto 作为通用框架即可实现类似功能，存储开销 < 1KB。

实验 Setup

实验平台：gem5 执行驱动模拟器，参数参考 Intel Skylake 配置

系统设置：

1-8 核，256-entry ROB，6-wide fetch/decode，8-wide issue
L1 I/D cache: 32KB 各，8-way；L2: 256KB，8-way；L3: 2MB/core，16-way（CHAR 替换策略）
主存：SC 单通道，MC 多通道，DDR4-2400

预取器组合：

Stream prefetcher (GS, from IPCP)
Stride prefetcher (CS, from IPCP)
Spatial prefetcher (PMP)
均实现在 L1 data cache，使用虚拟地址训练

Alecto 参数：N=8, M=5, c=3, PB=0.75, DB=0.05

对比方案：IPCP, DOL, Bandit3, Bandit6

Workload：SPEC CPU2006, SPEC CPU2017, PARSEC 3.0, Ligra；单核用 simpoint checkpoint（warm-up 100M + simulate 100M instructions），多核用 ROI checkpoint（warm-up 250M + simulate 250M）

实验结果

实验 1: 单核总体性能

设计：在 SPEC06 和 SPEC17 上比较各预取器选择算法相对于无预取的 IPC 加速。

结果：

SPEC06: Alecto 超过 IPCP 8.14%, DOL 8.04%, Bandit3 4.77%, Bandit6 3.20%
SPEC17: Alecto 超过 IPCP 5.47%, DOL 5.65%, Bandit3 3.67%, Bandit6 2.32%
平均超过 SOTA（Bandit）2.76%；memory-intensive benchmarks 上超过 Bandit6 5.25%

结论：Alecto 在单核场景下全面优于现有预取器选择算法，尤其在 memory-intensive workload 上优势明显。

实验 2: Prefetching Metrics 分析

设计：统计各方案的 covered (timely/untimely), uncovered, overprediction 分布。

结果：Alecto 的 prefetching accuracy 比 Bandit6 高 13.51%，同时不牺牲 coverage 和 timeliness。

结论：Alecto 能更好地平衡 accuracy、coverage 和 timeliness 三个指标。

实验 3: 不同预取器组合的泛化性

设计：将 stride prefetcher 换成 Berti，spatial prefetcher 换成 CPLX，测试 Alecto 的泛化能力。

结果：Alecto 平均超过 IPCP 8.52%, DOL 8.68%, Bandit3 5.02%, Bandit6 2.04%。

结论：Alecto 对不同预取器组合具有良好泛化性。

实验 4: Temporal Prefetching

设计：在 L1 composite prefetcher + L2 temporal prefetcher 配置下比较 Alecto、Bandit、Triangel。

结果：Alecto 超过 Bandit 8.39%, Triangel 2.18%。在不同 metadata table size 下，Alecto 用 <256KB 即可达到 Bandit 用 1MB 的性能。

结论：Alecto 的 DDRA 显著提升 temporal prefetcher 的元数据利用效率。

实验 5: 多核评估

设计：8 核配置下评估各方案在 SPEC06/17、PARSEC、Ligra 上的性能。

结果：Alecto 平均超过 IPCP 10.60%, DOL 11.52%, Bandit3 9.51%, Bandit6 7.56%。

结论：多核场景下 Alecto 优势更大，因为 Bandit 的粗粒度 RL 在多核干扰下更容易陷入次优策略。

实验 6: 存储开销

结果：Alecto 总存储开销约 1.30KB（P=3），排除 Sandbox Table 约 760B。Bandit 在相同配置下需要 4KB（5.4x），且随预取器数量指数增长。

结论：Alecto 存储可扩展性远优于 RL-based 方案。

实验 7: 能耗

设计：用 CACTI 在 22nm 工艺下建模能耗。

结果：Alecto 减少预取器表访问能耗 48%（整个 memory hierarchy 降低 7%）。每个预取器的训练次数减少 48%。

结论：DDRA 通过减少不必要的训练直接降低预取器能耗。

实验 8: Ablation Study

设计：将 Alecto 的预取度调整功能去掉（固定预取度），只保留 demand request allocation。

结果：仅 allocation 即可超过 Bandit6 4.34%，加上预取度调整后超过 5.25%。

结论：Alecto 的主要性能收益来自 demand request allocation，预取度调整提供额外增益。

Limits

Accuracy 作为唯一判断指标的局限：Alecto 仅使用 prefetching accuracy 判断预取器适用性，未考虑 coverage 和 timeliness。虽然实验表明这在多数场景有效，但可能存在 accuracy 高但 coverage 低的情况被过度优先。
PC 粒度假设的局限：Alecto 假设来自同一 PC 的 demand request 呈现一致的访存模式。对于同一 PC 在不同执行阶段产生不同模式的情况（phase change），需要依赖 Dead Counter 机制来检测并重置，响应可能不够及时。
阈值敏感性：PB、DB、N、M、c 等参数需要预先设定，论文中通过实验选定但未深入分析不同 workload 下的敏感性（除了简要提到可通过 CSR 微调）。
仅评估了 L1 级别的预取器选择：所有 non-temporal 预取器均放在 L1，虽然讨论了跨 cache level 的 temporal prefetching 场景，但未评估多级 cache 均有预取器时的表现。
Sandbox Table 容量限制：512 entry 的 Sandbox Table 在高预取率场景下可能频繁替换，影响 accuracy 计算和 duplicate filtering 的准确性。

Alecto (2025 HPCA): Integrating Prefetcher Selection with Dynamic Request Allocation Improves Prefetching Efficiency