计算机体系结构 E05:Chiplet 与 CXL 互联边界
计算机体系结构 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 | |
片间互联、PCIe switch 和网络 oversubscription 都能用同一套手算。应用性能还需要端到端测量。
验收结果
本批脚本退出 0,确认总需求 40 GB/s 受到 32 GB/s 共享上游约束。输出保留 application_effective_bandwidth_measured=false 和 cxl_device_measured=false。
模式速查
| 数字 | 可以解释 | 不能解释 |
|---|---|---|
| 单链路 payload | 链路题设上限 | 应用有效带宽 |
| 共享边容量 | 总需求上界 | 每应用分配 |
| 拓扑故障域 | 可能受影响路径 | 实机故障行为 |





