MOKA (2025 HPCA): To Cross, or Not to Cross Pages for Prefetching?

To Cross, or Not to Cross Pages for Prefetching 深度分析报告

执行摘要

这篇论文研究的问题是：L1D 预取器究竟应不应该跨页预取

首先这不是一个适合用静态策略回答的问题:

• 对同一组工作负载，始终允许跨页的 Permit PGC 有时会显著增益，有时却会因为投机页表遍历、TLB 污染和缓存污染而明显伤害性能
• 统计发现，现有 L1D 预取器发出的 page-cross 预取中，大约只有一半是有用的，这从根本上说明“跨页本身”不是答案，“何时跨页”才是需要关注的点

基于这个观察，论文提出 MOKA 框架，并在其上实现 DRIPPER 过滤器，让底层预取器只在“足够可信且符合系统状态”时才跨页。对状态最强的基线预取器 Berti，DRIPPER 在 218 个 seen 工作负载上相对 Discard PGC 提升 1.7%，相对 Permit PGC 提升 2.5%；在 178 个 unseen 工作负载上分别提升 1.2% 与 2.1%；在 300 个 8 核混合负载上，相对这两个基线分别提升 2.0% 与 3.3%。更重要的是，它几乎保留了 Permit PGC 的覆盖率增益，却把准确率从负收益扭转成正收益。citeturn12view0turn15view0turn9view0

书目信息与研究定位

条目	信息
题目	To Cross, or Not to Cross Pages for Prefetching?
作者	entity[“people”,”Georgios Vavouliotis”,”computer architect”]；entity[“people”,”Marti Torrents”,”computer architect”]；entity[“people”,”Boris Grot”,”computer architect”]；entity[“people”,”Kleovoulos Kalaitzidis”,”computer architect”]；entity[“people”,”Leeor Peled”,”computer architect”]；entity[“people”,”Marc Casas”,”computer architect”]
作者机构	entity[“organization”,”Huawei Zurich Research Center”,”research lab zurich”]；entity[“organization”,”Huawei Tel-Aviv Research Center”,”research lab tel aviv”]；entity[“organization”,”Barcelona Supercomputing Center”,”hpc center barcelona”]；entity[“organization”,”Universitat Politècnica de Catalunya”,”technical university barcelona”]；entity[“organization”,”University of Edinburgh”,”edinburgh university”]
发表 venue	entity[“organization”,”IEEE International Symposium on High-Performance Computer Architecture”,”computer architecture conf”] 2025
年份	2025
页码	188–203
DOI	10.1109/HPCA61900.2025.00025
你上传的论文 PDF	fileciteturn0file0
公开全文	可通过作者/实验室公开 PDF 页面访问
公开补充材料	作者主页条目列出了 PDF 与 Slides；未见正式 supplementary PDF 或 artifact 页面
公开代码/仓库	本次检索未定位到该论文专用公开代码仓库；作者主页条目也未直接列出代码链接

来源说明：书目信息、页码、DOI 与公开入口来自论文公开 PDF、研究门户与作者主页条目。citeturn1search1turn0search0turn13view0

从研究定位看，这篇论文不是在与 BOP、IPCP、Berti 这类 “如何更好地产生预取地址” 的工作做正面对抗，而是在它们之上加了一层 “什么时候允许跨页” 的控制层。它也不是简单照搬既有 prefetch filter，而是试图把 page-cross 这个特有决策，与程序局部模式、TLB 压力、执行阶段变化统一在一个框架里。因此，它的真正创新点是：把 page-cross 视为独立于预取算法本体的可学习控制问题。citeturn12view0turn10view1turn7view2

按我建议的优先阅读顺序，首要来源是原论文本身；其次是作者主页上的 PDF 和 slides；然后是论文明确对照的几个关键前作：BOP、IPCP、Berti、PPF、Page Size Aware Cache Prefetching，以及同一作者脉络中的 Exploiting Page Table Locality for Agile TLB Prefetching 与 Morrigan。这些工作共同构成了本文的问题背景、方法灵感与对比基线。citeturn16view0turn18search3turn18search5turn17search22turn17search11turn17search4

背景、问题与文献脉络

论文的背景判断非常准确。L1D 预取器通常工作在 VIPT 环境下，能够看到虚拟地址；在这个空间里，某些模式比物理地址空间更容易识别，因此从架构上看，L1D 预取器确实“有能力”跨页。但能力不等于应该一直做：一旦目标页翻译不在 TLB 中，预取就可能触发投机 page walk；如果这个跨页预取最终没有命中，就可能平白多出最多 5 次无用内存访问，并污染 TLB 和 cache。与之相对，如果跨页恰好准确，它又可能同时改善预取时机、L1D 命中与 TLB 命中。作者把这件事概括为 high-risk, high-gain，这是全文最重要的物理直觉。citeturn12view0

论文没有把研究问题写成形式化假设，但从引言和动机部分可以清晰还原出三类核心问题。第一，静态策略是否足够好：总是允许跨页，或永不允许跨页，哪个更优？第二，现有 L1D 预取器跨页时到底有多准确？第三，如果静态策略不好、原始预取器跨页准确率又不够，是否可以设计一个轻量的在线机制，动态决定某个跨页请求该不该发？整篇论文的结构基本就是沿着这三个问题展开：先做 characterization，再做 framework，再做 prototype 和 validation。citeturn12view0turn10view0

在文献脉络上，这篇论文的对照对象大致分成四类。第一类是 BOP、IPCP、Berti 这类 L1D spatial prefetcher，它们强在模式发现，但通常默认不跨页。第二类是 PPF 这类 prefetch filtering，它们说明“过滤不准的预取”是值得做的，但原始设计主要面向 L2/物理地址空间，并不针对 page-cross。第三类是 Page Size Aware Cache Prefetching，它利用 2MB 大页来安全跨越 4KB 物理页边界，但它更多是在利用页大小信息，而不是对 page-cross usefulness 做动态判定。第四类是作者此前关于 TLB / 页表局部性预取 的工作，它们说明作者团队长期关注虚拟内存与预取耦合带来的机会，因此这篇论文并不是凭空出现，而是这一研究线索的自然延展。citeturn7view2turn16view0turn18search3turn18search5

graph LR
    BOP["BOP 2016<br/>best-offset"] --> PPF["PPF 2019<br/>prefetch filtering"]
    BOP --> IPCP["IPCP 2020<br/>IP-based spatial prefetch"]
    IPCP --> Berti["Berti 2022<br/>local-delta prefetcher"]
    PPF --> Cross["Cross Pages 2025<br/>page-cross filter"]
    Agile["Agile TLB 2021"] --> Cross
    Morrigan["Morrigan 2021"] --> Cross
    PageAware["Page Size Aware 2022"] --> Cross
    Berti --> Cross

这张关系图概括了本文与前作的关系：它并不替换基线预取器，而是吸收 filtering、virtual-memory-aware 与 page-size-aware 三条研究线的经验，在 L1D page-cross 这个更细的控制点上汇合。citeturn16view0turn18search3turn18search5turn17search22turn17search11

方法详解与公式批注

MOKA 的设计可以概括成一句话：对“某个 page-cross prefetch 是否值得发”做一次轻量在线二分类。它的硬件组成包括：针对程序特征的多个 weight tables、针对系统特征的 saturating counters、捕捉“误杀”的 vUB、记录已发跨页预取并支持正/负训练的 pUB，以及一个会随 epoch 调整的 activation threshold。作者特别强调，这一层只介入 跨页请求，不会干扰普通 in-page 预取，因此具有“legacy preserving”的性质。citeturn10view1turn11view0

flowchart LR
    A["L1D 访问"] --> B["底层 L1D 预取器"]
    B --> C{"是否跨 4KB 页边界"}
    C -- 否 --> D["按原预取器路径发起普通预取"]
    C -- 是 --> E["MOKA / DRIPPER 过滤器"]
    E --> F["程序特征哈希查表"]
    E --> G["系统特征条件判断"]
    F --> H["累积权重 w_final"]
    G --> H
    H --> I{"w_final > T_a ?"}
    I -- 否 --> J["丢弃 page-cross 请求"]
    I -- 是 --> K["TLB 查询 / 可触发 speculative page walk"]
    K --> L["发出 page-cross prefetch"]
    L --> M["vUB / pUB / PCB 在线训练"]

这个流程图是根据论文 Figure 5–8 与 Section III 整理出来的抽象版本。关键思想是：先用程序特征估计“模式上值不值得跨”，再用系统特征估计“此时此刻是否适合跨”，最后再由自适应阈值控制 aggressiveness。citeturn10view1turn11view0turn8view0

下面把文中最关键的“公式/规则”逐条拆开评论：

表达式或规则	逐项解释	技术评价
w_final = Σ(程序特征权重) + Σ(激活的系统特征权重)	程序特征表示“这个 PC/VA/delta 模式过去跨页是否常有用”；系统特征表示“当前 sTLB/L1D/LLC 压力下，跨页是否更值钱或更危险”。	这不是重数学推导，而是工程上很合理的 additive scoring。优点是低成本、可解释；缺点是表达能力有限，无法显式建模高阶交互。
若 w_final > T_a，则发出 page-cross prefetch	T_a 是激活阈值，相当于 aggressiveness knob。	核心不在阈值比较本身，而在阈值会随阶段变化；没有这个机制，过滤器对不同工作负载会很难统一。
vUB 命中 demand miss => 正训练	表示过滤器先前错误地丢弃了一个本可有用的 page-cross 预取，即 false negative。	这是很聪明的一点：它不仅学习“什么已发出去后有用”，还学习“什么被误杀了”。
pUB 命中 useful block => 正训练；pUB 命中 useless eviction => 负训练	已发跨页预取若产生命中，则增权；若到驱逐都没产生命中，则减权。	这是把 usefulness 直接绑定到 cache-lifetime 命中语义上，定义清楚、实现自然，但仍是短视目标，不含更远端带宽/能耗成本。
weighted_speedup = normalize(Σ IPC_multicore / IPC_isolation)	多核实验采用经典 normalized weighted speedup。	选择合理，但论文没有对 mix 采样方差给出置信区间。

来源说明：上述公式化整理对应论文 Section III 和 Section IV 中对预测、训练、阈值调整与多核度量的文字定义。citeturn11view0turn8view0turn8view2

特征设计是这篇论文的方法学核心。MOKA 总共准备了 55 个程序特征 和 6 个系统特征；作者先在 218 个 seen 工作负载上离线测试 60 个单特征过滤器，按 geomean IPC speedup 排序，再做逐步加入，只在新增特征能把 geomean IPC 再提高超过 0.3% 时才保留。最终，Berti 选中 Delta + sTLB MPKI + sTLB Miss Rate，BOP/IPCP 则选中 PC⊕Delta + sTLB MPKI + sTLB Miss Rate。这说明作者最终找到的最强组合，很大程度上围绕两件事：跨页步长本身，以及 sTLB 压力的双向状态。citeturn8view0turn8view1

这个方法有两个很强的优点。第一，所选系统特征都与论文的物理机制解释高度一致：sTLB MPKI 低时，意味着翻译更可能直接命中，跨页更安全；sTLB Miss Rate 高时，说明地址翻译压力大，跨页反而可能通过额外 page walk 提前把翻译拉进来。第二，作者有意识地坚持“prefetcher-independent”特征，不去绑定某一基线预取器的私有 metadata，因此 DRIPPER 才能在三个预取器上复用。citeturn8view1turn10view1

但方法细节也有重要缺口。论文给出了存储开销：总计 1.44KB/core，其中程序特征表 0.625KB、系统特征权重约 0.00125KB、vUB 0.024KB、pUB 0.768KB。由此可以推得，pUB 一项就占总开销约 53.3%，程序特征表约占 43.4%，说明未来若想进一步压缩面积，优先优化 pUB 是最有价值的。与此同时，论文并没有公开 T1/T2/TL1i/tm/th 的具体数值，也未明确给出 epoch 长度，这使别人能“仿出结构”，但很难“精确复现控制面”。这是复现性上的实质损失。citeturn8view0turn8view1turn8view2

实验设置、结果与稳健性

实验方法本身是比较规范的。作者基于 ChampSim，模拟 1 核和 8 核 OOO 处理器、三级缓存、5 级 radix-tree page table、x86 page-table walker、split PSCs，并主要关注 4KB 页；扩展实验再加入 2MB 大页。工作负载覆盖 SPEC CPU 2006/2017、GAP、Ligra、PARSEC、Geekbench 以及由 entity[“company”,”Qualcomm”,”chip company”] 提供的工业整数/浮点 traces；主实验只取 LLC MPKI ≥ 1 的 memory-intensive 负载，共 396 个，其中 218 个用于设计，178 个作为 unseen 评估。单核 warm-up 与 measurement 区间也明确给出。总体来看，工作负载覆盖面与体系结构配置透明度是足够强的。citeturn8view2turn9view0

最核心的量化结果可以整理成下表：

结果维度	关键数字	我对结果的解读
Berti 单核 seen，相对 Discard PGC	+1.7%	动态过滤确实优于“永不跨页”
Berti 单核 seen，相对 Permit PGC	+2.5%	最大价值来自过滤掉有害的跨页请求
Berti 单核 unseen，相对 Discard PGC	+1.2%	有一定泛化，不是纯 seen overfit
Berti 单核 unseen，相对 Permit PGC	+2.1%	unseen 上仍明显优于总是跨页
全部工作负载，相对 Discard PGC	+0.4%	非 memory-intensive 负载把几何平均稀释了
全部工作负载，Permit PGC 相对 Discard PGC	-0.6%	说明“总是跨页”在总体上不成立
覆盖率变化，相对 Discard PGC	Permit +4.2%；DRIPPER +4.1%	过滤后几乎没丢覆盖率
准确率变化，相对 Discard PGC	Permit -2.6%；DRIPPER +1.2%	真正的收益来自准确率翻转
MPKI 平均绝对变化，相对 Discard PGC	dTLB -0.6；sTLB -0.1；L1D -2.1；LLC -0.2	机制链条是自洽的：更少坏跨页 → 更少污染 → 更低 MPKI
大页场景	DRIPPER 相对 Discard +1.3%；相对 Permit +2.2%；相对 filter@2MB +0.5%	4KB 粒度过滤比按 2MB 边界过滤更有效
多核 300 个 8-core mixes	相对 Discard +2.0%；相对 Permit +3.3%	多核下跨页错误的共享资源代价更大，因此过滤更值钱
组成特征消融	DRIPPER 比仅系统特征版高 0.9%	程序特征不可或缺
2MB 边界统计	>99% 的跨页预取并不跨 2MB 边界	解释了为什么 filter@2MB 会输给常规 DRIPPER

来源说明：上表来自正文 Figure 10–19、Table V 以及相关文字解释。citeturn15view0turn6view4turn6view5turn7view1turn9view0

结果链条在逻辑上是非常自洽的。论文并不是只给出最终 IPC，而是从 useful/useless page-cross 分布、coverage/accuracy、dTLB/sTLB/L1D/LLC MPKI 一层层解释为什么 DRIPPER 有效。特别值得肯定的是，作者证明 DRIPPER 与 Permit PGC 在 useful page-cross 数量上几乎相同，但 useless page-cross 大幅减少，因此 coverage 保住了，而 accuracy 被拉高。对于体系结构论文来说，这类“机制—中间指标—最终性能”的闭环，比单纯给一个 geomean 更有说服力。citeturn6view4turn6view5turn15view0

稳健性方面，论文至少做了五层校验。其一，跨预取器：Berti、BOP、IPCP 三者都能获益。其二，跨工作负载集合：seen 与 unseen 趋势一致。其三，跨页大小：4KB 与 2MB 共存时仍然有效。其四，跨缓存层配置：即使加入不同 L2C 预取器，DRIPPER 仍保持相对优势。其五，跨核数场景：8 核 mixes 仍然有正收益。这种 breadth 是本文实验一大强项。citeturn15view0turn7view1turn9view0

不过，论文几乎没有做统计推断意义上的分析。没有 p 值，没有置信区间，也没有对 300 个多核 mix 或 396 个工作负载做 bootstrap。从 systems 社区习惯看，这不算罕见；但如果作者想把“对 unseen 也泛化”说得更强，更好的做法应当是报告 workload-level 或 mix-level 的 bootstrap CI、pairwise sign test 或至少给出分布摘要统计，而不仅仅是 geomean 和散点图。当前版本里，effect size 很清楚，但统计不确定性几乎没有被量化。citeturn8view2turn15view0turn9view0

还有一个值得指出的再分析细节：正文 Figure 10 与 Table V 明确给出，Berti+DRIPPER 在 seen 上相对 Discard PGC 为 +1.7%，而 Permit PGC 相对 Discard PGC 为 -0.8%，因此 DRIPPER 相对 Permit 的提升应为 2.5 个百分点；unseen 上同理为 2.1 个百分点。这与正文后文是一致的，但如果只看摘要，比较对象顺序会让人有一点阅读歧义。严格说，这不影响实证结论，但属于写作层面可以改进的地方。citeturn12view0turn15view0turn9view0

复现性、局限与批判评估

复现项	状态	评语
论文全文	已公开	可直接获取
Slides	已公开	便于理解，但不替代 artifact
模拟器名称	已说明	使用 ChampSim
微结构配置	较完整	核心、缓存、TLB、DRAM 参数都有
工作负载来源	部分完整	公共套件清楚；工业 traces 的公开性有限
选中特征集合	已说明	Table II 给出最终组合
特征搜索流程	已说明	离线筛选 + 0.3% geomean 增益门槛
存储开销	已说明	1.44KB/core，结构级别足够清楚
精确阈值/epoch 长度	未公开	这是最关键的缺口之一
原始逐 workload 数据	未公开	无 CSV/日志，难做二次统计
代码 / artifact	未定位到	作者主页条目只列 PDF 与 slides
能耗 / 带宽 / 时序实现	不足	有定性讨论，但缺少完整定量评估

来源说明：这些判断基于论文方法与作者主页条目。citeturn8view0turn8view1turn8view2turn13view0

这篇论文最值得肯定的四个优点很清楚。第一，问题定义一针见血：它抓住了学术界“默认不跨页”和工业界“其实会跨页”之间的断层。第二，方案设计有很强的正交性：DRIPPER 不需要替换底层预取器，只需在 page-cross 请求入口做决策，因此更像一个可插拔控制层。第三，实验因果链扎实：coverage、accuracy、MPKI、性能之间的因果叙事一致。第四，开销克制：1.44KB/core 在体系结构论文里属于相对温和的额外状态。citeturn12view0turn11view0turn8view1turn15view0

它的主要弱点也同样明确。第一，主实验只聚焦 memory-intensive 负载，这很合理，但会天然抬高该问题的重要性与平均收益；作者后来用全 workload geomean 补了这一点，但 non-intensive 部分仍然没有提供同等粒度的图表。第二，设计过程使用 218 个 seen 负载进行 feature selection，虽然 unseen 结果在一定程度上缓解了 overfitting 担忧，但它并不能完全替代对阈值敏感度、跨平台迁移和 cross-validation 的更系统分析。第三，工程落地证据不足：没有时钟频率影响、关键路径长度、能耗/带宽账本、甚至没有正式 artifact。第四，细粒度定量讨论几乎都以 Berti 为中心，BOP/IPCP 在 Figure 9 中有结果，但正文并没有给出同等丰富的数值展开。citeturn8view2turn15view0turn9view0

还有两点更“审稿人视角”的批评。其一，作者在 related work 中正确区分了 lower-level physical page-cross 的安全风险与本文 L1D/VIPT 场景，但并没有继续追问 L1D page-cross 是否也可能带来可观察 side effect。这未必是本文必须解决的问题，但至少可以在讨论里更明确说明。其二，论文的 adaptive thresholding 明显很关键，但又恰恰是最像经验调参、最难复现的部分；如果没有更公开的阈值设置与训练轨迹，MOKA 的“框架价值”会比 DRIPPER 的“具体实现价值”更容易被认可，而具体数值结果则更难独立验证。citeturn12view0turn8view0turn8view1

改进建议、可再分析方案与逐节批注

我建议后续工作优先做六件事。第一，补上 bootstrap 置信区间，至少对 seen / unseen / 8-core mixes 的 geomean 和 weighted speedup 给出不确定性范围。第二，公开 阈值、epoch 长度、初始化、mix 生成脚本，把 DRIPPER 从“可理解”推进到“可复现”。第三，增加 storage-performance Pareto，特别是压缩 pUB 的设计空间——因为按论文公开数字估算，pUB 占了总额外状态的一半以上。第四，补上 page-walk traffic、带宽、能耗 报告，让“少发坏跨页”在资源账目上也能被量化。第五，做 跨平台迁移，例如换页大小组合、换 TLB 结构、换不同 OoO 宽度。第六，把 DRIPPER 与更现代的在线控制方法做比较，例如 contextual bandit 或轻量 RL，看是否能在同等存储下进一步提高 unseen 泛化。上述建议都直接来自当前论文最明显的空白处。citeturn8view0turn8view1turn8view2turn9view0

从潜在应用看，这个方向很适合三类场景：图处理/大内存 footprint 应用，因为它们对 TLB 与 cache 都有压力；服务器 CPU 的 L1D 预取控制，因为跨页错误在多核共享资源下代价更大；以及面向虚拟内存深度协同的预取设计，因为它天然把地址翻译状态纳入硬件控制回路。换句话说，DRIPPER 不只是一个“改预取器的小技巧”，它更像一种把 virtual memory metadata 纳入 prefetch policy 的设计范式。citeturn15view0turn7view2turn13view0

逐节批注可以浓缩为下表：

论文部分	内容价值	我的批注
引言	很强	工业/学术 gap 抓得准，问题动机成立
动机	很强	通过 Figure 2–4 把“为什么静态策略不行”讲清楚了
MOKA 设计	很强	把程序模式、系统状态、在线阈值统一起来，是全文方法核心
训练与阈值	中上	思路聪明，但最依赖经验调参，也最难复现
实验方法	中上	配置透明、套件丰富，但工业 traces 的公开性受限
结果与消融	很强	coverage / accuracy / MPKI / IPC 链条完整，large-page 与 unseen 都有
相关工作与结论	中上	定位基本准确，但对实现代价、统计不确定性与安全讨论还不够

来源说明：上表是对论文各 section 的综合评议，依据来自全文结构与对应实验/方法描述。citeturn12view0turn10view1turn11view0turn15view0turn9view0

如果继续做二次分析，我最建议优先画五类图。其一，每 workload 的 speedup ECDF，看收益是否由少数长尾支撑。其二，accuracy 增益 vs IPC 增益散点图，检验“准确率翻转是否总能换到性能”。其三，dTLB/L1D MPKI 变化 vs IPC 变化，验证不同层级污染对性能的边际贡献。其四，storage 开销拆解 Pareto 图，检验压缩 pUB 的价值。其五，2MB 场景下跨 4KB 与跨 2MB 的 page-cross 频次直方图，进一步验证“>99% 不跨 2MB”这一结论。当前公开资料里没有逐 workload 原始 CSV 或日志，所以再分析只能走两条路：一条是做图表数字化近似重建，另一条是重新实现/复刻 ChampSim 配置。如果你后续授权我做再分析，我会优先从“图表数字化 + 一致性检查”开始，因为这是当前信息条件下最现实的路径。citeturn9view0turn15view0turn8view2

最后，用一句最简洁的话概括这篇论文：它成功证明了“跨页预取不是该不该做，而是该由谁、在什么时候、凭什么证据去决定”。 这是一个很好的问题、一个很像样的答案，也是一篇仍然留有清晰后续空间的体系结构论文。citeturn12view0turn15view0turn7view2