计算机体系结构 E05:Chiplet 与 CXL 互联边界

核心问题

两个内存设备各有 24 GB/s 链路,应用总吞吐为什么不能直接写成 48 GB/s?共享上游、交换结构、协议开销、请求分布和端点能力都会形成边界。链路 payload 上限也不是应用有效带宽。

附件:E05-cxl.json。

范围与证据等级

证据等级为手算。拓扑固定为 host0 → root0 → switch0 → mem0|mem1。上游题设为 32 GB/s,两个下游各为 24 GB/s,两个应用各需求 20 GB/s。当前没有 CXL 设备、协议分析仪、NUMA 放置或应用带宽测量。

CXL 2.0 的公开发布材料支持 switching、memory pooling 和 persistent memory 等能力。完整旧版规范下载需要接受条款,本任务没有获取全文;文章不据此扩展未核查的协议细节。Chiplet 也不是一个自动保证 cache coherence 的泛称。

核心案例:共享上游先形成总量上限

两个应用合计需求 40 GB/s,设备侧链路合计可到 48 GB/s,但共享上游只有 32 GB/s。因此模型只能推出总流量不超过 32 GB/s,不能决定每个应用实际各得多少。公平性、路由、读写混合和协议开销都没有进入题设。

交换机上游故障会同时影响两个设备路径,单个 memory package 故障只影响对应地址区域。带宽瓶颈和故障域都依赖拓扑,不能只看端点参数。

模式:沿路径取瓶颈,沿共享边汇总需求

1
2
路径上限 = min(路径各链路上限)
共享边约束 = sum(经过该边的需求) <= 边上限

片间互联、PCIe switch 和网络 oversubscription 都能用同一套手算。应用性能还需要端到端测量。

验收结果

本批脚本退出 0,确认总需求 40 GB/s 受到 32 GB/s 共享上游约束。输出保留 application_effective_bandwidth_measured=false 和 cxl_device_measured=false。

模式速查

数字 可以解释 不能解释
单链路 payload 链路题设上限 应用有效带宽
共享边容量 总需求上界 每应用分配
拓扑故障域 可能受影响路径 实机故障行为

一手参考资料