CHI Write 事务全流程解析

比姚明高一截2026-03-29 15:05

🧩 Immediate Write（立即写）事务全流程深度解析

这是 ARM CHI 协议的「立即写」时序图 ，核心是：Requester 直接发起写事务，将数据写入内存 / 缓存，并维护缓存一致性，适用于无需先读、直接写的场景（如写穿透、写回、设备寄存器写入）。

一、初始请求与角色

1. 发起方与事务类型

  • Requester 向 Home 发起以下立即写请求：
    • WriteNoSnpPtl/WriteNoSnpFull：无监听写（部分 / 完整），直接写 Subordinate（内存），不触发 snoop
    • WriteUniquePtl/WriteUniqueFull：独占写（部分 / 完整），需先回收其他节点副本，再写入
    • WriteUniqueFullStash：独占写 + Stash，写完后将数据推送到指定节点缓存
  • 核心特点：直接写数据，无需先读缓存行，适合写穿透、设备控制等场景。

2. 角色分工

表格

角色 作用
Requester 发起写请求，发送数据 payload
Home 目录仲裁节点，管理地址状态、路由事务、维护一致性
Subordinate 存储 / 内存侧节点（如 DDR 控制器），最终数据落地处
Snoope 其他缓存节点，可能持有旧副本，需被监听失效

二、逐场景流程解析

场景 1：DWT（Data Write Transfer，数据写传输）

流程
  1. Requester → Home：发送 WriteNoSnpPtl/Full 或 WriteUniquePtl/Full（带数据）
  2. Home → Subordinate：转发写请求（WriteNoSnpPtl/Full 或 WriteUniquePtl/Full，DoDWT=1）
  3. Subordinate → Home：返回 DBIDResp（数据接收收据，标识事务 ID）
  4. Subordinate → Home：返回 NCBWrData/WriteDataCancel（写完成 / 取消）
  5. Home → Requester：返回 Comp（事务完成响应）
场景与原因
  • 适用场景 ：
    • 无监听写（WriteNoSnp）：数据直接写内存，无其他缓存副本，无需 snoop
    • 独占写（WriteUnique）：需先回收其他节点副本，再写入内存
  • 设计原因 ：
    • DWT 是数据直写路径，Requester 直接将数据发给 Home，Home 转发给 Subordinate
    • DBIDResp 用于流控 / 事务追踪，保证写请求被可靠接收
    • NCBWrData 标识非缓存写完成，WriteDataCancel 处理写失败场景
    • 适合写穿透场景：数据直接落盘，不依赖缓存状态

场景 2：No DWT，no CompAck（无数据直写，无完成确认）

子场景 2a：Separate responses from the Home（Home 分离响应）
  1. Requester → Home：发送写请求（DoDWT=0，数据由其他路径传输）
  2. Home → Requester：返回 DBIDResp（收据）
  3. Home → Requester：返回 DBIDRespOrd（有序收据，保证事务顺序）
  4. Home → Requester：返回 Comp（事务完成）
子场景 2b：Combined response from the Home（Home 合并响应）
  1. Requester → Home：发送写请求（DoDWT=0）
  2. Home → Requester：返回 CompDBIDResp（合并收据 + 完成响应）
  3. Home → Requester：返回 NCBWrData/WriteDataCancel（写完成 / 取消）
场景与原因
  • 适用场景 ：
    • 数据已通过其他路径（如 DCT、缓存直传）传输，无需 Requester 再发数据
    • 无需 CompAck 确认，适合低可靠性要求、高并发写场景
  • 设计原因 ：
    • DoDWT=0 表示无数据直写，Requester 不发送数据 payload，仅发控制请求
    • 分离 / 合并响应是协议对控制流与数据流解耦的优化
    • 适合写回缓存场景：数据先在缓存间传输，最后由 Home 统一落盘
可选分支：TagOp == Match
  • 当 TagOp == Match 时，Home 会先做标签匹配校验，确认地址 / 事务合法性，再返回响应
  • 场景：安全校验、地址翻译、事务去重，避免非法写操作

场景 3：No DWT，with CompAck（无数据直写，带完成确认）

子场景 3a：Separate responses from the Home（Home 分离响应）
  1. Requester → Home：发送写请求（DoDWT=0）
  2. Home → Requester：返回 DBIDResp（收据）
  3. Home → Requester：返回 DBIDRespOrd（有序收据）
  4. Home → Requester：返回 Comp（事务完成）
  5. Requester → Home：返回 CompAck（完成确认）
子场景 3b：Combined response from the Home（Home 合并响应）
  1. Requester → Home：发送写请求（DoDWT=0）
  2. Home → Requester：返回 CompDBIDResp（合并收据 + 完成）
  3. Requester → Home：返回 CompAck（完成确认）
  4. Home → Requester：返回 NCBWrData/WriteDataCancel（写完成 / 取消）
  5. Requester → Home：返回 NCBWrDataCompAck（写完成确认）
场景与原因
  • 适用场景 ：
    • 高可靠性要求的写事务（如设备寄存器写入、关键数据更新）
    • 需要确认 Requester 已收到事务完成信号，避免状态机死锁
  • 设计原因 ：
    • CompAck 是事务可靠收尾机制，保证 Home 与 Requester 状态同步
    • 分离 / 合并响应适配不同带宽 / 时序需求
    • 适合安全关键系统：必须确认写操作落地，否则触发重试
子场景 3c：Separate responses from the Subordinate（Subordinate 分离响应）
  1. Home → Subordinate：转发写请求（DoDWT=0）
  2. Subordinate → Home：返回 DBIDResp（收据）
  3. Subordinate → Home：返回 CompDBIDResp（合并收据 + 完成）
  4. Subordinate → Home：返回 NCBWrData/WriteDataCancel（写完成 / 取消）
场景与原因
  • 适用场景 ：
    • Subordinate 直接处理写事务，Home 仅做路由转发
    • 内存侧直接完成写操作，减少 Home 中转开销
  • 设计原因 ：
    • 典型 DMT（Direct Memory Transfer） 写路径，数据直接从 Requester → Subordinate
    • 提升写吞吐量，适合高并发内存写场景
可选分支：TagOp == Match
  • 同场景 2，用于标签匹配校验，保证写操作合法性

三、核心设计意图总结

  1. 立即写核心 ：无需先读缓存行，直接发起写操作，适合写穿透、设备控制等一次性写场景。
  2. 路径灵活性 ：
    • DWT：Requester 直写数据到 Home/Subordinate，适合写穿透
    • No DWT：数据由其他路径传输，仅发控制请求，适合写回缓存
  3. 一致性保障 ：
    • WriteUnique 事务会触发 snoop 监听，回收其他节点副本，保证独占写权限
    • WriteNoSnp 事务无 snoop，适合无缓存副本的内存写场景
  4. 可靠性与性能权衡 ：
    • CompAck 可选：高可靠场景用，低延迟场景可省略
    • 分离 / 合并响应：适配不同带宽 / 时序需求，优化并发性能
  5. 流控与排序 ：
    • DBIDResp/DBIDRespOrd 用于流控和事务排序，保证写操作有序完成
    • TagOp == Match 用于安全校验，避免非法写操作

四、一句话记忆

Immediate Write = 直接写数据，支持直写 / 间接写、可靠 / 快速模式，通过 snoop 保证一致性，是内存 / 设备写操作的核心路径。

📌 关键场景速查表

表格

场景 核心特征 典型用途
DWT Requester 直写数据到 Home/Subordinate 写穿透、设备寄存器写入
No DWT 仅发控制请求，数据由其他路径传输 写回缓存、缓存间数据搬运
No CompAck 无完成确认，低延迟 高并发普通数据写
With CompAck 带完成确认，高可靠 关键数据、设备控制写

🧩 Write Zero（零写）事务全流程深度解析

这是 ARM CHI 协议的「零写」时序图 ，核心是：Requester 发起写请求，将目标地址范围的数据置为全 0，无需携带实际数据 payload，是一种高效的内存初始化 / 清零操作。

一、初始请求与核心概念

1. 发起方与事务类型

  • Requester 向 Home 发起两类零写请求：
    • WriteNoSnpZero：无监听零写，直接清零内存，不触发对其他缓存节点的 snoop 操作
    • WriteUniqueZero：独占零写，先回收其他节点的缓存副本，再执行清零
  • 核心特点：不携带数据 payload，仅通过指令告知 Home/Subordinate "将地址范围置 0"，大幅节省带宽。

2. 角色分工

表格

角色 作用
Requester 发起零写请求，仅发送控制信息（地址、长度、类型）
Home 目录仲裁节点，管理地址状态、路由事务、维护缓存一致性
Subordinate 存储 / 内存侧节点（如 DDR 控制器），执行实际的清零操作

二、逐场景流程解析

场景 1：Separate response from Home（Home 分离响应）

流程
  1. 请求发起 ：Requester → Home：发送 WriteNoSnpZero 或 WriteUniqueZero（仅控制信息，无数据）
  2. 收据响应 ：Home → Requester：返回 DBIDResp + DBIDRespOrd
    • DBIDResp：数据接收收据，确认事务已被受理，分配事务 ID
    • DBIDRespOrd：有序收据，保证事务按发起顺序完成（强序语义）
  3. 完成响应 ：Home → Requester：返回 Comp（事务完成确认）
场景与原因
  • 适用场景 ：
    • 需要严格事务排序的场景（如设备寄存器初始化、多线程共享内存清零）
    • 协议实现要求分离 "收据" 和 "完成" 两个阶段，便于流控和状态机管理
  • 设计原因 ：
    • 分离响应让 Requester 能更早感知事务受理状态，优化并发流控
    • DBIDRespOrd 保证零写操作的全局有序性，避免乱序导致的数据不一致
    • 无数据 payload，带宽占用极低，适合大块内存初始化

场景 2：Combined response from Home（Home 合并响应）

流程
  1. 请求发起 ：Requester → Home：发送 WriteNoSnpZero 或 WriteUniqueZero
  2. 合并响应 ：Home → Requester：返回 CompDBIDResp
    • 这是一个合并消息 ，同时包含：
      • DBIDResp：事务收据
      • Comp：事务完成确认
场景与原因
  • 适用场景 ：
    • 对事务排序要求较低的场景（如普通内存清零、非关键数据初始化）
    • 追求低延迟、少消息交互的高性能实现
  • 设计原因 ：
    • 合并消息将 "收据" 和 "完成" 合为一条，减少协议交互次数，降低延迟
    • 适合弱序内存模型，无需严格保证事务完成顺序
    • 依然保持零写 "无数据 payload" 的带宽优势

三、两类零写请求的差异与适用场景

1. WriteNoSnpZero（无监听零写）

  • 流程：Home 直接将请求转发给 Subordinate，Subordinate 执行清零操作，不向其他缓存节点发送 snoop
  • 适用场景 ：
    • 目标地址无任何缓存副本（如刚分配的物理页、未被缓存的设备内存）
    • 允许其他节点保留旧数据（如一次性临时缓冲区清零）
  • 优势：无 snoop 广播，带宽占用极低，延迟最低
  • 风险：若其他节点缓存了旧数据，会出现缓存不一致，需上层软件保证

2. WriteUniqueZero（独占零写）

  • 流程 ：Home 先向所有持有该地址缓存副本的节点发送 SnpInvalidate 监听，回收并失效所有副本，再通知 Subordinate 执行清零
  • 适用场景 ：
    • 目标地址存在其他缓存副本（如多线程共享内存、已被缓存的堆内存）
    • 要求清零后数据全局一致（如安全敏感数据销毁、临界区初始化）
  • 优势：保证缓存一致性，清零后所有节点都能看到全 0 数据
  • 代价：需要 snoop 广播，延迟稍高，但依然无数据 payload，带宽效率远高于普通写

四、设计意图与核心价值

1. 带宽优化

  • 零写事务不携带任何数据 payload，仅发送控制消息，相比普通写事务（需携带全缓存行数据），带宽占用减少 90% 以上
  • 特别适合大块内存初始化（如页面清零、缓冲区重置）

2. 一致性保障

  • WriteUniqueZero 通过 snoop 监听机制，保证清零操作对所有缓存节点可见，避免 "旧数据残留"
  • WriteNoSnpZero 提供轻量级选项，适合无缓存场景，平衡性能与一致性

3. 事务灵活性

  • 分离 / 合并响应两种模式，适配不同时序 / 流控需求：
    • 分离响应：强序、高可靠、便于流控
    • 合并响应：低延迟、少交互、高性能
  • 与普通写事务复用 DBIDResp/Comp 等消息，降低协议实现复杂度

五、一句话记忆

Write Zero = 不带数据的高效清零操作 ，通过 WriteNoSnpZero/WriteUniqueZero 平衡性能与一致性，分离 / 合并响应适配不同场景，是内存初始化的最优协议选择。

📌 关键场景速查表

表格

事务类型 一致性 带宽占用 延迟 典型用途
WriteNoSnpZero 无（依赖上层） 极低 最低 无缓存内存初始化、临时缓冲区清零
WriteUniqueZero 强一致 低（无数据） 稍高 多线程共享内存、安全敏感数据销毁
分离响应 强序 中等 稍高 设备寄存器、临界区初始化
合并响应 弱序 低 最低 普通内存页、非关键数据清零

🧩 CopyBack Write（回写 / 驱逐写）事务全流程深度解析

这是 ARM CHI 协议的「回写 / 驱逐写」时序图 ，核心是：Requester 将本地缓存中被修改（脏）或要驱逐的缓存行，写回至 Home / 内存，是缓存写回机制的核心实现。

一、初始请求与核心概念

1. 发起方与事务类型

Requester 向 Home 发起以下回写 / 驱逐请求：

  • WriteBackPtl：部分回写（仅写回缓存行中被修改的部分数据）
  • WriteBackFull：完整回写（写回整个缓存行数据）
  • WriteCleanFull：干净行回写（写回未被修改的干净缓存行，通常用于缓存驱逐）
  • WriteEvictFull：完整驱逐写（驱逐缓存行并写回数据，之后 Requester 不再持有该缓存行）
  • WriteEvictOrEvict：驱逐或驱逐（仅驱逐缓存行，若为脏行则自动触发写回；若为干净行则直接丢弃）

核心特点：

  • 由 Requester 主动发起，目的是将本地缓存数据同步到内存 或释放缓存资源
  • 是缓存一致性中「脏数据回写」的关键路径，保证内存数据最终与缓存一致

2. 角色分工

表格

角色 作用
Requester 发起回写 / 驱逐请求，携带脏数据 payload；执行缓存行驱逐
Home 接收回写数据，更新目录状态，转发数据到内存（Subordinate）
Subordinate 存储 / 内存侧节点，最终落地回写数据

二、逐场景流程解析

场景 1：Combined response from Home（Home 合并响应）

流程
  1. 请求发起 ：Requester → Home：发送 WriteBackPtl/WriteBackFull/WriteCleanFull/WriteEvictFull（携带回写数据 payload）
  2. 合并收据 + 完成响应 ：Home → Requester：返回 CompDBIDResp
    • 这是一个合并消息 ，同时包含：
      • DBIDResp：事务收据，确认已受理回写请求并分配事务 ID
      • Comp：事务完成确认，告知 Requester 回写请求已被 Home 接收
  3. 数据回写 ：Requester → Home：发送 CopyBackWrData（实际回写数据 payload）
    • 若为 WriteBackPtl：仅发送被修改的部分数据
    • 若为 WriteBackFull/WriteCleanFull/WriteEvictFull：发送完整缓存行数据
场景与原因
  • 适用场景 ：
    • 缓存脏行需要写回内存（如缓存驱逐、容量不足、锁释放等）
    • 干净缓存行需要被驱逐（如缓存替换策略触发）
    • 追求低延迟、少交互的高性能实现
  • 设计原因 ：
    • CompDBIDResp 合并了收据和完成信号，减少协议交互次数，降低延迟
    • 分离控制流与数据流：先确认事务受理，再传输数据，避免带宽浪费
    • 支持部分回写（WriteBackPtl），大幅优化带宽效率（仅传输修改部分）
    • 干净行回写（WriteCleanFull）允许 Requester 释放缓存资源，同时保证内存数据一致

场景 2：For WriteEvictOrEvict Only（仅针对 WriteEvictOrEvict 事务）

流程
  1. 请求发起 ：Requester → Home：发送 WriteEvictOrEvict（仅控制信息，若为脏行则隐含数据回写）
  2. 完成响应 ：Home → Requester：返回 Comp（事务完成确认）
  3. 完成确认 ：Requester → Home：返回 CompAck（完成确认，告知 Home 已完成缓存行驱逐）
场景与原因
  • 适用场景 ：
    • Requester 要彻底驱逐缓存行，无论其是否为脏
    • 脏行会自动触发写回，干净行直接丢弃
    • 适合缓存替换、进程退出、地址空间释放等场景
  • 设计原因 ：
    • WriteEvictOrEvict 是轻量级驱逐事务，无需显式携带数据（脏行自动回写）
    • CompAck 是可靠收尾机制，保证 Requester 已完成驱逐，Home 可安全更新目录状态
    • 避免了显式数据传输，适合干净行驱逐场景，带宽效率极高
    • 保证驱逐后 Requester 不再持有该缓存行，避免 stale 数据

三、各类回写 / 驱逐请求的差异与适用场景

表格

事务类型 数据类型 缓存行为 典型用途
WriteBackPtl 部分脏数据 保留缓存行（仍可访问） 部分字段修改后写回，优化带宽
WriteBackFull 完整脏数据 保留缓存行（仍可访问） 完整缓存行修改后写回
WriteCleanFull 完整干净数据 驱逐缓存行（不再持有） 干净行驱逐，释放缓存资源
WriteEvictFull 完整脏 / 干净数据 驱逐缓存行（不再持有） 脏行驱逐 + 写回，干净行驱逐
WriteEvictOrEvict 无（脏行自动回写） 驱逐缓存行（不再持有） 通用缓存驱逐，简化协议交互

四、设计意图与核心价值

1. 缓存一致性保障

  • 回写事务是 ** 写回缓存（Write-Back Cache）** 的核心，保证脏数据最终被同步到内存
  • 驱逐事务保证缓存资源被高效释放，避免缓存污染和 stale 数据
  • WriteUnique 等读事务依赖回写机制，确保能获取最新数据

2. 带宽优化

  • 支持部分回写（WriteBackPtl），仅传输被修改的部分数据，带宽效率远高于完整回写
  • WriteEvictOrEvict 对干净行无需传输数据，进一步节省带宽
  • 分离控制流与数据流，避免无效数据传输

3. 事务灵活性

  • 合并响应（CompDBIDResp）优化延迟，适合高性能场景
  • CompAck 保证驱逐事务的可靠收尾，适合高可靠系统
  • 覆盖从「部分回写」到「彻底驱逐」的全场景缓存管理需求

4. 协议复用

  • 复用 DBIDResp/Comp/CompAck 等基础消息，与其他写事务保持一致，降低实现复杂度
  • 与读事务的 CompAck 机制对齐，统一事务收尾逻辑

五、一句话记忆

CopyBack Write = 缓存脏行 / 驱逐行的回写机制，通过部分 / 完整回写优化带宽，结合可靠驱逐事务保证缓存资源释放，是写回缓存与缓存一致性的核心支柱。

📌 关键场景速查表

表格

场景 核心特征 典型用途
脏行回写 携带脏数据，保留缓存行 缓存容量不足、锁释放、事务提交
干净行驱逐 无脏数据，释放缓存行 缓存替换、地址空间回收
彻底驱逐 自动处理脏 / 干净行，无数据传输 进程退出、缓存清空
合并响应 少交互、低延迟 高性能 CPU 缓存系统
驱逐确认 高可靠、状态同步 安全关键系统、虚拟化场景

🧩 Combined Immediate Write + CMO 事务全流程深度解析

这是 ARM CHI 协议的「立即写 + 缓存管理操作（CMO）」复合事务时序图 ，核心是：在执行写操作的同时，附带完成缓存行的清理 / 失效 / 共享等管理操作，实现 "写数据 + 维护缓存一致性" 的原子化处理，适合需要精细控制缓存状态的场景。

一、初始请求与核心概念

1. 发起方与事务类型

Requester 向 Home 发起写 + CMO 复合请求，核心类型包括：

  • 无监听类 ：
    • WriteNoSnpPtlCleanInv：无监听部分写 + 清理失效
    • WriteNoSnpFullCleanInv：无监听完整写 + 清理失效
    • WriteNoSnpPtlCleanSh：无监听部分写 + 清理共享
    • WriteNoSnpFullCleanSh：无监听完整写 + 清理共享
  • 独占类 ：
    • WriteUniquePtlCleanSh：独占部分写 + 清理共享
    • WriteUniqueFullCleanSh：独占完整写 + 清理共享

CMO（Cache Maintenance Operation）：缓存管理操作，包括：

  • Clean：将缓存脏数据写回内存，但保留缓存行
  • Invalidate：失效缓存行（后续访问需重新从内存读取）
  • CleanShare：写回脏数据并将缓存行置为共享状态
  • CleanInvalidate：写回脏数据后失效缓存行

2. 角色分工

表格

角色 作用
Requester 发起写 + CMO 复合请求，携带数据 payload
Home 目录仲裁节点，协调写事务、CMO 与缓存一致性
Subordinate 存储 / 内存侧节点，接收写数据并落地

二、逐场景流程解析

场景 1：Combined Write with DWT to Subordinate（带 DWT 的合并写）

流程
  1. 请求发起 ：Requester → Home：发送带 CMO 的写请求（如 WriteNoSnpFullCleanInv）Home → Subordinate：转发相同请求（DoDWT=1，表示 Requester 将直接发送数据）
  2. 收据响应 ：Subordinate → Home：返回 DBIDResp（事务收据，确认受理）
  3. 数据传输与写完成 ：Requester → Subordinate：发送 NCBWrData（非缓存写数据）或 WriteDataCancel（写取消）Subordinate → Home：返回写完成信号
  4. 事务完成与 CMO 确认 ：Home → Requester：返回 Comp（写事务完成）Home → Requester：返回 CompCMO（CMO 操作完成确认）或 Subordinate → Home：返回 Comp，Home 再向 Requester 发送 Comp + CompCMO
场景与原因
  • 适用场景 ：
    • 需要 ** 原子化完成 "写数据 + 缓存清理 / 失效"** 的场景（如设备寄存器同步、安全数据销毁）
    • 无监听写（WriteNoSnp）：目标地址无其他缓存副本，直接写内存
    • 独占写（WriteUnique）：先回收其他缓存副本，再写 + CMO
  • 设计原因 ：
    • DWT（Data Write Transfer）：Requester 直接向 Subordinate 发送数据，减少 Home 中转开销
    • 合并写 + CMO：避免两次独立事务，降低延迟，保证原子性
    • CompCMO：显式确认 CMO 操作完成，避免 Requester 提前假设缓存状态

场景 2：Non-combined write with DWT to Subordinate（带 DWT 的非合并写）

流程
  1. 请求发起 ：Requester → Home：发送纯写请求（WriteNoSnpPtl/WriteNoSnpFull，DoDWT=1）Home → Subordinate：转发写请求
  2. 收据响应 ：Subordinate → Home：返回 DBIDResp
  3. 数据传输与写完成 ：Requester → Subordinate：发送 NCBWrData/WriteDataCancelSubordinate → Home：返回写完成
  4. 事务完成与 CMO 确认 ：Home → Requester：返回 Comp（写完成）Home → Requester：返回 CompCMO（CMO 完成）
场景与原因
  • 适用场景 ：
    • 写操作与 CMO 操作分步执行，但仍在一个事务内
    • 协议实现需要分离写与 CMO 的状态机
  • 设计原因 ：
    • 非合并模式更便于调试和状态机拆解
    • 保留 DWT 直写优势，同时保证 CMO 最终完成
    • 适合对时序不敏感、但需要清晰事务阶段的系统

场景 3：No DWT（无数据直写）

子场景 3a：Separate/combined responses from Home（Home 分离 / 合并响应）
3a1. Separate responses
  1. Requester → Home：发送写 + CMO 请求（DoDWT=0，数据由其他路径传输）
  2. Home → Requester：返回 DBIDResp + DBIDRespOrd（收据 + 有序保证）
  3. Home → Requester：返回 Comp（写事务完成）
3a2. Combined response
  1. Requester → Home：发送写 + CMO 请求（DoDWT=0）
  2. Home → Requester：返回 CompDBIDResp（合并收据 + 完成）
子场景 3b：写完成与 CompAck 分支
3b1. No CompAck required
  • Subordinate → Home：发送 NCBWrData/WriteDataCancel（写完成）
  • 无需 Requester 回复 CompAck
3b2. CompAck required
  • 3b2a. Separate response ：
    1. Subordinate → Requester：发送 NCBWrData/WriteDataCancel
    2. Requester → Home：返回 CompAck（确认写完成）
  • 3b2b. Combined response ：
    1. Requester → Home：返回 NCBWrDataCompAck（合并写完成 + 确认）
最终：CMO 完成确认
  • Home → Requester：返回 CompCMO（所有 CMO 操作完成）
场景与原因
  • 适用场景 ：
    • 数据已通过其他路径（如 DCT、缓存直传）传输，Requester 无需再发数据
    • 高可靠性场景：需要 CompAck 确认 Requester 已感知写完成
    • 强序事务：DBIDRespOrd 保证写 + CMO 按发起顺序执行
  • 设计原因 ：
    • No DWT：优化带宽，避免重复数据传输
    • 分离 / 合并响应：适配不同时序 / 流控需求
    • CompAck：保证事务可靠收尾，避免状态机死锁
    • CompCMO：确保 CMO 操作全局可见，缓存状态最终一致

三、核心设计意图与价值

1. 原子化操作：写 + CMO 一体化

  • 将 "写数据" 与 "缓存管理" 合并为一个事务，避免中间状态导致的数据不一致
  • 例如：WriteNoSnpFullCleanInv 原子完成 "写内存 → 清理脏数据 → 失效缓存行"，保证后续访问只能从内存读取最新数据

2. 性能与带宽优化

  • DWT 模式：Requester 直写 Subordinate，减少 Home 中转
  • No DWT 模式：复用已有数据传输，节省带宽
  • 部分写（Ptl）：仅传输修改部分，进一步优化带宽

3. 一致性与安全保障

  • CMO 操作 ：精细控制缓存状态，满足安全 / 一致性需求：
    • CleanInv：写回并失效，适合数据销毁、安全清零
    • CleanSh：写回并置为共享，适合多线程读场景
  • CompCMO 显式确认：保证 Requester 知道缓存状态已变更，避免 stale 数据

4. 灵活性与可扩展性

  • 支持分离 / 合并响应、CompAck 可选等分支，适配不同性能 / 可靠性需求
  • 兼容无监听 / 独占写，覆盖从设备访问到多核心共享内存的全场景

四、一句话记忆

Combined Immediate Write + CMO = 原子化 "写数据 + 缓存管理"，通过 DWT/No DWT 优化带宽，用 CompCMO 保证缓存状态最终一致，是兼顾性能、一致性与安全的高级事务模式。

📌 关键场景速查表

场景 核心特征 典型用途
带 DWT 合并写 直写 Subordinate，原子写 + CMO 设备寄存器同步、安全数据销毁
No DWT 分离响应 无数据传输，强序 + 高可靠 多线程共享内存、缓存一致性维护
带 CompAck 事务可靠收尾 安全关键系统、虚拟化场景
CleanInv CMO 写回 + 失效缓存 数据销毁、页面回收
CleanSh CMO 写回 + 共享状态 多线程读优化、缓存预热

🧩 Combined Immediate Write + Persist CMO 事务全流程深度解析

这是 ARM CHI 协议的「立即写 + 持久化缓存管理操作（Persist CMO）」复合事务时序图 ，核心是在写数据的同时，完成缓存清理 / 共享 + 数据持久化（保证数据落盘到非易失性存储），是满足持久内存、存储级内存（SCM）和数据持久化需求的关键事务。

一、初始请求与核心概念

1. 发起方与事务类型

Requester 向 Home 发起写 + Persist CMO 复合请求，核心类型包括：

  • 无监听持久化类 ：
    • WriteNoSnpPtlCleanShPerSep：无监听部分写 + 清理共享 + 持久化（分离完成）
    • WriteNoSnpFullCleanShPerSep：无监听完整写 + 清理共享 + 持久化（分离完成）
  • 独占持久化类 ：
    • WriteUniquePtlCleanShPerSep：独占部分写 + 清理共享 + 持久化（分离完成）
    • WriteUniqueFullCleanShPerSep：独占完整写 + 清理共享 + 持久化（分离完成）
  • 纯持久化 CMO 类 ：
    • CleanSharedPersistSep：清理共享 + 持久化（仅 CMO，无写操作）

Persist（持久化） ：确保数据被写入非易失性存储（如 NVDIMM、SSD），保证掉电后数据不丢失。CMO（Cache Maintenance Operation）：

  • CleanSh：将缓存脏数据写回内存，并将缓存行置为共享状态
  • Persist：触发数据持久化到非易失性存储，保证数据落地

2. 角色分工

表格

角色 作用
Requester 发起写 + Persist CMO 复合请求，携带数据 payload；接收持久化完成确认
Home 目录仲裁节点，协调写事务、CMO、持久化与缓存一致性
Subordinate 存储 / 内存侧节点，接收写数据、执行持久化操作、落地到非易失性存储

二、逐场景流程解析

场景 1：Combined Write with DWT to Subordinate（带 DWT 的合并写）

流程
  1. 请求发起 ：Requester → Home：发送带 Persist CMO 的写请求（如 WriteNoSnpFullCleanShPerSep）Home → Subordinate：转发相同请求（DoDWT=1，表示 Requester 将直接发送数据）
  2. 收据响应 ：Subordinate → Home：返回 DBIDResp（事务收据，确认受理）
  3. 数据传输与写完成 ：Requester → Subordinate：发送 NCBWrData（非缓存写数据）或 WriteDataCancel（写取消）Subordinate → Home：返回写完成信号
  4. 事务完成与 CMO 确认 ：Home → Requester：返回 Comp（写事务完成）Home → Requester：返回 CompCMO（CMO 操作完成确认）
  5. 持久化确认 ：Home → Requester：返回 Persist（数据持久化完成确认，保证已落盘）
场景与原因
  • 适用场景 ：
    • 需要 ** 原子化完成 "写数据 + 缓存清理 + 持久化落盘"** 的场景（如持久内存操作、数据库事务提交、关键数据持久化）
    • 无监听写（WriteNoSnp）：目标地址无其他缓存副本，直接写内存 + 持久化
  • 设计原因 ：
    • DWT（Data Write Transfer）：Requester 直写 Subordinate，减少 Home 中转开销，提升写 + 持久化吞吐量
    • 合并写 + CMO+Persist：避免多次事务交互，保证原子性，降低延迟
    • CompCMO + Persist：显式确认缓存状态变更与数据落盘，满足持久化语义（掉电不丢数据）

场景 2：Non-combined write with DWT to Subordinate（带 DWT 的非合并写）

流程
  1. 请求发起 ：Requester → Home：发送纯写请求（WriteNoSnpPtl/WriteNoSnpFull，DoDWT=1）Home → Subordinate：转发写请求
  2. 收据响应 ：Subordinate → Home：返回 DBIDResp
  3. 数据传输与写完成 ：Requester → Subordinate：发送 NCBWrData/WriteDataCancelSubordinate → Home：返回写完成
  4. 事务完成与 CMO 确认 ：Home → Requester：返回 Comp（写完成）Home → Requester：返回 CompCMO（CMO 完成）
  5. 持久化确认 ：Home → Requester：返回 Persist（持久化完成）
场景与原因
  • 适用场景 ：
    • 写操作与 CMO / 持久化分步执行，但仍在一个事务内
    • 协议实现需要清晰拆分写、CMO、持久化的状态机
  • 设计原因 ：
    • 非合并模式便于调试和状态机拆解，适合复杂持久化逻辑
    • 保留 DWT 直写优势，同时保证持久化语义
    • 适合对时序不敏感、但需要分步确认的系统

场景 2a：Persist CMO to Subordinate（纯持久化 CMO）

子场景 2a1：Separate responses from Subordinate
  1. Home → Subordinate：发送 CleanSharedPersistSep（仅持久化 CMO）
  2. Subordinate → Home：返回 CompCMO（CMO 完成）
  3. Subordinate → Home：返回 Persist（持久化完成）
  4. Home → Requester：返回 CompCMO + Persist
子场景 2a2：Combined response from Subordinate
  1. Home → Subordinate：发送 CleanSharedPersistSep
  2. Subordinate → Home：返回 CompCMOPersist（合并 CMO 完成 + 持久化完成）
  3. Home → Requester：返回 CompCMO + Persist
场景与原因
  • 适用场景 ：
    • 仅需要对已有脏数据执行缓存清理 + 持久化（如后台数据刷盘、脏页回写）
    • 无新数据写入，仅做持久化管理
  • 设计原因 ：
    • 纯 CMO 路径：避免无效数据传输，专注于持久化逻辑
    • 分离 / 合并响应：适配不同时序 / 性能需求
    • 保证数据落盘，满足持久内存的 ACID 语义

场景 3：No DWT（无数据直写）

子场景 3a：Separate/combined responses from Home（Home 分离 / 合并响应）
3a1. Separate responses
  1. Requester → Home：发送写 + Persist CMO 请求（DoDWT=0，数据由其他路径传输）
  2. Home → Requester：返回 DBIDResp + DBIDRespOrd（收据 + 有序保证）
  3. Home → Requester：返回 Comp（写事务完成）
3a2. Combined response
  1. Requester → Home：发送写 + Persist CMO 请求（DoDWT=0）
  2. Home → Requester：返回 CompDBIDResp（合并收据 + 完成）
子场景 3b：写完成与 CompAck 分支
3b1. No CompAck required
  • Subordinate → Home：发送 NCBWrData/WriteDataCancel（写完成）
  • 无需 Requester 回复 CompAck
3b2. CompAck required
  • 3b2a. Separate response ：
    1. Subordinate → Requester：发送 NCBWrData/WriteDataCancel
    2. Requester → Home：返回 CompAck（确认写完成）
  • 3b2b. Combined response ：
    1. Requester → Home：返回 NCBWrDataCompAck（合并写完成 + 确认）
子场景 3c：All CMO / Only CMO 分支
3c1. Combined write without DWT to Subordinate
  • 同场景 1，但 DoDWT=0，数据由其他路径传输
3c2. All CMO responses from Home
  • Home → Requester：返回 CompCMO（CMO 完成）
  • Home → Requester：返回 Persist（持久化完成）
3c3. Only CMO transaction to Subordinate
  • Home → Subordinate：发送纯 Persist CMO
  • Subordinate → Home：返回 CompCMO + Persist
  • Home → Requester：返回 CompCMO + Persist
场景与原因
  • 适用场景 ：
    • 数据已通过其他路径（如 DCT、缓存直传）传输，Requester 无需再发数据
    • 高可靠性场景：需要 CompAck 确认 Requester 已感知写完成
    • 纯持久化场景：仅执行 CMO + 持久化，无新数据写入
  • 设计原因 ：
    • No DWT：优化带宽，避免重复数据传输
    • 分离 / 合并响应：适配不同时序 / 流控需求
    • CompAck：保证事务可靠收尾，避免状态机死锁
    • CompCMO + Persist：确保缓存状态变更与数据落盘全局可见，满足持久化语义

三、核心设计意图与价值

1. 原子化持久化：写 + CMO + Persist 一体化

  • 将 "写数据 → 缓存清理 → 持久化落盘" 合并为一个事务，保证原子性，避免中间状态导致数据丢失或不一致
  • 例如：WriteNoSnpFullCleanShPerSep 原子完成 "写内存 → 清理脏数据 → 置为共享 → 持久化落盘"，保证掉电后数据不丢失

2. 性能与带宽优化

  • DWT 模式：Requester 直写 Subordinate，减少 Home 中转开销，提升持久化吞吐量
  • No DWT 模式：复用已有数据传输，节省带宽
  • 部分写（Ptl）：仅传输修改部分，进一步优化带宽

3. 持久化语义保障

  • Persist 消息：显式确认数据已落盘到非易失性存储，满足持久内存、数据库等对 "掉电不丢数据" 的强需求
  • CompCMO 消息：保证缓存状态已变更，避免 stale 数据读取
  • 分离 / 合并响应：适配不同性能 / 可靠性需求，兼顾低延迟与持久化语义

4. 灵活性与可扩展性

  • 支持纯写、纯 CMO、写 + CMO+Persist 等多种组合，覆盖从普通内存到持久内存的全场景
  • 兼容无监听 / 独占写，适配多核共享内存与设备访问场景
  • 分步确认机制（Comp/CompCMO/Persist）便于调试和错误恢复

四、一句话记忆

Combined Immediate Write + Persist CMO = 原子化 "写数据 + 缓存管理 + 持久化落盘" ，通过 DWT/No DWT 优化带宽，用 CompCMO+Persist 保证缓存状态与数据持久化，是持久内存与关键业务数据持久化的核心事务模式。

📌 关键场景速查表

表格

场景 核心特征 典型用途
带 DWT 合并写 直写 Subordinate，原子写 + CMO+Persist 持久内存操作、数据库事务提交
No DWT 分离响应 无数据传输，强序 + 高可靠 多线程共享内存、后台数据刷盘
纯 Persist CMO 仅清理 + 持久化，无写操作 脏页回写、数据持久化
带 CompAck 事务可靠收尾 安全关键系统、金融交易
Persist 确认 保证数据落盘 持久内存、SSD 存储

🧩 Combined CopyBack Write + CMO 事务全流程深度解析

这是 ARM CHI 协议的「回写写 + 缓存管理操作（CMO）/ 持久化」复合事务时序图 ，核心是：Requester 在将本地脏缓存行回写的同时，附带完成缓存清理 / 失效 / 共享，甚至持久化落盘，是缓存写回机制与一致性管理、持久化语义结合的关键实现。

一、初始请求与核心概念

1. 发起方与事务类型

Requester 向 Home 发起回写 + CMO 复合请求，核心类型分为两类：

（1）无持久化场景（Without Persist）
  • WriteBackFullCleanInv：完整脏行回写 + 清理失效（写回后失效缓存行）
  • WriteBackFullCleanSh：完整脏行回写 + 清理共享（写回后置为共享状态）
  • WriteCleanFullCleanSh：完整干净行回写 + 清理共享（驱逐干净行并置为共享）
（2）带持久化场景（With Persist）
  • WriteBackFullCleanShPerSep：完整脏行回写 + 清理共享 + 持久化（分离完成）
  • WriteCleanFullCleanShPerSep：完整干净行回写 + 清理共享 + 持久化（分离完成）
  • 纯持久化 CMO：CleanSharedPersistSep（仅清理共享 + 持久化，无回写）

CopyBack Write ：将本地缓存中修改过（脏）或要驱逐的缓存行写回内存，释放缓存资源。CMO（Cache Maintenance Operation）：

  • Clean：将缓存脏数据写回内存，保留缓存行
  • Invalidate：失效缓存行（后续访问需重新读取）
  • CleanSh：写回脏数据并将缓存行置为共享状态
  • CleanInv：写回脏数据后失效缓存行Persist：确保数据落盘到非易失性存储（如 NVDIMM、SSD），保证掉电不丢失。

2. 角色分工

表格

角色 作用
Requester 发起回写 + CMO 请求，携带脏数据；执行缓存行状态变更 / 驱逐
Home 接收回写数据，更新目录状态，协调 CMO / 持久化，转发到 Subordinate
Subordinate 存储 / 内存侧节点，接收回写数据、执行持久化、落地到非易失性存储

二、逐场景流程解析

场景 1：Without Persist（无持久化的回写 + CMO）

流程
  1. 请求发起 ：Requester → Home：发送回写 + CMO 请求（如 WriteBackFullCleanInv）
  2. 合并收据 + 完成响应 ：Home → Requester：返回 CompDBIDResp（合并事务收据 + 写完成确认）
  3. 数据回写 ：Requester → Home：发送 CopyBackWrData（实际回写的脏数据 payload）
  4. CMO 完成确认 ：Home → Requester：返回 CompCMO（缓存管理操作完成确认）
场景与原因
  • 适用场景 ：
    • 缓存脏行需要写回内存，同时调整缓存状态（失效 / 共享）
    • 干净缓存行需要被驱逐，同时置为共享状态
    • 普通内存场景，无需持久化落盘
  • 设计原因 ：
    • 原子化 "回写数据 + 缓存状态管理"，避免中间状态导致一致性问题
    • CompDBIDResp 合并收据与完成信号，减少交互次数，降低延迟
    • CompCMO 显式确认缓存状态变更，保证 Requester 知道缓存行已失效 / 共享
    • 干净行回写（WriteCleanFullCleanSh）允许释放缓存资源，同时保证内存数据一致

场景 2：With Persist（带持久化的回写 + CMO）

子场景 2a：Persist from Home（Home 发起持久化）
2a1. Separate response from Home
  1. 完成场景 1 的回写 + CMO 流程
  2. Home → Requester：返回 CompCMO（CMO 完成）
  3. Home → Requester：返回 Persist（数据持久化完成确认）
2a2. Combined response from Home
  1. 完成场景 1 的回写 + CMO 流程
  2. Home → Requester：返回 CompPersist（合并 CMO 完成 + 持久化完成）
场景与原因
  • 适用场景 ：
    • 回写数据需要持久化到非易失性存储（如持久内存、SCM）
    • Home 直接管理持久化逻辑，Subordinate 仅负责数据落地
  • 设计原因 ：
    • 分离 / 合并响应适配不同时序需求：分离响应便于状态机调试，合并响应降低延迟
    • Persist 消息显式确认数据已落盘，满足持久化语义（掉电不丢数据）
    • 复用回写 + CMO 的基础流程，仅新增持久化步骤，降低协议实现复杂度
子场景 2b：Persist from Subordinate（Subordinate 发起持久化）
2b1. Separate response
  1. Requester → Home：发送带持久化的回写请求Home → Subordinate：转发请求（如 WriteNoSnpPtlCleanShPerSep）
  2. Subordinate → Home：返回 DBIDResp（事务收据）
  3. Subordinate → Home：返回 Comp（写完成）
2b2. Combined response
  1. Subordinate → Home：返回 CompDBIDResp（合并收据 + 写完成）
  2. Requester → Subordinate：发送 NCBWrData/WriteDataCancel（回写数据 / 取消）
  3. Subordinate → Home：返回 CompCMO（CMO 完成）
  4. Home → Requester：返回 CompCMO（CMO 完成）
  5. Home → Requester：返回 Persist（持久化完成）
场景与原因
  • 适用场景 ：
    • Subordinate 直接管理持久化逻辑（如内存控制器集成持久化引擎）
    • 无监听写 + 持久化场景，目标地址无其他缓存副本
  • 设计原因 ：
    • Subordinate 直连非易失性存储，可更高效执行持久化操作
    • 分离 / 合并响应适配不同流控 / 时序需求
    • 保证回写、CMO、持久化的原子性，避免数据丢失
子场景 2c：Only CMO transaction to Subordinate（仅持久化 CMO）
  1. Home → Subordinate：发送 CleanSharedPersistSep（仅清理共享 + 持久化）
  2. Subordinate → Home：返回 Comp（CMO 完成）
  3. Home → Requester：返回 CompCMO（CMO 完成）
  4. Home → Requester：返回 Persist（持久化完成）
场景与原因
  • 适用场景 ：
    • 仅需要对已有脏数据执行 "清理共享 + 持久化"，无新数据回写
    • 后台脏页回写、数据刷盘等场景
  • 设计原因 ：
    • 纯 CMO 路径，避免无效数据传输，专注于持久化逻辑
    • 保证缓存行置为共享状态，同时数据落盘，满足持久内存语义

三、核心设计意图与价值

1. 原子化回写 + 缓存管理

  • 将 "脏行回写 → 缓存状态调整" 合并为一个事务，保证原子性，避免中间状态导致数据不一致
  • 例如：WriteBackFullCleanInv 原子完成 "写回内存 → 失效缓存行"，确保后续访问只能从内存读取最新数据

2. 持久化语义保障

  • Persist 消息显式确认数据已落盘到非易失性存储，满足持久内存、数据库等 "掉电不丢数据" 的强需求
  • 支持 Home/Subordinate 两种持久化发起方式，适配不同硬件架构

3. 带宽与性能优化

  • 合并响应（CompDBIDResp/CompPersist）减少协议交互次数，降低延迟
  • 干净行回写无需传输数据，进一步节省带宽
  • 部分回写（若扩展支持 WriteBackPtl）可仅传输修改部分，优化带宽效率

4. 灵活性与可扩展性

  • 覆盖从 "脏行回写" 到 "干净行驱逐"，从 "无持久化" 到 "持久化落盘" 的全场景
  • 兼容无监听 / 独占写，适配多核共享内存与设备访问场景
  • 分步确认机制（CompDBIDResp/CompCMO/Persist）便于调试和错误恢复

四、一句话记忆

Combined CopyBack Write + CMO = 原子化 "脏行回写 + 缓存状态管理 + 持久化落盘" ，通过合并响应优化延迟，用 CompCMO+Persist 保证缓存一致性与数据持久化，是写回缓存与持久内存场景的核心事务模式。

📌 关键场景速查表

表格

场景 核心特征 典型用途
无持久化回写 + CMO 回写数据 + 调整缓存状态 缓存驱逐、脏行回写、普通内存场景
带持久化回写 + CMO 回写 + CMO + 持久化落盘 持久内存操作、数据库事务提交
纯持久化 CMO 仅清理共享 + 持久化 后台脏页回写、数据刷盘
合并响应 少交互、低延迟 高性能 CPU 缓存系统
分离响应 便于调试、状态清晰 安全关键系统、复杂持久化逻辑

📊 CHI 写相关事务完整对照表

下面是你之前所有写事务类型的横向对比，涵盖数据来源、缓存行为、一致性、持久化、典型场景等核心维度，方便你快速区分和记忆。

一、基础信息总表

表格

事务大类 具体事务类型 数据来源 核心目标 缓存分配
Immediate Write WriteNoSnpPtl/FullWriteUniquePtl/FullWriteUniqueFullStash Requester 携带数据 payload 直接写内存 / 缓存，无需先读 不分配（Non-allocating）
Write Zero WriteNoSnpZeroWriteUniqueZero 无数据 payload（协议置 0） 高效清零内存区域 不分配
CopyBack Write WriteBackPtl/FullWriteCleanFullWriteEvictFullWriteEvictOrEvict Requester 本地脏缓存行 脏行回写内存 / 缓存驱逐 已分配（写回 / 驱逐）
Combined Immediate + CMO WriteNoSnpPtlCleanInvWriteNoSnpFullCleanShWriteUniquePtlCleanSh 等 Requester 携带数据 payload 写数据 + 缓存管理（Clean/Inv/Sh） 不分配
Combined Immediate + Persist CMO WriteNoSnpPtlCleanShPerSepWriteUniqueFullCleanShPerSep 等 Requester 携带数据 payload 写数据 + 缓存管理 + 持久化落盘 不分配
Combined CopyBack + CMO WriteBackFullCleanInvWriteCleanFullCleanSh Requester 本地脏缓存行 脏行回写 + 缓存管理 已分配（写回 / 驱逐）
Combined CopyBack + Persist CMO WriteBackFullCleanShPerSepWriteCleanFullCleanShPerSep Requester 本地脏缓存行 脏行回写 + 缓存管理 + 持久化落盘 已分配（写回 / 驱逐）

二、核心行为与特性对比

表格

维度 Immediate Write Write Zero CopyBack Write Combined Immediate + CMO Combined Immediate + Persist CMO Combined CopyBack + CMO Combined CopyBack + Persist CMO
是否带数据 payload 是（Ptl/Full） 否（仅置 0 指令） 是（脏行数据） 是 是 是（脏行数据） 是（脏行数据）
snoop 行为 WriteNoSnp：无WriteUnique：有（回收独占） WriteNoSnpZero：无WriteUniqueZero：有 无（仅回写 / 驱逐） WriteNoSnp：无WriteUnique：有 同左 无 无
CMO 操作 无 无 无 CleanInv / CleanSh 等 CleanSh + Persist CleanInv / CleanSh CleanSh + Persist
持久化（Persist） 无 无 无 无 有（落盘保证） 无 有（落盘保证）
缓存行状态变化 无（不分配） 无 脏 → 干净 / 驱逐 无 无 脏 → 干净 / 驱逐 脏 → 干净 / 驱逐
事务响应模式 Separate / Combined可选 CompAck Separate / Combined CompDBIDResp + CopyBackWrDataWriteEvictOrEvict：Comp + CompAck Separate / CombinedCompCMO 同左 + Persist CompDBIDResp + CopyBackWrData + CompCMO 同左 + Persist
带宽效率 中等（Full 行传输） 极高（无数据） 高（Ptl 仅传修改部分） 中等 中等 高 高
延迟 中 低 中 中高 高 中高 高
一致性保障 WriteUnique：强一致WriteNoSnp：依赖上层 WriteUnique：强一致WriteNoSnp：依赖上层 最终一致（回写后内存同步） 强一致（CMO 保证缓存状态） 强一致 + 持久化 强一致（回写 + CMO） 强一致 + 持久化

三、典型适用场景对比

表格

事务类型 典型场景 核心价值
Immediate Write 设备寄存器写、I/O 访问、写穿透内存 直接写数据，不污染缓存
Write Zero 内存页初始化、临时缓冲区清零、安全数据销毁 无数据 payload，极高带宽效率
CopyBack Write 缓存驱逐、脏行回写、缓存容量不足 保证内存与缓存最终一致，释放缓存资源
Combined Immediate + CMO 设备寄存器同步、安全数据销毁、多线程共享内存 原子化 "写 + 缓存管理"，避免中间状态
Combined Immediate + Persist CMO 持久内存操作、数据库事务提交、金融交易 原子化 "写 + 缓存管理 + 持久化"，掉电不丢数据
Combined CopyBack + CMO 脏行回写 + 失效、干净行驱逐 + 共享 原子化 "回写 + 缓存状态调整"，保证一致性
Combined CopyBack + Persist CMO 持久内存脏页回写、关键数据刷盘 原子化 "回写 + 缓存管理 + 持久化"，保证数据落盘

四、一句话速记

  • Immediate Write：直接写，不缓存，适合设备 / 一次性写
  • Write Zero：不带数据，高效清零
  • CopyBack Write：脏行回写 / 缓存驱逐，保证内存同步
  • Immediate + CMO：写 + 缓存状态管理，原子化一致性
  • Immediate + Persist CMO：写 + 缓存管理 + 持久化，掉电不丢
  • CopyBack + CMO：回写 + 缓存状态调整，一致性优化
  • CopyBack + Persist CMO：回写 + 缓存管理 + 持久化，持久内存场景
相关推荐
比姚明高一截7 天前
第一部分：CHI协议基础与架构概览
chi
比姚明高一截7 天前
第二部分：CHI协议核心机制详解
chi
元直数字电路验证3 个月前
CHI 协议导论与宏观架构
chi·ace·abma
比姚明高一截4 个月前
ARM CMN-700 架构设计与实现指南
chi·arm cmn-700
mustfeng5 个月前
CHI协议学习记录
chi
CodingCos3 年前
【ARM AMBA5 CHI 入门 12 -- CHI 总线学习 】
chi·home node·rn·hn·sn·ci-700·chi sam
热门推荐
012026年3月AI领域大事件：DeepSeek引领开源风暴02GitHub 镜像站点03围棋-html版本04小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）05班级宠物园部署指南06【计算机一级WPSoffice】小黑课堂题库软件下载安装教程（2026年3月最新版）07“wsl --install -d Ubuntu-22.04”下载慢，中国地区离线安装 Ubuntu 22.04 WSL方法（亲测2025年5月6日）08UV安装并设置国内源09中国象棋-html版本10Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南