背景问题

这篇论文研究的是：如何在处理器里同时协调 data prefetching（数据预取）和 off-chip prediction（片外访问预测，OCP）

作者的核心观察是三点：

  1. 预取器和 OCP 往往是互补的
    • 预取器擅长“提前把未来会访问的数据拉到缓存里”，如果预测准、时机也对，收益很高；
    • OCP 是对“当前这个已知地址的 load 会不会一路 miss 到内存”做二分类预测，然后尽早向内存发起请求，所以它通常更容易做准，但时效性不如预取器
  2. 简单把两者同时打开并不一定好，尤其是在带宽紧张时，预取器可能因为错误预取带来带宽浪费和缓存污染，反而把 OCP 本来能带来的收益掩盖掉
  3. 已有控制策略要么不够灵活，要么性能上还有明显缺口

论文用一个实验说明这种互补性：

  • 在 100 个 memory-intensive workload 上，L2 预取器 Pythia 对大多数 workload 有益，但对 40/100 的 workload 反而伤害性能
  • 在这些“prefetcher-adverse” workload 中，POPET 这样的 OCP 还能平均提升 1.4%，而 Pythia 平均退化 11.6%
  • 在“prefetcher-friendly” workload 中，Pythia 的平均收益达到 16.0%，高于 POPET 的 5.9%

作者因此认为，两者不是简单替代关系，而是适合不同阶段、不同资源条件下的不同工具

简单组合 存在的问题

  • 构造了一个 baseline：Naive<POPET, Pythia>，OCP 和预取器始终同时开启
  • 一个离线最优上界 StaticBest: 事后知道整个 workload 的端到端结果，可以在“只开 OCP / 只开预取器 / 两者都开 / 两者都关”之间选最好那个

结果表明：

  • Naive 虽然在全部 workload 上平均还能提升 4.7%
  • 但在 prefetcher-adverse workload 上却平均退化 11.2%
  • StaticBest 比 Naive 平均高 6.5%

结论：问题不在于“这两个机制不能一起存在”，而在于缺乏一个合适的管理策略

已有工作

1. Two Level Perceptron, TLP

TLP 显式考虑 OCP，关键思想是：
如果一个预取会从 off-chip 填到 L1D，这类预取往往不准，所以用 OCP 信息去过滤这类 L1D 预取

但在 lower cache 中不一定成立
一个统计：L1D 的 off-chip prefetch fill 有 50.6% 不准确，而 L2C 上只有 28.1% 不准确

结论：TLP 的前提不适用于 L2 场景，不适合“多个 cache level 上不同 prefetcher”的情形

2. Hierarchical Prefetcher Aggressiveness Control, HPAC

HPAC 属于启发式控制，靠静态阈值比较准确率、带宽等特征来控制预取

问题：阈值是按平均情况调节得到的，不能随 workload/phase 自适应

  • 在 prefetching 友好的 phase ，会偏保守
  • 在 prefetching 不友好的阶段，也可能不够激进

3. Micro-Armed Bandit, MAB

MAB 用 multi-armed bandit 做决策，比固定阈值灵活

问题: 不感知系统状态，更多是根据历史 reward 对“哪个 arm 好”做统计。
这会导致它无法理解“当前为什么应该选这个动作”，尤其不能利用准确率、带宽、污染这类系统信号做出动作

Athena 核心思想

Athena：把“是否开启预取器/OCP、如何调节预取激进度”建模成一个在线强化学习问题

Athena 每隔一个固定 epoch 观察系统状态，选择一个动作，然后根据得到的奖励更新策略。

作者强调：不能把 IPC 变化当成唯一 reward

  • IPC 的变化既可能来自 Athena 的动作，也可能只是 workload 自身 phase 变化引起的。
  • 如果 reward 把这两种因素混在一起，RL 学到的策略就可能被噪声误导

Athena 设计了一个composite reward，把“与动作相关的系统变化”和“主要由 workload 自身变化引起的变化”分开，再做差来近似抽取动作的真实因果影响

Athena 设计

Athena 采用的 RL 算法是 SARSA:

SARSA 是经典的 时序差分（TD）控制算法，名字来自更新时用到的五元组：
$$S_t, A_t, R_{t+1}, S_{t+1}, A_{t+1}$$
更新公式是：
$$
Q(s_t,a_t)\leftarrow Q(s_t,a_t)+\alpha\Big[r_{t+1}+\gamma Q(s_{t+1},a_{t+1})-Q(s_t,a_t)\Big]
$$
特点是：

  • 直接学习 Q 值
  • 下一步用的 $A_{t+1}$ 是按照当前行为策略真正选出来的动作

SARSA 与 Deep RL 的区别:
SARSA 通常是表格型（tabular）:

  • 每个状态-动作对维护一个 $Q(s,a)$
  • 适合状态空间很小的场景

而 Deep RL 通常用神经网络近似函数：

  • 不需要显式存整张 Q 表
  • 可以处理高维状态，如图像、连续特征、大规模状态空间
  • 硬件代价大

二者适用问题规模不同:
SARSA

  • 适合小型、离散状态动作空间
  • 便于教学和理论分析
  • 收敛性质相对清楚

Deep RL

  • 适合复杂环境
  • 可处理高维输入
  • 工程能力强，但训练更复杂、更不稳定

Q-value 存储结构叫 QVStore

  • 不是一个巨大的完整状态表，而是拆成多个 plane
  • 对同一个 state vector 用多个 hash 映射到不同 plane
  • 每个 plane 存一个 partial Q-value
  • 最后把这些 partial Q-value 求和得到总 Q-value

两个好处：

  • 类似 state aliasing/generalization：相似状态会在部分 plane 上共享信息；
  • 每个 plane 很小，访问延迟和功耗都更容易控制

SARSA 的超参数通过离线学习得到：

Hyperparameters Final value
Learning Rate $\alpha$ 0.6
Discount Factor $\gamma$ 0.6
Rxploration Rate $\epsilon$ 0.0
Epoch Length 2K instructions

1. 状态（State）

Athena 把状态定义成一个系统级特征向量。候选特征一开始有 7 个，包括：

  • prefetcher accuracy
  • OCP accuracy
  • bandwidth usage
  • cache pollution
  • prefetch bandwidth share
  • OCP bandwidth share
  • demand bandwidth share

但考虑到状态维度越大，Q-value 存储越贵，作者做了离线 feature selection，最后保留了 4 个特征：

  1. prefetcher accuracy
  2. OCP accuracy
  3. bandwidth usage
  4. prefetch-induced cache pollution

这四个特征其实很合理，正好对应四个核心判断：

  • 预取器是不是准；
  • OCP 是不是准；
  • 系统是否带宽紧；
  • 预取器是不是在污染缓存。

从体系结构直觉看，这四个量已经能覆盖大部分“到底该不该开预取”的关键因素。

2. 动作（Action）

Athena 的动作空间很简洁，只有四种粗粒度协调动作：

  1. 只开 prefetcher
  2. 只开 OCP
  3. 两者都开
  4. 两者都关

只要动作中包含 prefetcher，Athena 还会进一步根据 Q-value 的相对大小来调节prefetch degree

具体做法是：看当前最佳动作的 Q-value 比其余动作平均 Q-value 的差距 ΔQ 大多少？

  • 差距大，说明打开预取对性能很有益，于是把预取 degree 提高
  • 差距小，就更保守

相当于把coordination + throttling合并

这里针对 $\Delta Q$ 的超参数也通过离线学习得到：

Hyperparameters Final value
$\tau$ 0.12

3. 奖励（Reward）

作者指出，很多以前的 RL 预取控制工作直接用 IPC change 当 reward。但 IPC 会随着程序 phase 波动，例如分支预测行为变化、load 指令比例变化等，未必是当前控制动作造成的。于是 Athena 设计了：

$$
R_t = R^{corr}_t - R^{uncorr}_t
$$

其中：

  • $R^{corr}t = \sum{i}{\lambda_i \cdot \Delta M_{i,t}^{corr}}$ 表示和 Athena 动作强相关的指标变化
  • $R^{uncorr}t = \sum{j}{\lambda_j \cdot \Delta M_{j,t}^{uncorr}}$ 表示主要来自 workload 内在行为变化的指标变化

最终，论文通过离线学习选出:

  1. correlated 指标:
Metrics Final Value
Cycles $\lambda_{cycle}$ 1.6
LLC misses $\lambda_{LLC_m}$ 0.0
LLC miss latency $\lambda_{LLC_t}$ 0.0
  1. uncorrelated 指标：
Metrics Final Value
Load instructions $\lambda_{load}$ 0.6
Mispredicted branches $\lambda_{MBr}$ 1.0

避免 reward 被 phase behavior 污染
(这个 composite reward 可以推广到别的控制问题，不只限于 prefetch/OCP 管理)

实验

Setup

Platform: ChampSim

  • 模拟类似 Intel Golden Cove 的核心，包括较大的 ROB、三级 cache、DDR4 主存等
  • 默认单核内存带宽是 3.2 GB/s per core，作者认为这接近一些数据中心 CPU 的每核可分摊带宽

workload: 共 100 个 memory-intensive 单核 trace，来自：

  • SPEC CPU 2006
  • SPEC CPU 2017
  • PARSEC
  • Ligra
  • CVP 商业类 workload

配置：

  • 多种 cache design（CD1–CD4）
  • 多种 L1/L2 预取器
  • 多种 OCP
  • 多种主存带宽
  • 4 核 / 8 核 mix

硬件开销

Athena 每核的额外开销是 3 KB：

Structure Description Size
QVStore planes = 8, rows = 64, columns = 4, entry_size = 8 bits 2 KB
Prefetch Accuracy Tracker 4096-bit Bloom filter with 2 hashes 0.5 KB
Cache Pollution Tracker 4096-bit Bloom filter with 2 hashes 0.5 KB

面积对比：

  • HPAC：0.5 KB
  • MAB：0.1 KB
  • TLP：6.98 KB
  • Athena：3 KB

1. 默认单核配置的结果（CD1：一个 L2 预取器 + OCP）

在默认配置中，Athena 协调 POPET 和 Pythia，整体上分别比：

  • Naive 高 5.7%
  • HPAC 高 7.9%
  • MAB 高 5.0%

在两类 workload 上都表现稳定：

  • 对 prefetcher-adverse，Athena 能识别“Pythia 在损失性能”，转而偏向 POPET
  • 对 prefetcher-friendly，Athena 又能识别“两者全部打开更有利于提高性能”，接近 Naive 的收益

论文还将 Athena 和离线 StaticBest 比，结果是：(基本接近)

  • Athena：1.103
  • StaticBest：1.111

Athena 甚至还能在某些 phase 上超过按 workload 粗粒度选择的 StaticBest，因为 Athena 是phase级动态切换

2. 不同 cache design 的结果

Athena 可以适配多个 cache level 上的多个 prefetcher

  • CD2（OCP + 1 个 L1D prefetcher）：
    • Athena 比 TLP 平均高 8.7%，比 MAB 高 5.2%
    • TLP 在 adverse workload 上能过滤一些 bad prefetch，但在 friendly workload 上会错误遏制有效预取
  • CD3（OCP + 2 个 L2C prefetcher）：
    • Athena 比 Naive/HPAC/MAB 分别高 10.1% / 10.4% / 6.4%
  • CD4（OCP + L1D prefetcher + L2C prefetcher）：
    • Naive 在 adverse workload 上会退化 26.8%
    • TLP 因为无法管理 L2C prefetcher，仍退化 16.7%
    • Athena 平均比 TLP 高 9.9%，比 MAB 高 7.0%

3. 对不同预取器 / 不同 OCP 的泛化能力

在固定 CD1 时：

  • 换 L2 预取器为 Pythia / SPP+PPF / MLOP / SMS，Athena 都优于 prior methods；相对 next-best MAB 的提升分别是 5.0% / 5.4% / 3.6% / 5.0%。
  • 换 OCP 为 POPET / HMP / TTP，Athena 相对 MAB 的提升分别是 5.0% / 4.7% / 8.2%。

4. 对带宽变化的适应能力

论文还专门研究了不同主存带宽。Athena 在 1.6 / 3.2 / 6.4 / 12.8 GB/s 下的 geomean speedup 分别是：

  • 1.0250
  • 1.1224
  • 1.2469
  • 1.3554

作者解释：

  • 在带宽很紧张时，静态组合很难始终保持较好的效果
  • 在带宽很充足时，Naive 组合往往已经能表现较好
  • Athena 能随着带宽条件变化自动更频繁地选择更合适的组合

5. 多核实验

作者还做了 90 个四核 mix 和 90 个八核 mix

四核结果里，Athena 在全部 mix 上比：

  • Naive 高 5.3%
  • HPAC 高 7.7%
  • MAB 高 3.0%

这些收益是在完全沿用单核调出来的超参数下得到的，没有专门为多核再调整参数。说明 Athena 的泛化性不错

6. ablation study

从一个无状态、只用 IPC reward 的 Stateless Athena开始，逐步加入：

  • prefetcher accuracy
  • OCP accuracy
  • bandwidth usage
  • cache pollution
  • uncorrelated reward

结论：

  1. 没有状态信息的 Athena 甚至比 MAB 略差
    • 说明: RL 本身并不自动带来好结果，关键在于状态设计
  2. 加入各个状态特征后性能逐步提升，表明作者选的四个特征都有增量价值
  3. 最后加入 uncorrelated reward 后还能进一步提升
    • 说明：reward 去除混淆 workload phase 的噪声，确实有用。

Limits

1. 本质上还是“离线调参、在线学习”

Athena 的特征选择、reward 权重、超参数都是通过离线 DSE/grid search 得到

说明:

  • 虽然 Athena 在线学习，但设计者其实已经在离线投入了不少训练/调优工作
  • 如果平台、缓存结构、NoC 延迟模型变化更大，这套配置不一定依旧能起作用

2. 部分超参数为 0

exploration rate $\epsilon$ 是 0.0

  • 意味着运行时几乎不做显式探索
    • 要么状态划分和初始化足够好，几乎不需要探索
    • 要么 trace-driven 场景下，探索代价太高，作者更偏向 exploitation
  • 问题：当系统进入没见过的新状态时，不一定依旧能起作用

部分 reward 权重为 0.0? ：$\lambda_{LLC_m}$, $\lambda_{LLC_t}$

3. reward 不是严格的因果推断

composite reward 是严格的因果推断。比如：

  • mispredicted branches 被归为 uncorrelated
  • load instruction 数量也被归为 uncorrelated

在大多数情况下合理，但未必严格

某些动作可能通过改变 memory stall 进而影响分支行为、执行窗口和 load retirement

4. 动作空间较粗糙

Athena 的动作空间只有 “开/关 OCP、开/关 prefetcher、调 prefetch degree”

不能：

  • 选择不同 prefetcher 内部配置
  • 分流不同类型请求
  • 更细粒度控制 OCP 的优先级或发射策略