一、CXL概述与多Socket架构简介
各位同学，大家好。我是这次课程的主讲。咱们直接进入正题。
多Socket CXL.cache性能调优，这名字挺长。你拆开看，其实就是三件事：多Socket架构、CXL协议、和cache一致性调优。第一节课，我们先搭好地基。把CXL是什么、多Socket为什么需要它、以及CXL.cache在这张图里站什么位置，一次搞清楚。
CXL（Compute Express Link）是一个开放性的高速互联标准。它跑在PCIe Gen5/6的物理层上，但干的事远不止IO搬运。它主要解决CPU、内存（DDR/HBM）、加速器（GPU/FPGA/ASIC）之间的一致性与低延迟共享。
我习惯把CXL理解为“智能PCIe”。PCIe只管把数据从A搬到B，搬完就不管了。CXL不一样，它知道A和B各自在干什么，能主动帮忙维护缓存一致性。这一点，在多Socket场景下尤其关键。
1.1 为什么多Socket需要CXL
咱们先看看传统多Socket系统长什么样。两个或四个CPU插槽，通过QPI/UPI互联。每个CPU有自己的本地内存。一个进程跑在Socket 0上，想访问Socket 1的内存，必须走跨Socket链路。延迟一下子就上去了，一般会增加40-80ns。
这还算好的。如果Socket 0上的加速器想访问Socket 1上的内存，或者GPU想直接读写远端DDR，那就更麻烦了。传统做法是让加速器先申请DMA缓冲区，再走PCIe，中间的拷贝和同步开销很大。
CXL改写了这个局面。
它允许设备（不限于CPU）直接参与系统的一致性域。也就是说，一个插在Socket 0上的CXL加速器，可以直接访问Socket 1的内存，而且能看到最新的缓存状态，不用软件去刷cache行。
我个人觉得，CXL是对UMA架构的一次回归和升级。为什么这么说？咱们接着看。
1.2 多Socket内存模型对比
不同架构下的内存模型，影响着你调优的手段。我整理了一个对比表格。
| 架构类型 | 特征 | 延迟参考 | 一致性域 |
|---|---|---|---|
| UMA（传统单Socket） | 所有内存对称访问 | ~80-100ns | 单域，硬件全保 |
| NUMA（传统多Socket） | 本地快，远端慢 | 本地~100ns，远端~160ns | 单域，UPI同步 |
| cxlNUMA（CXL扩展） | 本地快，CXL设备内存次之，远端再次 | 本地~100ns，CXL.内存~180ns，CXL.cache可控 | 多域，硬件+软件协同 |
这里要特别注意cxlNUMA这一行。我以前在搭建原型时，第一次看到CXL设备的内存被操作系统识别为一个独立的NUMA节点，还挺惊讶的。这意味着什么？意味着你的应用进程如果绑错了核，访问CXL内存的延迟可能比跨Socket还高。
1.3 CXL协议栈的三大子协议
CXL协议栈分为三个子协议。咱们这门课主要关注第三个——CXL.cache。但另外两个你也要了解，因为它们共享链路带宽。
- CXL.virt：用于IO虚拟化。简单说，就是让虚拟机直接访问CXL设备，绕过软件模拟。延迟好，吞吐高。
- CXL.io：本质上是PCIe的替代。用来做控制面的配置、中断、DMA。所有CXL设备都必须实现。
- CXL.cache：这个是我们的主战场。它允许从设备（比如加速器、智能网卡）主动缓存主机内存。并且，当设备修改了缓存数据，主机能看到最新的值。不需要软件去手动无效或刷新。
说白了，CXL.cache让设备在硬件层面，和CPU之间维持了缓存一致性。这对性能敏感的应用是革命性的变化。
一个常见的误区：CXL.cache不是让设备变成CPU的L3缓存。它是让设备拥有自己的私有缓存，同时能窥探CPU侧的缓存状态。设备写数据，CPU侧的旧副本会被硬件自动无效。反过来也一样。
1.4 课程的核心：为什么是CXL.cache，而不是CXL.mem？
有同学会问，CXL.mem不是更简单吗？直接扩展内存容量，操作系统就能看到。为什么还要折腾cache？
嗯，问得好。CXL.mem适合做内存扩展池。但它有一个问题：延迟。CXL.mem访问走的是CXL.io最底层，一次请求要经过完整的协议封装和解封装，加上物理层FLIT序列化，延迟大概在180-250ns左右。这个延迟对内存池来说能接受，但对加速器来说太高了。
CXL.cache不一样。它允许设备在本地维护一个快速的缓存。假设命中率能做到80-90%，有效延迟可以从180ns降到30-50ns。我曾在某个项目里实测过，一个FPGA加速器通过CXL.cache读取热点数据，吞吐量比用CXL.mem直接读提高了3.8倍。
这是这门课的核心。我们要学的，就是如何在多Socket环境下，用CXL.cache把延迟压到极致，把命中率提到最高。
1.5 本章知识体系总览
这一章我们打基础。我把整个知识脉络画了一张图，方便你建立全局感。
这张图你可以存下来，每学完一章，回头看一眼，能帮你把零散知识串起来。我自己做内核调优或BIOS调优之前，都会先在脑里把这四个层级过一遍。
1.6 我们这门课的设计思路
我一直觉得，好的课程应该像剥洋葱。一层一层剥下去，最终看到核心。
这30节课，我的设计逻辑是这样的：
- 基础篇（第1-5章）：讲清楚CXL协议细节、多Socket一致性协议、设备枚举和NUMA拓扑。这是立足点。
- 调优篇（第6-20章）：从硬件、固件、操作系统、驱动到应用，全链路分析。你会遇到各种工具，比如perf、Emulation Tracer、CXL Compliance Suite，还有我们实战用的CXL调优脚本。
- 案例篇（第21-30章）：真实场景复现与调优演练。包括多Socket CXL.cache miss率过高、跨Socket cache行颠簸、设备端预取策略错误等。
你们现在看到的是第一章。听起来可能有点抽象，别急。从第二章开始，我们就要动手了。我会带着你们分析第一手的协议trace数据，看能不能发现有意思的模式。
我记得第一次跑通CXL.cache的硬件原型时，操作系统里出现了一个新的NUMA节点，设备侧直接访问主机内存，不需要任何内核补丁。那个瞬间真的让我很震撼。希望你们也能在课程里体会到这种感觉。
学前警告：CXL.cache是硬件一致性协议，不是软件库。任何调优策略的前提是硬件平台和BIOS必须支持CXL.cache。如果你用的是只支持CXL.mem的早期物理样片，或者QEMU模拟器还没实现cache模型，学完理论后请先在虚拟环境下验证。