这篇论文提出的是 IP-CaT: Instruction Prefetch Centric Cache and TLB Management (Enhancing Instruction Prefetching via Cache and TLB Management, 2026 ISCA)

TLDR：

  1. 现代 L1I prefetcher 本身已经很强，但被两个结构影响了性能：跨页 prefetch 的 address translation latency，以及 L2C 中 prefetched code line 的高变异复用行为
  2. IP-CaT 用两个硬件模块处理这两个问题：
    • 面向跨页指令预取的 TLB stream buffer tPB : 缓存由 L1I page-cross prefetch 触发的 translation, 只复用 L1I prefetch 已经触发的 page walk 结果，避免污染 sTLB，并在后续 demand instruction translation 时转正到 sTLB。
    • 面向跨页指令预取的 L2C 替换策略管理 TIPRP: 专门管理 L2C 中由 L1I prefetch 带来的 code line, 在保护、低优先级插入、绕过三种策略间动态选择，因为 L1I prefetched line 既可能 dead-on-arrival，也可能极高复用。
  3. 在 105 个单核 server workloads 上，IP-CaT 分别让 EPI / Barça / FNL+MMA 获得 6.1% / 8.3% / 7.9% geomean speedup，并优于 CHiRP、Morrigan、Emissary、SHiP++、Mockingjay 等 TLB/cache 管理方案

背景和动机

现代 server workload 的 instruction footprint 很大，并且论文引用既有研究指出其 instruction footprint 可能以每年最高约 30% 的速度增长。
L1I、BTB、iTLB/sTLB 等前端结构虽然也在变大，但增长速度跟不上 server 软件栈和代码 footprint 的扩大，因此 front-end bottleneck 越来越显著。

L1I prefetching 是缓解 front-end stall 的关键技术。
本文评估的 EPI、FNL+MMA、Barça 都是强 L1I prefetcher，且在本文 workload 上已有较高 accuracy 和 coverage：EPI 为 74.1% / 85.8%，FNL+MMA 为 72.9% / 85.0%，Barça 为 67.7% / 83.7%。因此本文不是在弱 prefetcher 上“捡便宜”，而是研究强 L1I prefetcher 为什么仍没吃满收益。

跨页指令预取

现有 L1I prefetcher 通常在 virtual address 空间工作，因为 L1I 常是 VIPT。它们可以选择丢弃跨页 prefetch，也可以允许 page-cross prefetch，让预取流跨越 instruction page boundary。
论文发现，对 instruction stream 来说，允许跨页通常是有利的；这和 data prefetch 不同，因为 instruction stream 更多来自顺序执行和循环控制流，可预测性更高。

但允许跨页后，prefetch request 需要 address translation。若 iTLB/sTLB miss，则 page walk latency 会削弱 prefetch timeliness。换句话说，L1I prefetcher 虽然预测到了未来代码块，但 translation 太慢会让预取变晚。

Cache hierarchy

L1I prefetch 会把 code line 带入 L2C，但这些 line 的 reuse 行为差异很大。
以 EPI 为例，L2C 中由 L1I prefetch 带来的 code line 平均有 36.1% 一次 demand L2C access 都不服务，51.6% 只服务 1 到 8 次，11.5% 服务超过 8 次，0.8% 服务超过 128 次。

这个分布说明：统一保护所有 prefetched code line 会污染 L2C，统一低优先级或 bypass 又会丢掉少数非常有价值的 line。

相关工作：

Title Authors, From url
A Cost-Effective Entangling Prefetcher for Instructions Ros and Jimborean, ISCA 2021 https://doi.org/10.1109/ISCA52012.2021.00017
The FNL+MMA Instruction Cache Prefetcher Seznec, IPC 2020 report https://hal.inria.fr/hal-02884880/document
Barca: Branch-agnostic region searching algorithm Gratz et al., IPC 2020 -
Morrigan: A Composite Instruction TLB Prefetcher Vavouliotis et al., MICRO 2021 https://doi.org/10.1145/3466752.3480049
CHiRP: Control-Flow History Reuse Prediction Mirbagher-Ajorpaz et al., MICRO 2020 https://doi.org/10.1109/MICRO50266.2020.00023
Emissary: Enhanced Miss Awareness Replacement Policy for L2 Instruction Caching Nagendra et al., ISCA 2023 https://doi.org/10.1145/3579371.3589097
Effective mimicry of Belady’s MIN policy Shah et al., HPCA 2022 https://doi.org/10.1109/HPCA53966.2022.00048
To cross, or not to cross pages for prefetching? Vavouliotis et al., HPCA 2025 https://doi.org/10.1109/HPCA61900.2025.00025

Insight

Insight1: L1I page-cross prefetch 是有价值的，但 translation latency 吃掉了 timeliness

论文比较三种情况：

  1. No Page Cross：跨页 L1I prefetch 被丢弃。
  2. Permit Page Cross：允许 L1I prefetch 跨页并正常走 translation。
  3. Free Translation L1I Prefetching：理想化地让所有 L1I page-cross prefetch 的 sTLB miss 立即变成 sTLB hit。

结果显示，Permit Page Cross 一致优于 No Page Cross，说明 instruction prefetch 跨页本身是有收益的。进一步地，Free Translation L1I Prefetching 又优于 Permit Page Cross，说明 translation latency 不是小问题，而是在限制 prefetch timeliness。

这个 insight 的关键不在于“TLB miss 很慢”这个常识，而在于：L1I prefetcher 本身已经在替未来 instruction stream 触发 translation，如果能保存并复用这些 translation，就可以减少后续 demand instruction translation 的 page walk，同时不必引入一个额外 aggressive TLB prefetcher。

Insight2: L1I prefetched code line 的 reuse 是 trimodal 的

论文用理想 L2C 实验说明 L1I prefetch 对 L2C 造成的压力很大。Ideal L2C (All Pref) 把所有由 L1I prefetch 带来的 code line 暂存在无限 buffer 中，只有后续 demand L2C miss 真正需要它时才插入 L2C。以 EPI 为例，这个理想机制比 Permit Page Cross baseline 多出 9.5% speedup，说明 prefetched line 的 L2C pollution 是真实瓶颈。

更细地看，prefetched code line 大致有三类：

  1. dead-on-arrival：进入 L2C 后不服务任何 demand access，应尽量 bypass 或快速驱逐。
  2. limited reuse：服务少量访问，不值得长期保护，但完全绕过也可能损失。
  3. high reuse：服务大量 demand access，应被优先保留。

因此，一个好的 L2C policy 不能只按“code line 比 data line 重要”来处理，也不能只按“prefetch line 不可靠”来处理。它必须识别 execution phase 中 prefetched code line 的当前价值，并在保护、弱化、绕过之间切换

Insight3: TLB 与 L2C 优化有协同效应

tPB 减少 page walk，而 page walk 本身会访问 cache hierarchy；因此减少 page walk 也会减少 L2C/LLC 竞争，使 TIPRP 更容易发挥作用。论文消融中，EPI 下 tPB 和 TIPRP 单独分别是 2.9% 和 2.9% geomean speedup，二者线性相加是 5.8%，但 IP-CaT 达到 6.1%。这说明两个模块不是简单并列，而是有结构性协同。

核心设计

IP-CaT 由两个模块组成：

  1. translation Prefetch Buffer (tPB)：位于 sTLB 旁边，保存由 L1I page-cross prefetch 触发 page walk 得到的 instruction PTE。
  2. Trimodal Instruction Prefetch Replacement Policy (TIPRP)：L2C replacement policy，只针对由 L1I prefetch 带入 L2C 的 code line，动态选择保护、低优先级插入或 bypass。

设计点 1: translation Prefetch Buffer (tPB)

针对的问题：L1I page-cross prefetch 若 miss iTLB/sTLB，会触发 page walk；page walk 完成太晚会降低 prefetch timeliness。若直接把这些 speculative translation 全部插入 sTLB，又可能污染 demand translation 需要的 sTLB entry。

解决的思路：把 L1I prefetch 触发的 translation 暂存在独立小结构中。只有当后续 demand instruction translation 真的需要它，才把它插入 sTLB。

设计：

  1. tPB 是位于 sTLB 旁边的小型 set-associative 结构，entry 保存 vpn、ppn 和 sTLB entry 通常需要的 attribute bits。
  2. L1I prefetch request 先查 iTLB，再查 sTLB；如果两级都 miss，则查 tPB。
  3. 若 tPB hit，则把该 translation 插入 sTLB，并 invalid 掉 tPB 中对应 entry。
  4. 若 tPB miss，则发起 prefetch page walk。page walk 返回的 translation 插入 iTLB 和 tPB，但不插入 sTLB，以避免污染 sTLB。
  5. Demand instruction translation 若 miss iTLB/sTLB，也查 tPB；若 hit，则把 translation 插入 sTLB，并 invalid tPB entry。
  6. tPB 只由 L1I page-cross prefetch 的 translation request 填充，不由普通 demand sTLB miss 填充。

为了区分 translation request 的来源，IP-CaT 在 sTLB MSHR 中增加 cross-bit (cb)。当 miss 来源是 L1I page-cross prefetch 时，cb=1，page walk 返回后写入 tPB；否则仍按正常路径写入 sTLB。

实现上，论文说明 tPB 可以作为 sTLB 旁边的独立结构，也可以通过给 sTLB 增加若干 dedicated sets 来集成，从而降低 coherence 管理复杂度。TLB shootdown 只需要把 tPB 作为额外 TLB level 纳入 invalidation。

可能引入的问题是：tPB 和 sTLB 之间引入的 mux 可能影响时序

设计点 2: Trimodal Instruction Prefetch Replacement Policy (TIPRP)

针对的问题：L1I prefetch 带来的 code line 复用行为高度分化。固定保护会造成 L2C pollution，固定低优先级或 bypass 又会伤害 high-reuse prefetched line。

解决的思路：把 L2C 中 L1I prefetched code line 的管理拆成三种 policy，并用 decision tree 在 phase 间动态选择。

三种基础 policy：

  1. PIP (Prioritize Instruction Prefetch)：保护由 L1I prefetch 带入的 line。选择 victim 时优先找不是 L1I prefetched 的 line；如果全是 prefetched line，则退化为 evict LRU/RRPV=3 line。
  2. NPIP (Non-Prioritize Instruction Prefetch)：弱化 L1I prefetched line。prefetched line 插入到 recency stack 底部，即 RRPV=3；其他 line 使用标准 SRRIP 行为。
  3. BIP (Bypass Instruction Prefetch)：直接 bypass L1I prefetched code line，不插入 L2C；其他 line 使用标准 SRRIP 行为。

PIP 主要在 eviction time 起作用，因为它要保护 prefetched line 不被选为 victim。NPIP 和 BIP 主要在 insertion time 起作用，因为它们分别通过低优先级插入和绕过来减少 prefetched line 占用。

动态选择机制：(set dueling)

  1. TIPRP 把 L2C set 静态分成 PIP Leader Sets、NPIP Leader Sets、BIP Leader Sets 和 Follower Sets。
  2. 论文经验选择 32 / 16 / 16 个 Leader Sets 分别用于 PIP / NPIP / BIP。
  3. 用两个 10-bit saturating counters：PSEL1 和 PSEL2，形成两层 decision tree。
  4. Follower Sets 根据 PSEL1 和 PSEL2 选择 PIP、NPIP 或 BIP。
  5. 与传统 set-dueling 不同，TIPRP 在 L2C hit 和 eviction 两类事件上训练，而不是只在 eviction 上训练。
  6. TIPRP 使用每个 L2C block 的 prefetch bit (pb) 区分该 line 是否由 L1I prefetch 带入。若硬件没有现成 pb，则可通过 L1I/L2C MSHR 传播。

训练机制的关键是 asymmetric update：

  • PIP Leader Set 只在 pb=1 的 hit/eviction 上更新 counter，因为这些事件直接反映“保护 prefetched line 是否有用”
  • NPIP/BIP Leader Set 则主要在 pb=0 的事件上更新，因为这些事件反映“牺牲非-prefetch line 给 prefetched line 留空间是否伤害性能”

论文称，只在这些强相关事件上更新 counter，比所有事件都更新带来约 5% 更高 IPC。

硬件开销

基于论文的 baseline，IP-CaT 总 storage overhead 为 0.79KB：

  1. 64-entry tPB 为 6452 bits
  2. sTLB MSHR 的 16 个 cb bits
  3. 两个 10-bit PSEL counters

总开销约为 L2C 容量的 0.08%。

实验 Setup

实验平台：论文使用 ChampSim trace-based simulator，模拟 out-of-order core、three-level cache hierarchy、decoupled front-end 和 FDIP。地址翻译模型包含 5-level radix tree page table、x86 hardware page table walker 和 MMU caches。baseline 类似 Intel Cascade Lake。

核心配置：

Component Configuration
CPU Core 1-core / 4-core, 4GHz, 128-entry FTQ, 352-entry ROB, 6-wide issue
Branch Predictor TAGE-SC-L, 8K-entry BTB, 64-entry RAS
iTLB / dTLB 64-entry, 4-way, 1 cycle, 8-entry MSHR, LRU
sTLB 1536-entry, 12-way, 8 cycles, 16-entry MSHR, LRU
Page Structure Caches 4-level split PSC, parallel search, L5/L4/L3/L2 = 1/2/8/32 entries
L1I 32KB, 8-way, 4 cycles, 8-entry MSHR, LRU, with EPI / Barça / FNL+MMA
L1D 48KB, 12-way, 5 cycles, 16-entry MSHR, LRU, Berti data prefetcher
L2C 1MB, 16-way, 10 cycles, 32-entry MSHR, LRU baseline
LLC 1.375MB per core, 11-way, 36 cycles, 64-entry MSHR, SHiP
DRAM 4GB/core, 25.6GB/s, 1 channel/core

workload 选择：

  1. 单核主实验使用大 code footprint 的 server workloads，包括 Qualcomm traces 以及 NodeApp、PHPWiki、TPCC、Twitter、Wikipedia、Kafka、Spring、Tomcat、Chirper、HTTP 等。
  2. 主实验只保留 instruction sTLB MPKI 至少 0.5 的 workload，共 105 个 single-core server workloads。
  3. 每个 workload warm-up 50M instructions，再模拟 100M instructions。
  4. 多核实验构造 60 个 homogeneous 4-core mixes 和 100 个 heterogeneous 4-core mixes，共 160 个 mixes，指标为 normalized weighted speedup。
  5. SMT 实验扩展 ChampSim 支持 SMT，构造 75 个随机 workload pairs。
  6. 页大小实验包括纯 4KB pages，以及 4KB + 2MB pages 的混合场景。

对比方案：

  1. TLB 管理：CHiRP、Morrigan。
  2. Code-aware / prefetch-aware / general cache replacement：CLIP、Emissary、PACIPV、PACMAN、SRRIP、DRRIP、SHiP++、Mockingjay。
  3. 组合方案：tPB 与多个 state-of-the-art cache/TLB policies 组合。
  4. 消融方案：tPB、NPIP、BIP、PIP、TIPRP、SRRIP(L2C)、IP-CaT。

实验结果

实验 1: 单核主实验

设计：在 105 个 instruction-TLB-intensive server workloads 上，分别以 EPI、Barça、FNL+MMA 作为 L1I prefetcher，比较 IP-CaT 与 TLB/cache replacement policies。

结果：

Scheme EPI Barça FNL+MMA
TIPRP alone 2.9% 4.8% 5.0%
IP-CaT 6.1% 8.3% 7.9%

IP-CaT 在三个 prefetcher 上均优于 CHiRP、Morrigan、CLIP、Emissary、PACIPV、PACMAN、DRRIP、SHiP++、Mockingjay，即使这些方案与 tPB 组合也不如 tPB+TIPRP。

结论：IP-CaT 的收益不是绑定某一个 L1I prefetcher，而是来自 L1I prefetch 下游 TLB 与 L2C 管理的共性瓶颈。

评价：baseline 选择较强，因为三个 L1I prefetcher accuracy/coverage 都很高；这使结果更可信。不过主实验筛选了 instruction sTLB MPKI >= 0.5 的 workload，偏向能展现 translation bottleneck 的场景。

实验 2: MPKI 与 miss latency 分析

设计：比较 baseline 与 IP-CaT 在 L2C、LLC、sTLB 上的 MPKI 和 average miss latency。

结果：

  1. tPB 显著降低 sTLB MPKI；按论文定义，sTLB MPKI 是同时 miss sTLB 和 tPB 的访问数。EPI / FNL+MMA / Barça 下分别降低 31.6% / 18.2% / 32.3%。
  2. TIPRP 降低 LLC miss，并改善平均 miss latency；它有时会让 L2C instruction MPKI 上升，但这是以减少更昂贵下层 miss 和 page-walk traffic 换来的。
  3. page walk 减少后，cache hierarchy 的额外压力也降低，因此 tPB 间接帮助 TIPRP。

结论：IP-CaT 的关键不是简单减少某一级 MPKI，而是把 instruction fetch 的 critical latency path 缩短；即使 L2C MPKI 局部上升，也可能因 LLC/sTLB latency 降低而提高 IPC。

实验 3: 与 L2C 版本 prior policies 对比

设计：把原本设计用于 LLC 的 Mockingjay、PACIPV、SHiP++、SRRIP、DRRIP 等应用到 L2C，与 TIPRP/IP-CaT 对比。

结果：以 EPI 为例，IP-CaT 分别比 Mockingjay、PACIPV、SHiP++、SRRIP、DRRIP 高 8.0%、3.0%、5.3%、4.4%、3.6%。

结论：只把通用 replacement policy 搬到 L2C 不够；TIPRP 的优势来自它显式识别 L1I-prefetched code line，并按 phase 动态选择 PIP/NPIP/BIP。

实验 4: 组件消融

设计：单独评估 tPB、NPIP、BIP、PIP、TIPRP、SRRIP(L2C) 以及完整 IP-CaT。

结果：在 EPI 下，tPB、NPIP、BIP、PIP、TIPRP、SRRIP(L2C)、IP-CaT 分别为 2.9%、4.8%、5.5%、-1.5%、2.9%、1.7%、6.1% geomean speedup。

结论：

  1. 单独 PIP 反而负收益，说明“保护所有 prefetched instruction line”不是好策略。
  2. BIP/NPIP 单独有效，说明 dead-on-arrival prefetched line 比例确实高。
  3. TIPRP 低于 BIP alone 的一个可能解释是它需要在不同 phase 间折中，但完整 IP-CaT 最高，说明 tPB 降低 page-walk/cache contention 后，TIPRP 的动态策略更有用。

评价：消融非常关键，因为它证明本文不是简单叠加一个 TLB buffer 和一个 cache policy；二者之间通过 page-walk traffic 产生协同。

实验 5: tPB size/associativity 与 sTLB integration

设计：改变 tPB entry 数量和组织方式，并比较独立 tPB 与集成到 sTLB dedicated sets 的实现。

结果：

  1. EPI 下，fully-associative tPB 从 8 entries 增至 128 entries，hit rate 从 3.1% 增至 48.3%；论文选择 64-entry 作为性能和复杂度折中点。
  2. 固定 64 entries 时，EPI 下 fully-associative 到 direct-mapped 的 hit rate 从 37.2% 降至 28.0%；32-way 和 16-way 与 fully-associative 差距较小。
  3. 集成到 sTLB 时，给 sTLB 增加 4 sets / 8 sets dedicated to tPB，hit rate 分别为 25.6% / 41.6%；独立 fully-associative tPB 为 36.2%。论文称这些 hit-rate 差异没有转化为显著性能差异。

结论：tPB 不需要很大；64 entries 已是可行点，而且可通过 sTLB 增设 sets 的方式降低实现和 shootdown 管理复杂度。

实验 6: Branch predictor、LLC size 和 page size 敏感性

设计：评估 ITTAGE indirect branch predictor、不同 LLC 容量、以及 4KB/2MB 混合页大小对 IP-CaT 的影响。

结果：

  1. 加入 ITTAGE 后，15 个代表性 workload 上 IP-CaT 性能趋势基本不变，最大 IPC variation 为 2.4%。
  2. EPI 下，LLC 为 1MB 时 IP-CaT geomean speedup 为 12.7%，LLC 为 4MB 时降至 2.6%；LLC 越大，L2C policy 重要性越低，但 IP-CaT 仍有收益。
  3. EPI 下，大页比例从 0% 增至 100% 时，IP-CaT speedup 从 7.5% 降至 1.8%；最佳 prior-art 从 4.5% 降至 -0.4%。当所有 footprint 都映射到 2MB pages 时，tPB alone 基本无收益，因为 sTLB miss 已很少。

结论：IP-CaT 对大 LLC 和大页仍有收益，但主要受益场景是 L2C/translation 压力较高、4KB page 仍大量存在的 server 环境。

实验 7: 多核与 SMT

设计：在 160 个 4-core workload mixes 和 75 个 SMT workload pairs 上比较 IP-CaT 与其他方案。

结果：

  1. 4-core 下，IP-CaT 在三个 L1I prefetcher 上均优于所有 competing schemes。以 EPI 为例，IP-CaT 比 CHiRP、Morrigan、CLIP、Emissary、PACIPV、SHiP++、Mockingjay 分别高 7.2%、6.8%、7.8%、9.1%、9.3%、9.0%、14.2%。
  2. SMT 下，IP-CaT 同样最优；以 EPI 为例，比 CLIP、PACIPV、PACMAN 分别高 7.1%、9.3%、10.3%。

结论：多核和 SMT 会加剧 sTLB/L2C contention，因此 IP-CaT 的 cache/TLB 协同管理仍能成立，甚至在 SMT 下绝对收益更大。

Limits

  1. 主实验选择 instruction sTLB MPKI >= 0.5 的 workload，适合验证 translation bottleneck，但会放大对 TLB-intensive 场景的关注。论文补充了 788 个未按 sTLB MPKI 筛选的 Qualcomm workloads，显示 IP-CaT 不伤害非 TLB-intensive 场景，但细粒度分析较少。
  2. IP-CaT 的收益随 huge page 比例升高而下降。若系统能稳定把绝大多数 code/data footprint 放入 2MB pages，tPB 的空间会明显缩小；此时剩余收益主要来自 TIPRP。
  3. IP-CaT 的收益也随 LLC 变大而下降。大 LLC 已经能吸收更多 working set，L2C replacement 的相对重要性降低。
  4. tPB 需要纳入 TLB shootdown/coherence 流程；论文认为可作为额外 TLB level 或集成进 sTLB，但没有给出完整 RTL/timing/energy 评估。
  5. TIPRP 依赖 pb 标记 L2C line 是否由 L1I prefetch 带入。论文指出很多设计已有类似 prefetch metadata；若没有，需要在 L1I/L2C MSHR 和 cache metadata 中传播。
  6. wrong-path requests 没有专门处理。论文承认 IP-CaT 像普通 replacement policy 一样对 wrong-path agnostic；错误路径上的 prefetch/translation 可能污染 tPB 或 L2C，也可能偶然有用。
  7. TIPRP 的 leader set 数量、PSEL bits、decision tree 结构主要来自经验选择。该机制是 phase-level global adaptation，不是 per-PC 或 per-region 精细预测；遇到更细粒度快速变化的 instruction behavior，可能反应不够快。
  8. 论文使用 ChampSim trace-based simulation。虽然配置详细且覆盖单核、多核、SMT，但仍缺少真实 OS、真实 page allocation、TLB shootdown、context switch、speculation recovery 等全系统效应。
  9. IP-CaT 不改进 L1I prefetcher 的预测本身。它假设已有 prefetcher 具备较高 accuracy/coverage；若 prefetcher 很差，TIPRP 可以 bypass 一部分污染，但 translation/cache 协同收益会受限。
  10. IP-CaT 与 BOLT、Codestitcher、huge page placement、iTP/xPTP 等软件或硬件技术是互补关系，但论文没有实现组合评估；真实系统中组合收益可能非线性。