传统的内存以 DDR 为主，通过 DIMM 插槽安装在各主机上，形成主机的内存的私有内存，也被成为内存孤岛. 在数据中心，服务器集群可以通过热插或者热拔弹性实现内存扩容(Expansion)和缩容(Shrink), 虽然这样可以充分利用内存资源，但每台服务器上大量的冷数据依旧会占用价格不菲的内存，并且每台服务器的内存就是一个个内存孤岛，需要很高的成本才能和其他主机交换数据.

技术不断进步，内存池化技术不断被提出来，不同的实现方案被拿出来不断的讨论，但能够落地且使用的方案少之又少. 当 CXL 2.0 推出之后，主机之间可以通过 CDFP 和 CXL SWITCH 形成新的互联方式，这给内存池化方案落地带来了一些机会.

在 CXL 池化方案中，在一个机柜内，服务器之间通过 CDFP 统一连接到顶部的 CXL SWITCH 上，服务器被分作 CPU、内存、存储、GPU 异构和网络节点，在 CPU 节点，服务器内部部署了高密的 CPU Core，内存服务器则插满了 CXL Type3 内存设备，存储服务器则插满了 CXL Type3 PMEM/DDR 设备作为存储节点，而 GPU 异构节点则插满了 GPU.

当一个任务下发下来，首先动态从计算节点热插指定数量的 CPU Core，接着从内存服务器热插指定容量的内存，然后从存储服务器节点热插指定容量的磁盘，最后根据需求热插指定数量的 GPU 和网卡, 通过上面的操作之后运行任务的环境弹性构建完毕. 当任务处理完毕之后，将弹性热插的资源全部归还给各模块.

在该方案中，内存节点的池化可以存在多种实现方案，本节重点介绍基于 CXL 的内存池化方案. 池化中两个基础功能就是: Pooling(隔离) 和 Sharing(共享). 首先是 Pooling(隔离)，内存池可以根据需求弹性提供指定容量的内存设备，并且内存设备需要与其他主机之间隔离，也就是需求方独占(Exclusive) 内存设备. 其次是 Sharing(共享)，内存池根据需求将同一个内存设备同时让多个主机之间共享，以便在特定场景下实现多主机之间数据共享.接下来重点介绍一下 Sharing(共享) 的实现原理.

在 CXL 架构中，内存服务器由管理节点和内存节点构成，内存节点由 CXL Type3 设备构成服务器，CXL Type3 设备分作两类，首先一类是由 NVDIMM 颗粒构成的非易失 CXL Type3 PMEM 设备，其特点是可以掉电存储数据. 另外一类是由 Volatile DRAM 颗粒构成的易失 CXL Type3 DDR 设备. 管理节点在收到命令之后，可以将 CXL Type3 设备热插到指定主机，也可以将设备从指定主机热拔设备.

主机则通过 CDPF 连接到 CXL SWITCH，CXL SWITCH 下游则连接到存储节点的 CXL Type3 设备，CXL SWITCH 独立于主机，由 Fabric Manager(FM) 管理, FM 可以让多台主机同时连接到 CXL SWITCH，并让每个主机看到的 CXL SWITCH 是一个独立隔离的 VCS(Virtual CXL SWITCH)，这就是 CXL 池化方案的基础.

FM 为每个主机创建了独立的 CXL 总线(PCIe 总线)之后，池化系统可以根据需求，从存储节点将指定容量的 CXL Type3 设备热插到 CXL 总线. 接下来 CXL Type3 支持 MHMLD 和 MHSLD，简单的来说 MHMLD 可以将一个 CXL Type3 设备虚拟成多个 CXL Type3 设备, 并且被虚拟出来的设备可以同时挂接到不同的 CXL 总线上. 同理 MHLD 可以将一个 CXL Type3 设备同时挂载到不同的 CXL 总线.

硬件上构建了一条隔离的 CXL 总线，以及共享的 CXL Type3 设备. 接下来 CXL Type3 设备热插到系统之后，系统内部识别到热插的 CXL 设备，接下来就是对该设备创建新的 CXL REGION. 如果 CXL REGION 的模式配置为 SYSTEM-RAM，那么系统可以可以像访问普通内存一样使用 CXL 内存. 如果 CXL REGION 的模式配置为 DEVDAX，则可以按顺序访问 CXL 内存.

当系统不在需要存储设备时，系统内部先做软件层面的热插插座，然后向池化系统发送热拔(HOT-REMOVE)操作. 池化系统收到热拔请求之后，将对应的 CXL Type3 设备从 CXL 总线上热拔掉，这样该 CXL Type3 设备在存储池子里变成空闲可用的内存节点. CXL 内存池化 Sharing(共享) 的好处是可以在主机之间共享物理内存，那么就让多个内存孤岛连接成一片大陆，主机与主机之间的交流信息不再需要额外的开销，形成了主机之间的 ZEROCOPY. 那么接下来通过一个实践案例讲解整个过程，实践案例在 BiscuitOS 上的部署逻辑是:

# 切换到 BiscuitOS 项目目录
cd /BiscuitOS
# 选择开发环境，如果已经选择过可以跳过，这里与 linux 6.10 X86 为例
make linux-6.10-x86_64_defconfig
# 通过 Kbuild 选择需要部署的应用程序
make menuconfig

  [*] DIY BiscuitOS/Broiler Hardware  --->
      [*] CXL: Compute Express Link
            CXL Hardware Topology (CXL2.0: x1 VCS + x1 Type3 PMEM)  --->
            (5120)  CXL Type3 PMEM Size(MiB)
            [*]     CXL MEMORY POOL
  [*] Package  --->
      [*] HETEROGENEOUS MEMORY MANAGEMENT
          [*] CXL MEMORY POOL: SHARING MODE  --->

# 配置完毕保存，然后进行部署
make

# 切换到实践案例所在目录
cd /BiscuitOS/output/linux-6.10-x86_64/package/BiscuitOS-CXL-MEMORY-POOL-SHARING-default
# 准备依赖工具
make prepare
# 编译实践案例
make download
make build

首先启动第一台主机，当主机启动之后，首先使用 “lspci-common -vt” 查看 CXL 总线(PCIe 总线)，可以看到 0000:0C 总线为 CXL 总线，其 CXL SWITCH 上只挂接了一个 CXL Type3 设备. 接下来向池化管理者发起弹性热插一块存储的命令:

# 切换路径
cd /BiscuitOS/output/linux-6.10-x86_64/package/BiscuitOS-CXL-MEMORY-POOL-SHARING-default/BiscuitOS-CXL-MEMORY-POOL-SHARING-default
# 发送热拔请求
./FManager.sh HOTPLUG HOST1
# 主机内部执行热拔命令
RunBiscuitOS.sh
# 查看 CXL 总线 
lspci-common -vt

当在主机 1 里面执行 RunBiscuitOS.sh 脚本，脚本里包含了热插存储节点的命令，当命令执行完毕之后，再次使用 “lspci-common -vt” 查看 CXL 总线，可以看到新插入的存储节点(0000:10:00.0), 接下着使用 APP 命令对 CXL 内存起始地址读写操作, 写入数据 “THIS IS BISCUITOS-HOST1”. 接下来将在主机 2 上也热插一个存储节点，使用如下命令:

# 切换路径
cd /BiscuitOS/output/linux-6.10-x86_64
# 启动主机 2
./RunBiscuitOS-CXL.sh

# 主机 2 外新开一个 Docker 窗口发起发送热拔请求
./FManager.sh HOTPLUG HOST2
# 主机 2 内部执行热拔命令
RunBiscuitOS.sh
# 查看 CXL 总线
lspci-common -vt

当主机 2 其中之后执行 RunBiscuitOS.sh 脚本，脚本里包含了热插存储节点的命令，当命令执行完毕之后，再次使用 “lspci-common -vt” 查看 CXL 总线，可以看到新插入的存储节点(0000:18:00.0), 接下来使用 APP 命令对该文件进行读数据，读到的数据是 “THIS IS BISCUITOS-HOST1”, 此时只要其中一台主机写入数据，那么在另外一台主机同时可以读到刚刚写入数据，这就是两台主机同时共享同一块物理内存, 也验证了内存池化的 Sharing(共享) 的特性. 以上便是 CXL 内存池化 Sharing(共享) 的完整实践案例.