当前主流处理器一般并非只部署单一预取器，而是在 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 中获益，但某些随机性较高的负载在关闭一个或两个预取器后性能更好

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 之类更复杂的机制

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 的工作

主要面向跨页预取管理的：DRIPPER / CROSS-page L1D prefetch 管理（HPCA 2025）

研究的是L1D prefetcher 的 page-cross 管理，原因是 first-level caches 能直接接触虚拟地址与 TLB，而 lower-level caches 通常工作在物理地址空间。它讨论的不是传统意义上的“多 L2 子预取器仲裁”，而是 L1D 预取器在是否允许跨页预取上的动态决策与控制，本质上属于 L1 级预取管理。

与 L1 强相关、但不属于“多预取器管理”主线的：IPCP（ISCA 2020）

属于根据访存模式分类进行管理的策略（Intel 校企合作）

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

针对 L2 / private L2 / LLC 的工作

Title Year From URL
Coordinated Control of Multiple Prefetchers in Multi-Core Systems 2009 MICRO https://doi.org/10.1109/MICRO.2009.12
Prefetch-Aware Shared-Resource Management for Multi-Core Systems 2011 ISCA https://doi.org/10.1145/2000064.2000088
Feedback Directed Prefetching: Improving the Performance and Bandwidth-Efficiency of Hardware Prefetchers 2007 HPCA https://doi.org/10.1109/HPCA.2007.346185
Techniques for Bandwidth-Efficient Prefetching of Linked Data Structures in Hybrid Prefetching Systems 2009 HPCA https://doi.org/10.1109/HPCA.2009.4798229
Combining Prefetch Control and Cache Partitioning to Improve Multicore Performance 2019 IPDPS https://doi.org/10.1109/IPDPS.2019.00037
Near-Side Prefetch Throttling: Adaptive Prefetching for High-Performance Many-Core Processors 2018 PACT https://doi.org/10.1145/3243176.3243189

FDP (HPCA 2007)

FDP 建模的 stream prefetcher 以及训练、monitor 和 request 状态都是围绕 L2 miss 展开的

Coordinated Control of Multiple Prefetchers in Multi-Core Systems (MICRO 2009)

这篇论文使用的 locality、memory intensity 指标是基于 L2 cache miss/hit 来定义的

Near-Side Prefetch Throttling (PACT 2018)

这篇论文 NST 讨论的是L2 预取器节流

Bandit（Micro-Armed Bandit / 2023-2024）

Bandit 把多臂 bandit 用来 orchestrate “non-RL level-2 (L2) data prefetchers”，也就是 next-line、stride 和 stream 这些 L2 数据预取器

µMama (MICRO 2025)：private L2 上的多核扩展

µMama 的贡献是把 RL 预取控制从单核 Bandit 推到多核场景

I-POP (HPCA 2026)

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

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

跨层 / 不严格绑定单一层级的工作

Alecto (HPCA 2025)：层级无关的统一框架

  • Alecto 的核心问题是 demand request allocation，也就是每个 demand request 先判断适合哪些 prefetcher，再把请求路由过去
  • 论文明确说它既考虑“temporal prefetcher and other non-temporal prefetchers are located at the same cache level”的情况，也考虑“they are located at different cache levels”的情况
  • Alecto 本质上是一个prefetcher selection framework，既能用于同层多个预取器，也能处理跨层关系
工作 主要层级 归类理由
FDP (HPCA 2007) L2 baseline stream prefetcher 将块带到 last-level cache，而其 baseline 中 LLC 就是 L2；训练和触发基于 L2 miss。
Coordinated Control of Multiple Prefetchers (MICRO 2009) L2 / shared L2 系统配置围绕 shared unified L2、L2 MSHR、L2 miss/hit 展开；属于多核下的 L2 预取器协调控制。
Near-Side Prefetch Throttling (PACT 2018) L2 开销建模用 L2 MSHR 和 L2 cache block；实验上 baseline 保留 L1 预取器，主要控制一个或多个 L2 prefetchers。(heirman.net)
Bandit / Micro-Armed Bandit private L2 明确说明 orchestrate non-RL L2 data prefetchers；控制对象是 private L2 cache 中的 prefetcher ensemble。(iacomaweb.web.engr.illinois.edu)
µMama (MICRO 2025) private L2，多核扩展 在多核下协调多个 Bandit agents，而这些 agents 作用于 private L2 caches。(iacoma.cs.uiuc.edu)
Alecto (HPCA 2025) 跨层 / 层级无关 论文同时考虑 same cache level 和 different cache levels 两种场景，属于统一选择框架。
DRIPPER / CROSS-page L1D prefetch 管理 (HPCA 2025) L1D 论文直接声明 target 是 L1D prefetchers，而不是 lower-level cache prefetchers。