Dorado: Cache Coherence for 1,000+ Cores

Dorado：面向千核处理器的层次化缓存一致性协议

Authors: Jovan Stojkovic, Abraham Farrell, Gerasimos Gerogiannis, Zhangxiaowen Gong*, Christopher J. Hughes*, Josep Torrellas Affiliation: UIUC, *Intel Labs Venue: ISCA 2026 Presenter: Zongwu Wang | 2026-07-03

TL;DR

  • Bottleneck: 1000+ 核一致性协议的三重困境——远端 home 访问的高延迟 + 广播 invalidate 的高流量 + 全位向量的高存储

  • Core Idea: 三项正交技术协同——TLH（本地化事务）、Dynamic Apportioning（动态空间竞争）、SetOverflow（per-set 溢出），首次同时改善延迟、流量和存储

  • Headline Result: 相比等面积 Dir₂B 平均加速 1.36×，load 延迟 −46.1%，以 24 bits/entry（vs 66 bits）实现与 full bit vector 差距 <1%

Background：Snoop vs Directory Coherence

Snoop-Based Coherence：延迟与开销

  • 工作原理：所有核心共享广播总线，每个 cache controller 侦听 所有事务，维护本地 MESI 状态
  • 延迟：Requester → Bus Arbitrate → Broadcast → All Snoop → Response。仲裁 O(1)，但串行化所有请求——同时仅一个事务占用总线
  • 流量：每次广播到所有 N 核，O(N) 流量，即使仅 1 个 sharer
  • 存储：无目录——每核仅需 ~2 bits/line（MESI），无额外开销
  • 上限：总线带宽随核数下降，电气负载 + 仲裁延迟 → 实际限制 8–16 核

Directory-Based Coherence：延迟与开销

  • 工作原理：分布式目录追踪每 line 的共享者集合。事务 pt-to-pt，不走广播，通过 NoC 路由
  • 延迟：Requester → NoC → Home Dir Lookup → Fwd to Sharers → Response。Home 在远端 cluster 时 cross-cluster RT ≥ 60 cycles (1024-core mesh)
  • 流量：pt-to-pt O(k)，仅发 invalidate 给实际共享者；但 limited-pointer 溢出时退化为广播
  • 存储：精确追踪 O(N²)——full bit vector = 66 bits/entry for 1024 cores

Problem：Triple Trade-off at 1000+ Cores

  • 延迟墙：远端 home 访问需 cross-cluster RT（≥60c），一次 read miss 可能 3 次穿越 → ~198 cycles
  • 流量墙：Limited-pointer 溢出设 Broadcast 位 → 写入时广播到所有核心，浪费带宽 + 触发所有 tag lookup
  • 存储墙：Full bit vector = 66 bits/entry；6MB/core LLC 下目录占 ~10%+ 面积，不可接受
  • 关键矛盾：已有技术（Bloom Filter, Cuckoo, Hierarchical, Pool Dir...）最多改善 2/3 维度而牺牲第三个——Dorado 需打破此 triple trade-off

Key Observations (→ Three Design Pillars)

Obs 1 — 91% 远端 load miss 可本地化 (→ TLH) - 32-core cluster 下，绝大多数远端 home line 可由本地核心提供（Fig.3）。大量 line 是 read-mostly + 多线程共享

Obs 2 — Workload 差异巨大 (→ Dynamic Apportioning) - Redis 以 remote 为主，FaaSFunc 以 local 为主（Fig.4）。固定 local/remote 比例必然次优

Obs 3 — 多共享者稀有但关键 (→ SetOverflow) - 多数 line 只有 ≤2 sharer，少数被数十核共享。需按需溢出，不为少数犒赏全体

Existing Work：技术全景

Directory Protocol Evolution

Dorado：High-Level Architecture

  • 32 clusters × 32 cores = 1024 cores，双级 2D mesh NoC，每 core 配 directory-LLC slice（TD + ED）
  • 物理地址哈希确定 Global home（串行化点）；远端 cluster 访问时按需创建 Temporary home

Mechanism 1：Two-Level Homes (TLH)

  • 解耦正确性与性能：Global home = 唯一串行化点；Temporary home = 分布式本地缓存
  • 三种指针：LLptr（本地核 ID）、LRptr（远端 cluster ID，1 ptr = 32 cores）、RLptr（Temp home 中本地核 ID）
  • MS 状态：dirty remote line 多核读取时不用写回 Global home → 进一步减少远端流量

TLH：事务延迟分析

Mechanism 2：Dynamic Apportioning

  • 问题：TLH 引入 3 种指针 + local/remote 数据 + TD/ED——静态分区顾此失彼（Redis vs FaaSFunc）
  • 方案：所有类型共享同一硬件，动态竞争空间，workload 自适应
  • 代价：指针加 1 bit type 标记（6b vs 5b），完全消除静态划分浪费

Mechanism 3：SetOverflow

  • 设计：Per-set PointerSpace (12 共享指针) + OwnerWay (T¹=6, T²=2) 记录归属
  • 溢出流程：way 内 2 ptr 用尽 → O=1 → 从 PointerSpace 申请 → 用尽则 B=1 (广播)
  • 32cl_32co 下仅 2% set 溢出；写操作收集需额外 3 cycles（非关键路径）

Hardware Overhead

Verification：TLA+ Model Checking

  • 模型：4 clusters × 4 cores × 4 lines — 覆盖数千种 interleaving；含 M/E/S/I/MS 五状态
  • 验证 5 属性：SWMR 语义 · Dirty-bit consistency · Home consistency · Sharer soundness · Read correctness
  • 结果：TLC 报告 无死锁、无活锁、无 invariant violation
  • 核心不变量：任何修改 Global home 的事务必须先锁 Global home，才能锁 Temp home

Methodology

  • Simulator: SST + DRAMSim2，Pin trace，Ariel OoO (6-issue, 3GHz, TSO, 352-ROB)
  • Cache: L1I/D 64/32KB → L2 2MB/core → L3 6MB/core, 2D mesh NoC (5c/hop intra, 60c cross-cluster)
  • Workloads (13 apps, 1024 threads): Graph (BFS/DFS/CC/PR), Redis (R/W), FaaS (FuncBench), ML Serving (DLRM/CNN), µService (SocNet), MUMmer, MapRed
  • Baselines (all ≈ same directory storage): Dir₂B, TLH-Dir₄B, TLH-Dir₃B-Dyn, UpperBound (66b), SCD, WayC, Hier2/4/16

Performance：Main Results

  • 三层递进：Dir₂B (1.00×) → TLH-Dir₄B (1.17×) → TLH-Dir₃B-Dyn (1.24×) → Dorado (1.36×)
  • Dorado vs UpperBound (full bit vector, 2.75× 存储)：性能差距 < 1%

Performance：Why It Works

Metric Dir₂B → Dorado Mechanism
Remote L2-missing loads −89.6% TLH: Temp home 截获
Invalidation messages −39% SetOverflow + LRptr (1=32 cores)
Avg data load latency −46.1% TLH 消除 cross-cluster RT
  • Fig.14：Dorado 下绝大多数请求在 Local-L2 + Cluster-L3 完成
  • 加权延迟：first miss 138c (9%) + subsequent 35c (91%) ≈ 44c vs Dir₂B 198c

Comparison：Many-Sharer Designs

  • 等存储下：SetOverflow (+10.5%) > WayC (+5.8%) > SCD (+3.1%)（vs TLH-Dir₃B-Dyn）
  • SCD 在 set-assoc cache 上冲突多；WayC 需空闲 way；SetOverflow 无此限制

Comparison：Hierarchical Coherence

  • Hier4 (8MB extra cache/core) = 1.20× vs Dorado (6MB) = 1.36× — 更少 cache，更高性能
  • 层次化 write 延迟：上溯覆盖层 → 逐级下发 invalidate → 多层串行；Dorado flat-TLH 直接到串行化点
  • SocNet (cross-cluster R/W sharing)：Hier4 L1 load = 72c，Dorado = 57c（−21%）

Sensitivity：Consistency & Scalability

  • TSO → RC：Dorado 1.36× → 1.38×；vs Hier4 从 1.13× → 1.11× (RC 对写延迟高的 Hier4 补偿更多)
  • SetOverflow 扩展：64-core cluster 仅 3% set 溢出 → 12-pointer PointerSpace 足够
  • RTL 面积/功耗：+0.44% area, +2.3% leakage, +1.8% dynamic → 工业可接受

Conclusion

  • TLH：Global home 串行化 + Temporary home 本地缓存 → −89.6% remote load miss
  • Dynamic Apportioning：所有类型动态竞争同一硬件 → workload 自适应，消除静态划分浪费
  • SetOverflow：per-set 精细溢出 → 多共享者精确追踪，优于 SCD/WayC 2-3×
  • 综合：1.36× 加速 + 46.1% 延迟降低 + 2.75× 存储节省 vs full bit vector，硬件代价可忽略

Critique：Pros & Cons

✅ 优点

  • 三层技术正交互补，各攻一个明确定义的瓶颈
  • TLA+ 验证 + RTL 综合 → 正确性到物理实现的完整证据链
  • Baseline 全面公平（等存储），Table I 分类堪称模板

❌ 局限

  • Temp home 多副本空间膨胀上界未量化；TLA+ 仅 4×4×4 配置
  • 无全系统模拟，OS activity (page fault, TLB shootdown) 影响被忽略

Future Work

  • CXL Multi-Socket：TLH 思想扩展到 CXL 场景——socket 内 = cluster，socket 间 = TLH
  • ML-Guided Partition：硬件计数器监测 sharing pattern → 预测 phase transition → 预调 Dynamic Apportioning 策略
  • Larger-Scale TLA+：使用 stateless model checking 或 symbolic execution 覆盖 ≥16-core 配置