当前主流处理器一般并非只部署单一预取器，而是在 L1、L2、LLC 甚至互连与内存控制器等多个层级同时配置多类数据预取器，以分别处理顺序流、固定步长、空间局部性、区域访问乃至数据相关访存等不同模式。Intel、AMD、Arm 和 Apple 的公开资料与反向工程研究都表明，现代 CPU 普遍已进入“多预取器并存”的阶段。

然而，多预取器并行工作并不天然带来收益。多个预取器可能争夺 MSHR、fill buffer、cache 容量和内存带宽，导致污染、误预取叠加和核间干扰等问题。
学术界长期将这一问题概括为多预取器管理或协同预取控制问题，核心在于：

  1. 如何决定哪些访问应训练哪些预取器
  2. 哪些预取请求应该真正下发
  3. 预取应进入哪一级缓存
  4. 在资源紧张时如何动态限流

多数据预取器管理的问题

当前多预取器的管理维度：

  1. 空间分层管理，即预取器部署在哪一层：L1D、L2、LLC 还是更远的互连与内存控制器。

    • 不同层级决定了可观测信息、预取距离、反馈时效和污染代价。
    • 综述指出，现代服务器和高性能处理器中的预取器已广泛分布于不同 cache level，其行为与部署层级密切相关

  2. 模式分工管理，即不同预取器擅长识别不同类型的访存模式。

    • AMD 公开的 BIOS/调优文档 就同时暴露了 L1 Stream、L1 Stride、L1 Region、L2 Stream、L2 Up/Down 等多种预取器

  3. 资源仲裁管理，即多个预取器在共享 cache、队列和带宽时如何避免相互拖累

    • Intel 文档披露，L2 streamer 会根据 outstanding requests 数量动态调整预取距离，并在压力较大时只预取到 LLC 而不是 L2

  4. 动态反馈管理，即根据实际收益调整预取深度、激进度或启停状态

    • FDP 的核心思想就是利用运行期反馈动态控制预取器，从而减少不必要的带宽浪费和 cache 污染

多预取器管理策略还需要考虑的问题：

  1. 子预取器的选择问题
  2. 子预取器的触发问题和激进度调节问题
  3. 多个子预取器触发时的处理

不同 cache 层级的多预取器管理要求

对比维度 L1 层多预取器管理 L2 层多预取器管理
主要目标 尽量不影响 demand latency，控制污染和误触发 提高 miss coverage，拉长 prefetch lookahead，隐藏更长内存延迟
典型风格 保守、近端、快速反馈 更激进、远端、强调资源协调
主要风险 L1 容量小，误预取会直接挤掉热点数据并干扰 load/store 路径 占用 MSHR、fill buffer、L2 容量和下级带宽，可能压制 demand miss
更适合的控制变量 启停控制、训练门控、小 degree、短距离 throttling lookahead 深度、请求速率、填充落点、多预取器请求分配
多预取器协同特征 更强调“谁不该工作” 更强调“谁来工作、工作多少、数据落到哪一层”
典型工业体现 AMD 将 L1 Stream / Stride / Region 分开暴露，适合按 workload 裁剪 (AMD Documentation) Intel L2 streamer 可长距离前推，并在压力大时仅送 LLC；Arm L2 侧做 stream/stride 检测 (Intel CDRD)
更贴近的学术管理思路 FDP 式短反馈节流、请求级训练门控 Alecto 式请求分配、系统级协同与资源感知控制 (Home)

L1 层的多预取器管理：核心是“保守、快速、避免伤害前端 demand”

  1. L1 的首要目标是低延迟与低污染

    • L1D 的容量小、替换敏感、且直接服务流水线中的 load/store，因此 L1 侧预取器的管理通常必须更保守
    • L1 层一旦误预取，代价很大。因为它会直接挤掉刚刚被使用、而且很可能马上还要再次访问的热点数据

  2. L1 层更适合短距离、短反馈环的管理

    • L1 级预取器离 demand 最近，反馈最快
    • 一个 L1 预取是否及时、是否有用，通常很快就能观察到。这意味着 L1 层更适合做短周期反馈控制，例如快速节流、快速关闭某一路预取器、或限制每次只预取极少的行数

  3. L1 层更强调“谁别工作”，而不是“谁多工作”

    • L1 层管理往往不是鼓励多个预取器同时大规模发请求，而是要尽快判断：
      • 哪些预取器当前不适合
      • 哪些模式在 L1 过于激进
      • 哪些访问应该绕过某些预取器训练

或许可以解释 I-POP 为何在 L1 表现不佳，I-POP 本身是通过观察一个 phase 内的 PE 指标来训练开关和调节激进度的

  • phase 太短，在 MSHR 观测到的 miss latency 等指标不准确
  • phase 太长，对 L1 的管理就滞后了

L2 层的多预取器管理：核心是“扩展覆盖、控制长距离预取副作用”

  1. L2 层更强调 coverage 和 lookahead

    • L2 的优势是：既比 L1 更大，又比 LLC 更近，更适合承担“中距离到长距离预取”
    • L2 层的多预取器管理更偏向让多个模式识别器并行工作，然后再通过资源与策略来筛选

  2. L2 层更重视共享资源协调

    • L2 预取器不会直接干扰流水线，但会更明显地消耗 MSHR、fill buffer、下级 cache 带宽和内存带宽
    • 因此，L2 层管理的重点通常为：预取请求数量是否过多、是否过远、是否挤占 demand miss 的服务能力

  3. L2 层更适合“多个预取器并行 + 后端仲裁”

    • AMD 的 L2 Stream 和 L2 Up/Down 预取器同时存在，Intel 的 L2 streamer / spatial 与更远层 LLC prefetch/XPT 也呈协同关系，都说明 L2 更容易成为多个预取器汇聚、共享后端资源的层级
    • L2 更常见的是“让多个预取器都试着预取，但在后端做仲裁和限流”
    • Alecto 这类 request allocation 框架，本质上就是在回答：既然多个预取器都可能对同一个 memory access 感兴趣，那应该把这个 demand request 分配给谁训练、谁来发预取、谁不该占用表项和带宽。
    • 后端仲裁的问题在 L2 层尤其突出，因为 L2 是各种 temporal/spatial/streaming prefetcher 汇合的地方

工业界多数据预取器管理策略

Intel：分层并存、动态调节、目标层级可变

Intel 优化手册说明，Intel 核心长期同时具有多类硬件预取机制；以 Sandy Bridge 一类公开描述为代表，L2 streamer 具有两个非常关键的行为：

  1. 会根据 outstanding requests 的数量动态调整预取前推距离
  2. 在请求较多时会只预取到 LLC 而不是 L2，以减少对 L2 的替换污染

在 3rd Gen Xeon Scalable 的官方 HPC 调优资料中，Intel 公开了 XPT Prefetch 与 UPI Prefetch

  • XPT 是一种面向 LLC miss 路径的推测性机制: 会在请求送往 LLC 时推测性地向 memory controller 发起副本读取
  • UPI prefetch 则涉及远端内存路径: 会在 UPI receive path 提前触发 DDR 读取
  • 官方建议 HPC 负载通常启用 XPT/UPI prefetch

4th Gen Xeon 的官方 LLC Prefetch 文档又进一步指出，LLC prefetch 是在既有预取器之上增加的一层机制，能够额外把数据送入 LLC；同时文档也强调其收益与工作负载相关，并非越激进越好

AMD：多模块并行识别，默认全开，依赖 BIOS 选择调优

AMD uProf 文档与 EPYC 调优资料表明，AMD 平台通常同时具备 L1 Stream HW Prefetcher、L1 Stride Prefetcher、L1 Region Prefetcher、L2 Stream HW Prefetcher、L2 Up/Down Prefetcher 等多个可分别启用或关闭的预取器。(默认多为 Enabled)

AMD 官方工作负载调优指南指出：
大多数工作负载会从 L1/L2 stream prefetchers 中获益，但某些随机性较高的负载在关闭一个或两个预取器后性能更好

Title Year Inc. Number
Apparatus and method for managing multiple prefetchers 2019 AMD US10430342B2
Prefetcher arbitration based on prefetch accuracy metrics 2023 AMD US11593275B2

Apparatus and method for managing multiple prefetchers (AMD, US10430342B2, 2019)

  • 现代处理器同时运行多个预取器（stride, stream, spatial 等），需要统一管理
  • 设计了多预取器管理装置，包括优先级分配、冲突检测和带宽分配机制

Prefetcher arbitration based on prefetch accuracy metrics (AMD, US11593275B2, 2023)

  • 多个预取器同时产生候选地址需要仲裁
  • 基于每个预取器的历史准确率进行仲裁，优先执行高准确率预取器的请求

Arm：公开实现较少，但可确认采用 L1/L2 多层预取与模式分工

Arm 的 load/store hardware prefetcher 文档指出

  • load/store 单元包含一个硬件预取器，能够对 L1D cache 和 L2 cache 产生预取
  • L2 中存在独立机制检测 load-store streams，并在 4KB 页内做 stride 检测，所有这类预取都会分配进入 L2

2026 年的新研究表明，Arm 生态中部分 CPU 已不再局限于传统 stride/spatial，而可能存在 data memory-dependent prefetcher 之类更复杂的机制

Title Year Inc. Number
Adaptive hardware prefetcher control 2015 ARM US9043573B2
Adaptive multi-prefetcher management using performance feedback 2022 ARM US11321235B2

Adaptive hardware prefetcher control (ARM, US9043573B2, 2015)

  • ARM 平台上不同应用对预取的需求差异巨大
  • 核心 insight：利用硬件性能计数器的反馈实现自适应控制，可动态启用/禁用/调节多个预取器
  • 设计了基于 PMU 反馈的自适应预取控制框架

Adaptive multi-prefetcher management using performance feedback (ARM, US11321235B2, 2022)

  • 多预取器系统中各预取器的贡献随工作负载动态变化
  • 基于 IPC、miss rate、带宽等运行时反馈动态调整各预取器的激活状态和激进程度

Apple：公开资料最少，但反向工程显示其已具备多流 stride 与 data-dependent 预取

Apple 的多预取器管理资料主要来源于反向工程和安全研究

  • ASPLOS 2025 的 ShadowLoad 对 Apple M1/M2 P-core stride prefetcher 进行了逆向
    • 指出其 stride prefetching 逻辑不基于 load PC，而与完整 load target address 相关
    • 并显示该预取器可以同时跟踪多条 stride 流
  • USENIX Security 2024 的 GoFetch 工作系统性研究了 Apple CPU 上的 Data Memory-Dependent Prefetcher (DMP)，指出该机制会根据先前访问得到的数据内容来推测后续预取目标
  • 2026 年的后续工作明确把 DMP 定义为一种不仅依赖地址访问轨迹、也依赖已取回数据内容的预取器类型，并专门以 Apple M-series DMP 为主要分析对象

上述工作表明 Apple 的预取体系至少包含：

  • 传统的多流 stride 预取
  • 更高级的 data-dependent 预取

学术界多预取器管理

  1. 反馈调节：激进度和插入策略如何动态变化
    最经典的代表是 FDP (Feedback Directed Prefetching), 该工作指出:

    • 预取器不应固定激进度运行，而应根据 accuracy、timeliness、pollution 等反馈动态调节 degree 和 cache insertion policy
    • 核心思想与商用 CPU 中“根据 outstanding requests 调整远近和落点”的逻辑一致
    • I-POP 也属于此类

  2. 资源干扰：关注多核、多预取器造成的共享资源干扰
    Coordinated Control of Multiple Prefetchers in Multi-Core Systems 明确指出: 多核环境下的多个预取器会相互干扰，单独优化每个核的本地预取器并不足够，必须从系统级协调其激进度，限制严重干扰情形

  3. 请求选择：关注不同需求访问应由哪些预取器接管
    Alecto 则进一步把问题推进到“请求级选择”

    • 核心思想是先对每个 demand request 做选择，再把该请求路由给合适的预取器进行训练和预取
    • Alecto 明确声称其目标是协调 accuracy、coverage、timeliness 以及预取器表项利用率

学术界的大多数经典工作主要落在 L2 或更低层级（含 LLC/private L2），而明确、直接面向 L1D 多预取器管理的工作明显更少。这和 L1 的实现约束有关：L1D 预取器要贴着 pipeline 工作，时序更紧、面积更敏感、误预取代价也更直接；相对地，L2 更适合放较复杂的 stream/stride/ensemble 控制逻辑。ISCA 2020 的 IPCP 就明确总结过，L1-D 预取虽然有“能看到未过滤访问模式、能把块带到所有 cache level”等优势，但同时面临更严苛的延迟与硬件开销约束

针对 L1 的工作

Title Year From URL
Division of Labor: A More Effective Approach to Prefetching 2018 ISCA https://doi.org/10.1109/ISCA.2018.00018
Bouquet of Instruction Pointers: Instruction Pointer Classifier-based Spatial Hardware Prefetching 2020 ISCA https://dl.acm.org/doi/10.1109/ISCA45697.2020.00021
Integrating Prefetcher Selection with Dynamic Request Allocation Improves Prefetching Efficiency 2025 HPCA https://doi.org/10.1109/HPCA61900.2025.00026

TPC/DOL: 面向 L1（2018 ISCA）Division of Labor: A More Effective Approach to Prefetching

  1. 单体预取器面临 scope 与 accuracy 的内在权衡：扩大覆盖范围必然降低精度
  2. 提出”分工”思想：用多个专注简单模式的子组件（T2 strided + P1 pointer + C1 spatial locality）组成复合预取器 TPC
  3. 静态优先级主要专注于 T2 + P1 + C1 这三种预取器

IPCP: 与 L1 强相关、但不仅仅是“多预取器管理”（ISCA 2020）

（Intel 校企合作）

属于根据访存模式分类进行管理的策略

  • 面向 L1 DCache
  • 其中关于多预取器管理部分，根据 IP 分类确定访存模式，根据触发的不同访存模式对应的子预取器置信度来选择不同的预取器
    （关于 GS 的空间预取器，和基于 IP 分类选择的预取器之间是静态优先级管理，GS 更像被拉来凑数的）
  • 子预取器激进度调节：根据每个子预取器的 issued/useful 计数器决定
    • accuracy > 0.75，逐渐提高 degree 直到 max degree
    • accuracy < 0.40，逐步降到 degree=1
  • 当多个预取器被触发时：采用静态优先级选择一个预取器（通过 DSE 决定优先级）
    （回答了子预取器的管理和子预取器的选择两个问题）

Alecto: 实验面向 L1（2025 HPCA）

（Intel 校企合作）

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

针对 L2 / private L2 / LLC 的工作

L2 级别不太好进行输入选择，因为输入选择目前一般通过 PC 识别区分不同的访存模式，但 L2 看不到完整的 PC 请求流，识别访存模式比较困难，因此当前针对 L2 的多预取器管理策略一般是输入全部接到子预取器，只在发出预取请求时决定启用哪些子预取器

Title Year From URL
Sandbox Prefetching: Safe Run-Time Evaluation of Aggressive Prefetchers 2014 HPCA https://doi.org/10.1109/HPCA.2014.6835971
ReSemble: Reinforced Ensemble Framework for Data Prefetching 2022 SC https://doi.org/10.1109/SC41404.2022.00086
Micro-Armed Bandit: Lightweight & Reusable Reinforcement Learning for Microarchitecture Decision-Making 2023 MICRO https://doi.org/10.1145/3613424.3623780
RL-CoPref: a Reinforcement Learning-based Coordinated Prefetching Controller for Multiple Prefetchers 2024 Journal of Supercomputing https://doi.org/10.1007/s11227-024-05938-9
I-POP: Ignite Positive Prefetchers 2026 HPCA https://doi.org/10.1109/HPCA68181.2026.11408454

Sandbox Prefetching: Safe Run-Time Evaluation of Aggressive Prefetchers (HPCA 2014)

（Intel 校企合作）

  • SBP 提出用 Bloom filter 作为”沙箱”，模拟评估多个候选 offset prefetcher 的准确率，而不实际发出预取请求，从而避免污染 cache 和浪费带宽
  • 准确率达标的候选 prefetcher 才被激活，发出真实预取；
  • 尽管原文只面向多个 offset prefetcher 之间的管理，但其核心思想是模拟评估各个子预取器的准确率，以模拟的准确率作为子预取器管理的指标
    1. 模拟的 score (和 accuracy 相关)越高，该预取器允许的 prefetch 请求数越多
    2. 总的 prefetch degree 的调节通过带宽反馈

ReSemble: Reinforced Ensemble Framework for Data

（Intel 校企合作）

  • 单个预取器只擅长特定访存模式，面对混合模式的应用表现不佳
  • 已有的集成预取方法（分类法、SBP）存在离线训练不适应在线变化、response lag 等问题
  • 提出用 Q-learning 训练一个集成控制器（MLP），从多个预取器的建议中动态选择最佳预取地址，通过 hash and norm 解决地址空间爆炸、lazy sampling 解决反馈延迟问题
  • 采用的是 $\epsilon$-greedy 算法（随机探索）

Bandit（Micro-Armed Bandit / 2023-2024）

  • 发现微架构决策问题中动作空间具有时间同质性（temporal homogeneity）——在较长时间窗口内，最优动作基本不变
  • 基于这一性质，用最简单的 RL 形式——Multi-Armed Bandit (MAB) 替代复杂的 MDP-RL，大幅降低复杂度和存储开销
  • 采用 Discounted Upper Confidence Bound (DUCB) 算法

RL-CoPref (Yang et al., Journal of Supercomputing 2024)

  • 背景：多个预取器各擅长不同模式，混合应用中静态组合效果不稳。
  • 核心 insight：用 reinforcement learning 同时调节 prefetcher activation 和 prefetch degree，并把 bandwidth usage 纳入 reward。
  • 设计：以 PC、address、PC+delta 等特征构造 state，action 映射到多个 underlying prefetcher 的开关和 degree。

I-POP (HPCA 2026)

(Alibaba)

根据观测指标反馈调节的策略

  • 没有回答子预取器如何选择的问题
  • 面向 L2 Cache
  • 根据各个子预取器的观测指标计算一个 PE 值决定子预取器的开关与否
  • 当多个子预取器被触发时：相同请求地址的预取请求被合并