BlackWell 双计算 die 的 L2 一致性 cases

在了解的 BlackWell B200 双计算die下，什么情况下需要实施L2 cache 一致性操作，发掘所有 cases。

基于公开架构文档、微基准测试论文（Chips and Cheese 、arxiv ）及 NVIDIA 技术资料，以下是 Blackwell B200/B300 双计算 die 架构下所有需要触发 L2 Cache 一致性操作的场景。

前提：B200/B300 的 L2 与 Coherence 架构

组件	配置
Die 结构	2× 计算 die（各 ~74 SMs），通过 NV-HBI（10 TB/s）互联
L2 组织	物理分区（Partitioned），总共 4 个 L2 partition （每 die 2 个），逻辑上通过 NV-HBI 呈现为统一、共享、硬件一致的 L2
Coherence 机制	硬件维护跨 die 一致性（Hardware cache coherence），对 CUDA 透明
NUMA 边界	存在隐性 NUMA：本地 L2/HBM 延迟低，跨 die 访问延迟显著增加

注意：B200 的 L2 虽然对软件呈现为"统一缓存"，但物理上是分区的。任何跨 partition（尤其是跨 die）的同一地址访问，都可能触发 coherence 协议（目录查询、无效化、写回或迁移）。

一、跨 Die 数据共享类（运行时读写冲突）

Case 1: 跨 Die 写后读（RAW, Read-After-Write）

场景：Die 0 上的 SM 写入全局地址 X，随后 Die 1 上的 SM 读取同一地址 X。
触发原因 ：Die 1 的 L2 partition 中可能缓存了 X 的旧副本。硬件必须：
- 查询目录（Directory Lookup）确定 X 的 Home 位置；
- 将 Die 0 L2 中的脏数据（Dirty Line）写回 HBM，或经由 NV-HBI 直接转发到 Die 1；
- 使 Die 1 中该地址的旧缓存行失效（Invalidate）。
性能影响：跨 die 延迟远高于本地 L2 命中（Chips and Cheese 实测延迟显著增加）。

Case 2: 跨 Die 读后写（WAR, Write-After-Read）

场景：Die 1 读取 X 后，Die 0 对 X 执行写入。
触发原因：需要确保 Die 1 的 L2 中 X 的只读副本失效，并允许 Die 0 获取独占写权限（Exclusive Ownership）。

Case 3: 跨 Die 并发写（WAW, Write-After-Write）

场景：两个 die 上的 SMs 几乎同时对同一地址 X 写入。
触发原因：L2 必须串行化写入顺序，确保所有 die 的 L2 最终看到一致的数据版本。涉及目录锁、缓存行所有权转移和写传播。

Case 4: 跨 Die 原子操作（Atomic Operations）

场景：atomicAdd、atomicCAS、atomicExch 等操作的目标地址位于 Die 0 的 HBM，但由 Die 1 的 SM 发起。
触发原因 ：原子操作通常以 L2 为 Coherence Point 。跨 die 原子需要：
- 目录查询定位 Home Partition；
- 将操作路由到持有该缓存行的 die；
- 执行后更新/失效其他 die 的副本。
特别说明：B200 的原子操作如果涉及跨 die，可能退化为"远程 L2 执行"或"写穿到 HBM + 广播失效"，性能远低于本地原子。

二、显式同步与内存屏障类（软件触发的 Coherence）

Case 5: CUDA 内核启动边界（Kernel Launch Boundary）

场景：Kernel A 在 Die 0 上修改了全局内存，随后 Kernel B 在 Die 1 上读取该内存。
触发原因 ：虽然 CUDA 编程模型保证内核间一致性 （即新内核能看到旧内核的写入），但在双 die 硬件上，这需要驱动/硬件在启动时：
- Flush Die 0 L2 中的脏行到 HBM，或
- 使 Die 1 L2 的对应地址范围失效。
用户视角：隐式同步，无需显式代码，但硬件在底层执行了跨 die coherence。

Case 6: `threadfence()` / `threadfence_block()`

场景：一个线程块内（或 grid 内）的线程通过 __threadfence() 保证全局内存写入对所有线程可见。
触发原因 ：__threadfence() 在单 die 上通常只需等待 L2 写回；在 B200 上，若数据可能被其他 die 缓存，则需要触发跨 die 的**写传播（Write Propagation）**或目录更新，确保其他 die 的 L2 能看到最新值。

Case 7: `__threadfence_system()`

场景：GPU 内核与 CPU（Grace 通过 NVLink-C2C）共享统一内存。
触发原因 ：这是最强的一致性屏障。需要：
- Flush 两个 die 的所有 L2 脏行到 HBM；
- 使 CPU LLC（Grace 的 L3）中对应地址失效；
- 在 GB200 Superchip 中，NVLink-C2C 作为 Coherent Bridge 处理这些事务。

Case 8: `cudaDeviceSynchronize()` / `cudaStreamSynchronize()`

场景：Host 代码等待 GPU 完成。
触发原因：若后续需要 CPU 读取 GPU 写入的数据（或 Peer GPU 通过 NVLink 访问），必须确保所有 die 的 L2 脏数据写回内存，并维护目录一致性状态。

三、内存管理与运行时 API 类

Case 9: `cudaMemcpy` / `cudaMemcpyAsync`（Device-to-Device & Host-to-Device）

场景：H2D 拷贝、D2D 拷贝（尤其跨 die 的隐式拷贝）。
触发原因 ：
- H2D：目标地址若在某 die 的 L2 中有旧缓存行，需先 Invalidate。
- D2D：若源数据在 Die 0 的 L2 中（脏），而目标在 Die 1 的地址空间，拷贝引擎必须要么直接从 Die 0 L2 读取，要么触发 Flush + 跨 die 传输。
- 有第三方分析指出 Blackwell 的 cudaMemcpy 可能与 L2 Directory Scan 存在竞态，暗示拷贝路径涉及目录一致性检查。

Case 10: `cudaMemset` / `cudaMemAdvise`

场景：对全局内存区域执行 memset，或修改 Unified Memory 的迁移策略（如 cudaMemAdviseSetReadMostly）。
触发原因 ：memset 必须使所有 die 的 L2 中对应地址范围失效；MemAdvise 改变页属性时，可能触发页迁移和 L2 逐出。

Case 11: Unified Memory (UM) 页迁移

场景：UM 页最初由 Die 0 的 SM 访问（页分配在 Die 0 的本地 HBM），随后 Die 1 频繁访问。
触发原因 ：
- 页迁移到 Die 1 的 HBM 前，需 Flush Die 0 L2 中的该页脏行；
- 迁移后，Die 0 L2 中该页的所有缓存行必须失效；
- 若页在多个 die 的 L2 中同时存在（如 Read-Only 共享阶段），迁移时需处理多副本一致性。

Case 12: MIG（Multi-Instance GPU）跨 Die 内存共享

场景：B200 支持 MIG，理论上可将一个 die 划分为一个实例。若更高阶配置允许实例间共享内存（或通过 NVLink 跨实例 P2P）。
触发原因：若两个 MIG 实例分别位于不同 die，但共享某些内存区域（如通过 CUDA IPC），则对这些共享区域的访问需要 L2 coherence。

四、外部 I/O 与互联类（Die-External Coherence）

Case 13: NVLink P2P（Peer-to-Peer）访问

场景：通过 NVLink 5 连接另一块 B200（或 H100/H200），远端 GPU 直接读取本地 B200 的 HBM。
触发原因 ：若目标地址缓存在本地 B200 的某个 die L2 中，NVLink P2P 请求需要：
- 本地 L2 将该脏行写回 HBM，或
- 通过 NVLink 直接从 L2 转发（若支持 Cache Stashing/Forwarding）；
- 涉及跨 GPU 的 L2 coherence，B200 作为 Responder 需维护其目录状态。

Case 14: GPUDirect RDMA / NVLink SHARP

场景：NIC（如 ConnectX-7/8）通过 PCIe 或 NVLink 直接读写 GPU HBM。
触发原因：NIC 发起的读请求若命中 L2 脏行，需要 L2 先写回；NIC 写之后，需 Invalidate GPU L2 中的旧副本。若数据分散在两个 die 的 L2 中，需同时处理两个 partition。

Case 15: NVLink-C2C（Grace CPU ↔ B200 GPU）

场景：GB200 Superchip 中，Grace CPU 通过 NVLink-C2C（900 GB/s）访问 GPU HBM，或 GPU 访问 CPU LPDDR5X 。
触发原因 ：这是完整硬件一致性 场景：
- CPU 读取 GPU HBM 地址 X：若 X 在 GPU Die 0/1 的 L2 中为脏，需写回并转发到 CPU LLC；
- CPU 写入 X：需 Invalidate 两个 GPU die 的 L2 中 X 的所有副本；
- 涉及跨器件的 Directory Protocol（Home Agent 在 GPU L2/Home Logic 中）。

Case 16: PCIe 边界一致性（CPU 通过 PCIe 访问）

场景：非 C2C 场景下，CPU 通过 PCIe 读取 GPU 内存（如 cudaMemcpyDtoH 的回环路径）。
触发原因：DMA 引擎读取前，需 Flush 两个 die 的 L2 脏行；CPU 写之后需 Invalidate GPU L2。

五、Cache 硬件管理与异常类

Case 17: L2 Cache 行逐出（Eviction / Replacement）

场景：L2 容量满（126 MB 总量，但每 partition 仅 ~32-64 MB），新数据需要分配缓存行。
触发原因：若被逐出的行（Victim Line）是 Dirty 状态，必须写回 HBM；若该地址在其他 die 的 L2 中有共享副本，目录需更新状态（如从 Shared 变为 Uncached）。

Case 18: ECC 纠错与 RAS 事件

场景：B200 支持完整 ECC。当 HBM 发生可纠正 ECC 错误，或 L2 出现 Tag/ Data 奇偶校验错误。
触发原因：RAS 引擎可能触发缓存行刷新、重映射或冗余切换，期间需要确保多 die 间该地址的一致性状态被正确重置。

Case 19: 热迁移 / 时钟门控 / Power Gating

场景：对某个 die 或 GPC 进行功耗管理（如动态关闭一个 die 的部分 SM）。
触发原因：若被关闭的单元 L2 中持有脏数据，必须在断电前 Flush 到另一 die 的 L2 或 HBM，并更新全局目录。

六、并发执行与编程模型类

Case 20: 重叠内核执行（Concurrent Kernels on Different Dies）

场景：CUDA 允许不同流中的内核并发执行。若 Stream A 在 Die 0 运行，Stream B 在 Die 1 运行，且它们访问重叠的全局内存区域。
触发原因 ：没有显式同步时，若发生写共享，硬件需保证最终一致性；若程序员使用 __threadfence() 或事件同步，则触发显式跨 die coherence。

Case 21: CUDA Graphs 与跨 Die 依赖

场景：CUDA Graph 中节点分布在不同 die 上，存在跨 die 的数据依赖边。
触发原因：Graph 执行引擎在调度跨 die 依赖时，可能插入隐式的 L2 Flush/Invalidate 以保证依赖节点的数据可见性。

Case 22: Tensor Memory (TMEM) 回写到 L2/HBM

场景：Blackwell 引入 TMEM（每 SM 256 KB，用于张量操作缓存）。TMEM 数据最终可能写回 L2 或 HBM。
触发原因：若 TMEM 数据写回全局内存，且该内存地址在其他 die 的 L2 中有缓存，需触发一致性更新使其他副本失效。

总结：一致性代价与优化建议

B200 的 NV-HBI 虽然提供了 10 TB/s 的 coherence 带宽，但跨 die 的 L2 coherence 并非零成本：

操作类型	本地 L2	跨 Die L2	备注
读命中	~150 ns	显著更高	需目录查询 + 可能的远程读取
写命中	低延迟	需获取所有权	涉及目录更新 + 失效广播
原子操作	最优	严重退化	可能退化为远程执行或 HBM 直通

优化原则：

利用 Locality：让数据尽量被同一 die 上的 SM 复用，避免跨 die 共享可写数据。
避免 False Sharing：同一缓存行（128 bytes ）若被两个 die 同时写入，会触发频繁的跨 die coherence ping-pong。
谨慎使用 Atomics：跨 die 原子代价极高，尽量通过数据分区（Data Parallel）或 SM-local aggregation 减少。
善用 Read-Only 数据：只读数据可在多个 die 的 L2 中安全共存（Shared 状态），不触发写传播。

BlackWell 双 计算 die 的 L2 一致性 cases