CXL Bias Mode (3) - Bias Mode 管理与示例

MangoPapa

已于 2023-08-06 11:56:17 修改

阅读量973

点赞数 5

分类专栏： CXL 协议文章标签： CXL

于 2023-07-21 00:23:43 首次发布

本文链接：https://blog.csdn.net/weixin_40357487/article/details/131842376

版权

CXL 协议专栏收录该内容

25 篇文章 118 订阅

订阅专栏

文章详细介绍了CXL协议中BiasMode的管理，包括软件辅助和硬件自主两种方案。软件辅助适合简单任务，硬件自主适用于复杂任务的自适应切换。内容涵盖BiasMode的切换示例，以及Q&A环节，解答了BiasMode的相关问题。

摘要由CSDN通过智能技术生成

🔥点击查看精选 CXL 系列文章🔥
🔥点击进入【芯片设计验证】社区，查看更多精彩内容🔥

📢 声明：

🥭 作者主页：【MangoPapa的CSDN主页】。
⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/131842376】。
⚠️ 本文目的为个人学习记录及知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
😄 欢迎大家指出文章错误，欢迎同行与我交流 ~
📧 邮箱：mangopapa@yeah.net
💬 直达博主：loveic_lovelife 。（搜索或点击扫码）

CXL Bias Topic 分 3 部分，本篇是第 3 篇。

CXL Bias Mode (1) - Bias Mode 背景与分类
CXL Bias Mode (2) - 实现 Bias Mode 的要求
CXL Bias Mode (3) - Bias Mode 管理与示例 👈

为便于描述，Host Bias Coherency Model 在下文中简写为 Host Bias，Device Bias 同理。当我们提到 Accelerator 时，是指 Device 中的 Accelerator；当我们提到 Device Memory 时，是指 Accelerator-attached Memory；当我们提到 HDM-DB 时，单指 Type 2 Device 中的 HDM-DB Memory。

1. Bias 背景与分类

CXL Bias Mode (1) - Bias 背景与分类

2. 实现 Bias Mode 的要求

CXL Bias Mode (2) - 实现 Bias Mode 的要求

3. Bias Mode 管理与示例

3.1 Bias Mode 管理

对 Bias Mode 的管理是指依据当前运行阶段调整 Bias Mode，使 Host、Device 的整体性能达到最佳。

CXL 提供了两种 Bias 管理 方案：软件辅助 (Software Assisted) 及 硬件自主 (Hardware Autonomous) 管理。Device 可以任选其一或者混合使用。当然 Device 也可以都不选，这时全部 HDM-D/DB 区域默认为 Host Bias。

3.1.1 软件辅助

软件辅助切换，意为由软件来主动切换 Bias Mode。对于分段计算等简单且规律的运算 Pattern，软件可以很明确地知道哪些 Page 在执行何种任务，Accelerator 可以依据当前的软件运行阶段来切换相关 Page 的 Bias Mode，从而优化软件运行性能。

软件辅助 Bias 管理有以下裨益：采用软件方案，在 Device 中的 Accelerator 进行计算前就能准备好数据并切换到合适的 Bias Mode，硬件比较省心。话虽如此，但 Accelerator 所需的数据并不一定都能放在 Accelerator-attached Memory——比如 Accelerator 子任务所需的数据集很大，Device Memory 放不下。此时，Device Memory 不能开放给 Host 作统一编址，而应把整个 Device Memory 作为一个 Giant Cache，原数据集仍然保留在 Host Memory，Accelerator 根据程序运行的阶段逐步把 Host Memory 内的超大数据集按需分段搬运到 Giant Cache 中。<- 此为笔者对 Spec 下述两句话的解读，参考了附录 A-4 Giant Cache：

If data is not moved to accelerator memory in advance, it is generally moved on demand based on some attempted reference to the data by the accelerator.
In an “on-demand” data-fetch scenario, the accelerator must be able to find work to execute, for which data is already correctly placed, or the accelerator must stall.

上述 Giant Cache 的应用，有点“显存不够内存来凑”的意思，Accelerator 程序运行期间不断到内存（Host Memory）Fetch 所需数据，Latency 大是难免的，这对低配 Accelerator 而言实属无奈之举。

对于较为简单的 Accelerator 而言，有效的软件辅助数据一致性管理是至关重要的。但软件辅助切换存在一定的局限性：①软件中存在 Bias Mode 感知/切换开销；②不同的软件均需在软件内进行相关设计。对于一些较为复杂的任务，比如 Host、Accelerator 分离计算问题，比如基于指针模型、树模型或稀疏数据问题，任务本身涉及的 Page 就分散且杂乱，这时候再去依靠软件去感知/切换这些 Page 的 Bias Mode，软件工程师怕是要骂娘。

3.1.2 硬件自主

上文提到，软件辅助的方案对功能简单的 Accelerator 较为友好，硬件偷的懒，由软件找补回来。对于上档次点的 Accelerator，其功能复杂可编程，硬件本身就支持 Bias Mode 的自适应切换，此时再去用软件辅助感知、切换 Bias Mode，无异于舍近求远，徒增软件开销。

鉴于此，CXL 提出一种硬件自动 Bias Mode 管理方案，该方案不依赖于软件来管理 Page 的 Bias Mode，而是依赖于硬件来做，硬件基于 Requestor 发出的请求对其所需的 Bias Mode 进行感知与自主切换。

若采用了硬件自动切换的 Bias Mode 管理方案，在 Host 分拆任务时，无需顾及各个 HDM-D/DB Page 的 Bias Mode，软件直接将大任务分拆、下发给各个 Accelerator Core，Accelerator 收到子任务后及子任务运行期间会自适应动态调整 Bias Mode。

当然，也可以采用软硬结合的方案，由硬件感知所需的 Bias Mode，通知软件并由软件进行 Bias Mode 的切换。

3.1.3 方案比对

除了上述提到的不同，软硬件之间还存在一些不同。

笔者理解，软硬件方案的简化流程如下图所示。

在这里插入图片描述

采用软件方案时，在任务下发之前就已经完成了 Bias Mode 切换；采用硬件方案时，任务下发完毕开始执行了才能感知到其所需的 Bias Mode 并作出调整。在调整之前，势必会有 Host 访问 Device Bias 或者 Device 访问 Host Bias 区域的情况，在此期间其性能稍逊于软件方案。

软件方案是先评估所需的 Bias Mode 再将相关任务下发到所需的 Page 中，最后执行任务。软件评估期间 Accelerator 没有拿到任务，处于 Stall 的闲置状态。有而不用视为浪费，势必会对软件性能有所牵累，评估越慢受累越深。相比之下，硬件上来就下发任务并执行，发现不对后再切换 Bias Mode，Accelerator 就没闲着，软件性能或许能比软件管理方案高。

3.2 Bias 切换示例

比如有一个较大的任务 Task0，切分为多个独立的子任务 Sub-Task1/2/3/4。Host 先获取 Data Line 的访问权限（Host Bias），这样 Host 就能直接把相关程序写到 Host Cache 内。写完之后，Device Host Cache 内的 HDM-D/DB Cacheline Flush 回 Device Memory，即把程序及所需数据取回，进而收回权限，由 Device 独立运行程序，运行结果也放在该区域。Device 执行完之后，把 Bias 交给 Host，由 Host 到 Device Memory 中把运行结果取回。Host 取回结果之后，释放对相关 Page 的占用。整个过程可以概括为：Host 分配任务@Host Bias->Device 执行任务@Device Bias->Host 取回数据@Host Bias。

下文做稍详细的流程描述：

初始情况下为 Device Bias，此时应确保 Device Bias 的 Page 在 Host Cache 内没有副本。
软件分配 Device Memory 的 Pages 给 Host 用，此间涉及：
- 软件采用 OpenCL* API 在 Host Cache 中开辟 Device Memory 相关 Cacheline 的 Entry，若相关 Page 为 Device Bias 则将其切换为 Host Bias。这里仅仅是开辟 Cacheline Entry，不需要 Device Memory 的数据，也无需将 Host Cache 内此前已存在的 Cache Line Flush 回 Device Memory。
- Host 获取相关 Cacheline 的独享权限后，执行相关操作，把子任务及所需数据写进新开辟的 Cacheline 中。
Device 内软件采用 OpenCL API 将上述 Host Bias 的 Cacheline 切回为 Device Bias，此间涉及
- 调用 API 触发 Work Descriptor 把子任务提交到 Device，即 Descriptor 请求 Device 发起 Flush 操作。Device 通常采用 RdOwnNoData 要求 Host Cache 把相关 Cacheline 数据 Flush 回 Device Memory。
- Flush 完毕之后，Device 获得 Cacheline 的独享权限，Host Bias 切换到 Device Bias，软件提交子任务给 Accelerator 完毕。
- Accelerator 直接访问 Device Bias Cacheline，执行上述子任务，期间把子任务运算结果写到存放结果的 Device Bias 的 Page 中。
Host 软件从 Device 结果页取处理结果
- 软件采用 OpenCL API 重新获取相关页的权限，Device Bias 再次切回到 Host Bias，此间不涉及 Cache 一致性或 Data Flush 操作
- Host 可以直接到访问、缓存或 Share 结果数据
子程序运行完毕，软件释放相关页。

4. Q&A

Bias Mode 是什么？
Type 2 Device Memory 中 Page 的偏向性，决定了谁来直接管理其一致性。
Bias Mode 存放在哪？谁来管理？
直接放在 Device 中的 Bias Table，由 DCOH 来直接管理。Host 可以通过 SF 或访问 Meta 来推测或间接更新 Bias Mode。
Host 能看到 Bias Mode 吗？
Host 无法直接看到确切的 Bias Mode，其可以通过 SF 或访问 Meta 来推测或间接更新 Bias Mode。
HDM-DB 也有不同的 Bias Mode 吗？
Bias Mode 是 Type 2 Memory 的属性，Type 2 类型的 HDM-D 及 HDM-DB 均支持 Bias Mode。
两者不同的 Bias 切换方式中，由谁发起 Bias 切换？
软件和硬件都可以发起 Bias Mode 切换请求。
不同的 Bias Mode 应用场景是什么？
Host Bias 常用于 Host 分配任务或回收出运算结果，Device Bias 常用于 Accelerator 运算。