13.0 Performance Considerations
CXL 为加速器访问系统提供了低延迟、高带宽的路径。CXL 的性能取决于多种因素。表 13-1 列出了 CXL 的主要性能属性。
1.实现的带宽取决于协议和有效载荷大小。CXL.cache 和 CXL.mem 的效率预计为 60-90%。效率与 CXL.io 上的 PCIe* 类似
一般而言，预计上行端口和下行端口的速率是匹配的。但是，如果实现不匹配速率，则需要较快的实现限制其协议流量的速率，以匹配较慢的实现（包括突发），只要没有明确的流量控制循环。
CXL 允许加速器/设备以一致的方式访问主机内存，并允许将连接到加速器/设备的内存映射到系统地址映射中，并由主机直接作为写回内存访问。为了支持这一点，它支持第 2.2.1 节和第 2.2.2 节中所述的一致性模型。
13.1 Performance Recommendations
为了最大限度地减少缓冲要求并提供良好的响应能力，CXL 组件需要努力降低延迟。根据组件类型，需要特别关注特定的事务流，以确保系统性能不会受到负面影响。
建议组件满足表 13-2 中列出的延迟目标。
这些目标是在空闲系统中的组件引脚处测量的。
测量的是平均空闲响应时间，这意味着将单个消息传输到组件，并在将另一条消息传输到组件之前从组件收到响应。用于平均测量的消息的地址应随机分布。表 13-2 中列出的所有目标都假设 x16 链路全速（64 GT/s），IDE 禁用。
对于 CXL 设备和交换机，CDAT（参见第 8.1.11 节）提供了一种机制
- 案例 1：提供的范围考虑了实现权衡，专用的 CXL 接口监听过滤器提供最低延迟，而嵌入在设备缓存层次结构中的监听过滤器则会导致更高的延迟。
案例 2：假设写入数据已准备好在 CXL 输出缓冲区中传输。
案例 3 和 4：适用于使用 DRAM 介质的 3 类设备，旨在提供与 DDR DIMM 相当的系统级性能。假设此类设备相对简单、小巧、低功耗，而不是复杂、多端口或池化内存设备。请注意，案例 3 比表 13-3 中的目标更激进，因此表 13-3 中的目标将低于这些设备中的案例 3 目标。使用较慢介质的内存设备（例如某些持久内存类型）将具有更长的延迟，系统设计人员必须考虑到这一点。
情况 5：BISnp 将导致主机解析发送 BISnp 的设备所拥有的 HDM-DB 内存地址的一致性。解析一致性的目标延迟适用于主机在任何主机管理的缓存中都没有缓存行的简单情况（此范围包括使用 CXL.cache 的对等 CXL 设备）。
向主机软件报告最低延迟和最高带宽（请参阅 ACPI 规范以了解系统局部延迟和带宽信息结构的定义）。但是，该报告结构仅辅助主机软件。
硬件和系统设计人员必须在设计时考虑拓扑和感兴趣的组件。硬件设计人员应考虑其组件需要容忍的最大延迟，同时仍保持高链路带宽、相应地调整未完成请求和数据缓冲区的大小。
QoS 遥测机制（请参阅第 3.3.4 节）定义了一种机制，主机可以通过该机制动态调整其请求速率以避免内存设备过载。
此机制对于在多个主机之间共享的 MLD 组件尤为重要。
在链路层，建议使用表 13-3 中列出的最大加载延迟。
如果不遵守，两个端口之间的链接可能会被限制到低于线速。这些建议适用于所有 CXL 端口以及 CXL.cache 和 CXL.mem 接口。目标假设 x16 链接已禁用 IDE。
2. 情况 1：考虑 8 个连续的 flit 序列，其中 CRC 必须累积，然后才能传输 Ack。仅适用于以 68B Flit 模式运行的链路，因此假设全链路速度为 32 GT/s。以 256B Flit 模式运行的链路与 PCIe 共享 Ack/Retry 逻辑，并符合 PCIe 基本规范中提供的任何准则或要求。
情况 2：在这种情况下，端口缺少传输消息所需的链路层信用，然后接收允许传输消息的信用更新。假设全链路速度为 64 GT/s
13.2 Performance Monitoring
性能调整和性能调试活动依赖于位于不同系统组件内的性能计数器。本节介绍 CXL 组件的性能监控基础架构。
基本硬件单元称为 CXL 性能监控单元 (CPMU)。CXL 组件可能有零个或多个 CPMU 实例。每个 CPMU 实例包括一个或多个计数器单元。通过以下 CXL 寄存器定位器 DVSEC（寄存器块标识符 = 4）来定位与 CPMU 关联的寄存器。交换机中的每个 CPMU 实例都应计数与单个端口关联的事件。可以通过遵循该端口配置空间中的 CXL 寄存器定位器 DVSEC 来识别与端口关联的 CPMU 实例。如果 CXL 多功能设备实现了一个或多个 CPMU 实例，则与功能 0 关联的寄存器定位器 DVSEC 应指向它们。
CXL 事件定义为与 CXL 组件操作相关的特定组件活动的发生。根据事件所代表的活动类型，将事件分组为事件组。 <事件供应商 ID，事件组 ID> 对标识一个事件组。每个事件组最多可以有 32 种不同类型的事件，每个事件由 5 位事件 ID 标识。元组
<事件供应商 ID，事件组 ID，事件 ID> 唯一地标识事件的类型。
有关本规范定义的 CXL 事件列表，请参阅表 13-5。过滤器列列出了适用于事件组的所有过滤器 ID 值。多事件计数 (MEC) 列定义了计数器单元的行为，当计数器单元配置为通过设置多个位同时计数事件组中的多个事件时。如果 MEC 列指示 ADD，则计数器单元应在每个时钟上添加所有启用事件的发生次数，这可能导致计数器数据在单个时钟内增加超过 1 的值。如果 MEC 列指示 OR，则计数器单元应在每个时钟上逻辑或所有启用事件的发生次数，并且计数器数据在任何单个时钟内都不会增加超过 1。
本规范中定义的任何事件都不能使计数器数据每周期增加超过 1。因此，在对此处指定的任何事件进行计数时，软件必须将计数器配置寄存器中的阈值字段（参见第 8.2.7.2 节）设置为 1。计数器单元能够对一个或多个事件的发生进行计数。计数器单元能够配置为对计数器单元能够计数的事件子集进行计数。计数器单元可能能够配置为在计数溢出时采取某些预定义的操作。表 13-4 描述了三种类型的计数器单元。
CPMU 寄存器接口在第 8.2.7 节中定义。这些寄存器供主机软件或系统固件使用。如果此类访问可能会干扰主机软件操作，则组件不得将 CPMU 寄存器或底层资源暴露给带外代理。虽然组件可以选择为带外使用实现一组单独的计数器，但使用这种机制超出了本规范的范围。
Event Group: 事件组的名称，说明这个事件属于哪个类别或功能。
Event ID: 事件的唯一标识符，方便在系统中引用特定事件。
Mnemonic: 事件的助记符，便于在代码或文档中引用。
Event Description: 对于事件的详细描述，包括这个事件具体计数的内容。
Filters: 可选的过滤器，指明是否可以对事件进行筛选。
MEC (Metrics Evaluation Capability): 指示该事件是否可以用于评价指标的能力。
事件的具体内容： 00h (Clock Ticks): 计算用于增量计数器的时钟滴答。
10h (D2H Req Opcode encoding): 计算从D2H（设备到主机）请求中发起的消息数。
11h (D2H Rsp Opcode encoding): 计算D2H响应消息中发起的消息数。
12h (H2D Req Opcode encoding): 计算H2D（主机到设备）请求中发起的消息数。
13h (H2D Rsp Opcode encoding): 计算H2D响应消息中发起的消息数。
14h (D2H Data): 计数与D2H数据相关的消息数量。
15h (Reserved): 保留事件，未来可能用于其他功能或扩展。
这样的计数对于性能监控和调试CXL系统非常重要，可以帮助识别瓶颈或潜在问题
3. 在 MEC 列中，ADD 表示计数器单元应在每个时钟周期内将所有启用事件的发生次数相加，这可能导致计数器数据在单个时钟周期内增加超过 1 的值。在 MEC 列中，OR 表示计数器单元应在每个时钟周期内对所有启用事件的发生次数进行逻辑或运算，并且计数器数据在单个时钟周期内永远不会增加超过 1。
4. 有关事件描述列中引用的特定命令的定义，请参阅 JEDEC DDR5 规范
该图以图形方式表示了支持单个事件组和两个可配置计数器的简单 CPMU 如何计数事件。
- 每个时钟，通过计数器配置寄存器中的事件字段选择的事件被“或”在一起。
- 步骤 1 的输出，标记为“或”事件，受到各种配置过滤器的影响。
- 步骤 2 的输出被添加到计数器数据中。
注意：为了便于阅读，未显示阈值、边缘和反转控件。
