在 CXL 拓扑结构中，可能同时存在多个 CXL Type3 设备，CXL 将 CXL Type3 设备上的存储区域称为 DPA(Device Physical Address) 区域，而将 CXL Typ3 设备存储区域映射到系统物理地址总线的区域称为 HPA(Host Physical Address). 与 DDR 类似，DDR 会按照一定的规则将其存储区域映射到系统物理地址空间，以此形成物理内存. 对于 CXL Type3 设备，其 DPA 映射到 HPA 的规则如何?

在系统启动过程中，Linux 从 ACPI CEDT 的 CFMWS 表中获得 CXL 在系统物理地址空间占据的范围，此时这段区域并没有与任何 CXL Type3 设备的 DPA 映射，而是预留给 CXL 映射 DPA 使用, 如上图可以从 “/proc/iomem” 节点查看系统物理地址空间，其中 CXL Windows 0 就是 CXL 占用的区域.

# 清除所有的 CXL REGION
cxl destroy-region -f all
# 创建一块映射 CXL Type3 RAM 的 CXL REGION
cxl create-region -d decoder0.0 -m mem0 -s 512M -t ram -w 1 -g 4096 -u
# 使 CXL REGION 生效
cxl enable-region region0

使用上图命令可以创建一个 CXL REGION，其从 “CXL Windows 0” 找一块空闲 512M 区域，然后将 512M HPA 区域映射到 CXL Type3 设备 mem0 的 512M DPA 上，映射完毕之后可以在 “/proc/iomem” 里看到 “region0” 被创建，那么此时系统访问 region0 对应的 HPA，那么硬件会访问在 mem0 的 DPA. 通过上面的例子，大致了解 CXL REGION 的作用.

CXL REGION 可以解释为用于维护 HPA 到 DPA 的合集，由于一段 HPA 区域可以由不同的 CXL Type3 设备的 DPA 构成，那么 CXL REGION 用于屏蔽 HPA 到 DPA 的映射关系，让操作系统只需访问 HPA 区域，而无需关系 HPA 到底来自哪个 CXL Type3 设备的 DPA. 如上图，CXL Windows 里被划分成 CXL REGION 的区域代表系统可以使用的区域，同一块 CXL REGION 可以来自同一块 CXL Type3 设备，也可以来自不同的 CXL Type3 设备，这样的设计的好处是:

• 内存容量扩展: 通过 CXL Region，多个 CXL 内存设备的内存资源可以被统一管理，形成一个逻辑上连续的内存池. 在数据中心中，多台服务器的内存资源可以通过 CXL Region 池化，按需分配给需要大内存的任务(如 AI 训练、大数据分析). 突破单机物理内存容量限制，减少对传统分布式内存架构的依赖
• 内存共享与低延迟访问: CXL Region 允许多个处理器或加速器(如 GPU、FPGA)共享同一内存空间，避免数据复制. 在异构计算中，CPU 和 GPU 可以直接访问同一 CXL Region 中的内存，无需通过 PCIe 多次拷贝数据. 降低数据传输延迟，提升计算效率(尤其适合机器学习、实时分析)
• 缓存一致性支持: CXL 协议原生支持缓存一致性(CXL.cache)，通过 CXL Region 管理的设备内存可被主机处理器以缓存一致的方式访问. 多个主机通过 CXL Switch 连接到共享的 CXL 内存池，每个主机可透明访问内存，无需软件维护一致性. 简化编程模型，减少软件开销，提升多核/多节点系统的性能
• 灵活的交错访问(Interleaving): CXL Region 支持按固定粒度(如 256B、4KB)在多个 CXL 设备间交错分配数据，最大化利用设备带宽. 在内存密集型应用中，数据分布到 4 个 CXL 内存设备，每个设备的访问压力均匀，避免单点瓶颈. 提高吞吐量，减少访问争用，尤其适合高并发场景(如数据库、内存计算)
• 动态资源管理: CXL Region 支持动态添加或移除 CXL 设备，系统可在运行时调整内存映射和容量. 在云计算中，根据工作负载需求动态挂载 CXL 内存卡，按需扩展内存容量. 提高资源利用率，支持灵活的资源分配策略
• 降低系统复杂性与成本: CXL Region 通过标准化的协议和接口，将异构设备(CPU、GPU、FPGA、内存扩展卡)整合到统一的内存空间中. 无需为每个加速器单独设计专用内存接口，简化系统设计. 降低硬件和软件开发成本，加速产品上市时间

当创建一个 CXL REGION 之后，可以在 “/sys/bus/cxl/devices/regionX” 目录下查看新创建的 CXL REGION 设备，CXL REGION 向用户空间提供了上图的节点，用于控制和读写 CXL REGION，各节点的含义如下:

• modalias: 该文件包含一个字符串，用于描述设备的硬件标识信息, 内核利用这个信息来查找并加载合适的驱动程序. 例如驱动程序开发者可以根据 modalias 的内容编写匹配特定设备的驱动
• uevent: 当设备的状态发生变化时(如设备插入、拔出等)，内核会通过该文件发送事件通知. 用户空间的程序可以监听这些事件并做出相应的处理
• uuid: 存储设备的通用唯一识别码(Universally Unique Identifier)，用于在系统中唯一标识该设备或资源区域，方便系统对设备进行管理和跟踪
• accessX: 通常用于表示对设备资源区域的不同访问模式或权限设置, 不同的数值可能代表不同的访问级别，如只读、读写等，也可能对应不同的访问接口或方式
• commit: 这个文件可能与资源的提交操作相关, 在某些情况下，对设备资源的配置或更改需要通过向 commit 文件写入特定的值来使其生效.
• mode: 用于设置或显示设备的工作模式, 设备可能支持多种工作模式，通过修改 mode 文件的内容，可以切换设备的不同工作状态
• size: 表示该设备资源区域的大小，通常以字节为单位. 这个信息对于了解设备可用资源的数量很重要，在进行内存分配、数据传输等操作时会用到
• resource: 包含设备使用的系统资源信息，如内存地址范围、I/O 端口等, 通过查看该文件，可以了解设备在系统中的资源占用情况
• dax_region0: DAX(Direct Access) 表示直接访问，dax_region0 可能代表该设备的一个支持直接访问的存储区域. 直接访问允许应用程序绕过文件系统缓存，直接访问存储设备，提高数据访问效率
• driver: 这是一个符号链接，指向当前驱动该设备的驱动程序在 /sys/bus 目录下的位置, 通过查看这个链接，可以知道设备当前使用的是哪个驱动程序
• subsystem: 同样是一个符号链接，指向该设备所属的子系统在 /sys 目录下的位置。子系统是内核中对设备进行分类和管理的一种方式，例如 USB 子系统、PCI 子系统等
• devtype: 用于描述设备的类型，如存储设备、网络设备等。这个信息有助于系统对不同类型的设备进行分类管理和适配
• interleave_granularity/interleave_ways: 这两个文件通常与存储设备的交织(Interleaving)配置相关, interleave_granularity 表示交织的粒度，即数据在多个存储设备之间划分的最小单位. interleave_ways 表示交织的路数，即参与交织 CXL Type3 设备数量
• target0: 可能代表该设备的一个目标设备或接口, 在某些存储系统中，target 通常用于表示存储目标，如 iSCSI 目标、Fibre Channel 目标等

同理，当创建一个 CXL REGION 之后，可以使用 “cxl list -R” 查看新创建 CXL REGION 的信息，例如上图各字段的含义:

• region: 描述 CXL REGION 的名字
• resource: 描述 CXL REGION HPA 的大小
• size: 描述 CXL REGION 的实际大小
• type: 描述 CXL REGION 的类型
• interleave_ways: 描述 CXL REGION 交织 CXL Type 设备的数量
• interleave_granularity: 描述 CXL REGION 交织的最小单位
• decode_state: 描述 CXL REGION 是否生效，”commit” 表示生效

CXL 框架使用 “struct cxl_region” 数据结构描述一个 CXL REGION，其各成员的含义:

• dev: 这是一个表示该 CXL 区域所关联设备的结构体, 在 Linux 内核中，struct device 是设备模型的核心结构体，用于描述一个硬件设备. 通过这个成员，该 CXL 区域可以与内核的设备管理系统集成，利用设备模型提供的各种功能，如设备注册、电源管理、热插拔处理等. 方便内核统一管理该 CXL 区域对应的硬件设备，例如在设备初始化、资源分配和设备移除等操作中使用
• id: 该 CXL 区域的唯一标识符, 这个 ID 在所有 CXL 区域中是全局唯一的，用于在内核中唯一标识该 CXL 区域. 在进行区域查找、管理和通信时，可以通过这个 ID 快速准确地定位到特定的 CXL 区域，避免混淆和冲突
• mode: 表示端点解码器的分配和访问模式, enum cxl_decoder_mode 是一个枚举类型，定义了不同的分配和访问模式，例如可能包括只读模式、读写模式、特定的访问权限组合等
• type: 表示端点解码器的目标类型. enum cxl_decoder_type 是一个枚举类型，定义了不同的目标类型，例如可能包括内存类型、存储类型、设备类型等. 帮助内核和驱动程序了解该 CXL 区域的用途和特性，从而采取相应的处理策略。例如，如果是内存类型的区域，可能会有不同的内存管理和访问优化策略
• cxl_nvb: 指向非易失性双列直插式内存模块(NVDIMM)桥接器的指针. NVDIMM 桥接器用于协调 cxlr_pmem 区域的设置和关闭操作. 在处理非易失性内存相关操作时，通过这个桥接器可以实现对 cxlr_pmem 区域的初始化、配置和资源管理，确保非易失性内存的正常使用
• cxlr_pmem: 指向持久内存(PMEM)区域的指针，对于持久内存类型的 CXL 区域，这是一个缓存副本，用于存储与持久内存相关的信息. 方便内核和驱动程序快速访问和操作持久内存区域，提高持久内存的使用效率. 例如在进行数据读写、内存映射等操作时可以直接使用这个缓存副本
• flags: 表示该 CXL 区域的状态标志. 这些标志是一些位掩码，用于表示该区域的不同状态，例如是否已初始化、是否处于活动状态、是否发生错误等. 内核和驱动程序可以通过检查这些标志来了解该区域的当前状态，从而做出相应的决策. 例如如果某个错误标志被设置，就可以进行错误处理操作
• params: 表示该 CXL 区域的活动参数和配置参数. struct cxl_region_params 结构体包含了该区域的各种配置信息，如内存大小、访问速度、缓存策略等. 在初始化和使用该 CXL 区域时，根据这些参数进行相应的配置和调整，确保区域的性能和功能符合预期
• coord: 这是一个数组，包含了该 CXL 区域的服务质量(QoS)访问坐标. 每个 access_coordinate 结构体可能包含了与访问优先级、带宽分配、延迟要求等相关的信息. 作用：通过这些访问坐标，内核可以对该 CXL 区域的访问进行调度和管理，确保不同的访问请求能够按照预定的服务质量要求得到处理，提高系统的整体性能和资源利用率
• memory_notifier: 这是一个通知块，用于将该 CXL 区域的访问坐标设置通知给节点. struct notifier_block 是 Linux 内核中用于实现通知机制的结构体，当该 CXL 区域的访问坐标发生变化时，可以通过这个通知块通知相关的节点. 实现不同组件之间的信息同步和协调，确保节点能够及时了解该 CXL 区域的访问坐标变化，从而做出相应的调整。例如，当访问优先级发生变化时，节点可以重新调度资源以满足新的要求.

在 CXL 架构里，可以使用 cxl 工具便捷创建一个 CXL REGION，其中 “cxl region-create” 命令是如何创建一个 CXL REGION 呢? 接下来边实践边讲解 CXL REGION 创建的整个过程，为了统一实践，开发者参考下面命令进行实践:

# 切换到 BiscuitOS 项目目录
cd BiscuitOS
# 通过 Kbuild 选择需要部署的应用程序
make menuconfig

  [*] DIY BiscuitOS/Broiler Hardware  --->
      <*> Intel Q35
      [*] CXL: Compute Express Link
            CXL Hardware Topology (CXL2.0: x1 VCS + x1 Type DDR)  --->
  [*] package --->
      [*] CXL Tools: cxl/ndctl/daxctl  --->


# 配置完毕保存，然后进行部署
make
# 安装必备工具
cd BiscuitOS/output/linux-6.10-x86_64/package/cxl-tools-default
# 第一次执行如下命令
make prepare
make download
make tar
make configure
# 运行 BiscuitOS
make build

创建 CXL REGION 的第一步是在 “decoder0.0” 的 create_ram_region 写入 “region0”, 其在 CXL 架构里的处理逻辑如下:

• A: 当向 “create_ram_region” 节点写入 region0 之后，通过系统调用到 dev_attr_create_ram_region 函数，该函数首先获得 decoder0.0 对应的设备，然后调用 __create_region 函数创建 CXL REGION，在该函数内部包括调用 cxl_region_alloc 分配一个 Struct clx_region 数据结构，然后对齐进行相应的初始化. 接着将 CXL REGION 对应的设备加入到 CXL BUS，并提供了设备驱动使用 probe 函数等.
• B: 接着将 CXL REGION 的设备类型设置为 “cxl_region”, 并配备相应的属性节点，包括 “devtype”、”resource” 等属性节点.
• C: 接着将 CXL REGION 作为设备，调用 device_add 函数，该函数会查找 CXL REGION 设备对应的驱动，找到最后会发现 CXL REGION 的驱动对应的 PROBE 函数是 cxl_region_probe 函数，驱动没有实际的动作，简单的检查 CXL REGION 是否生效之后就返回.
• D: 最后为 CXL REGION 添加 Memory Notifiy 通知链，并提供钩子函数 cxl_region_perf_attrs_callback. 以上操作完毕之后，会在 “/sys/bus/cxl/devices/root0/decoder0.0/” 目录下新增 region0 目录.

创建 CXL REGION 的第二、三步是设置 CXL REGION 的交织粒度和交织设备树, 其在 CXL 架构里的处理逻辑如下:

• 设置交织粒度: 当要设置 CXL REGION 的交织为 4096，那么向 region0 目录下的 “interleave_granularity” 文件写入 4096，该操作最后会通过系统调用到 “interleave_granularity_store” 函数，该函数首先获得 region0 对应的 CXL REGION 设备，其对应数据结构 cxl_region, 其包含成员 params, 其属于 struct cxl_region_params, 其用于管理 CXL REGION 的参数，该数据包含成员 interleave_granularity，用于描述 CXL REGION 的交织粒度，因此函数将 4096 写入 interleave_granularity 成员.
• 设置交织设备数: 当要设置 CXL REGION 来自几个 CXL Type3 设备时，那么向 region0 目录下的 “interleave_ways” 文件写入 1，表示 CXL REGION 只来自一个 CXL Type3 设备，该操作通过系统调用会调用 interleave_ways_store 函数，该函数也是先获得 CXL REGION 对应的 struct cxl_region, 然后找到 struct cxl_region_params 成员，该成员对应的数据结构里包含 interleave_ways 成员，用于描述 CXL REGION 来自 CXL Type3 设备的数量. 当执行完这些操作之后会的 region0 目录下新增 target0 节点.

创建 CXL REGION 的第四、五步是为 CXL REGION 申请物理区域(HPA), 以及设置 CXL REGION 的类型，其在 CXL 架构里处理逻辑如下:

• 申请物理区域: 接着是为 CXL REGION 从系统物理地址总线上申请一段物理区域，这段物理区域位于 CXL Windows 0 内部，CXL 可用的物理内存区域有 CXL ROOT DECODER 管理，因此用户向 region0 目录的 size 写入申请 HPA 的大小，其通过系统调用会调用到 size_store 函数，该函数首先找到 region0 对应的 CXL REGION 设备，然后调用 alloc_hpa 函数进行分配 HPA. alloc_hpa 函数首先获得 CXL ROOT HDM DECODER，然后对申请的 HPA 大小进行检查，检查通过之后从 CXL ROOT HDM DECODER 维护的 CXL Windows 区域里找到一块空闲的区域，然后将 CXL REGION 的 res 指向刚分配的物理区域.
• 设置 CXL REGION 的类型: CXL REGION 支持 RAM 和 PMEM 两种类型，由于这里使用的 CXL Type3 设备是 RAM，其中 endpoint3 作为 CXL Type3 设备，因此在 endpoint3 目录下找到一个空闲的 CXL HDM DECODER，例如上图找到 decoder3.0 进行 HPA 地址解码，向 decoder3.0 目录的 mode 写入 ram，此时通过系统调用会调用到 mode_store 函数，该函数首先找打 decoder3.0 对应的设备，然后将 decoder3.0 对应数据结构 struct cxl_endpoint_decoder 的 mode 成员设置为 ram.

创建 CXL REGION 的第六步是从 CXL Type3 设备上申请可用的 DPA 区域. 由于 CXL HDM DECODER 负责 HPA 到 DPA 的转译工作，因此向 decoder3.0 目录的 dpa_size 写入需要分配 DPA 大小. 由于 DPA 并不暴露给软件，而是与 CXL ENDPOINT 维护的 CXL HDM DECODER 有关，简单来说就是上一个 CXL HDM DECODER 分配一段 DPA 之后，下一个 CXL HDM DECODER 则从其尾部继续分配. 因此向 dpa_size 写入 DPA 的大小之后，通过系统调用会调用到 dpa_size_store 函数，该函数首先找到 decoder3.0 对应的设备，然后对需要申请的 DPA 进行检查，最后调用 cxl_dpa_alloc 函数分配 DPA，可以从该函数的逻辑看出，free_ram_start 里记录了上一次 DPA 已分配的结束地址，因此新的分配从这里开始，最后将分配的 DPA 资源维护在 CXL ENDPOINT HDM DECODER 里.

创建 CXL REGION 的第七步是将 CXL REGION 插入到所有 CXL PORT 维护的 CXL REGION 集合里，其在 CXL 架构里处理逻辑如下:

• A: 该步骤主要向 region0 所在目录的 target0 写入 CXL ENDPOINT HDM DECODER，然后从 CXL ENDPOINT 向上找打所有的 CXL PORT，因此在向 target0 写入 decoder3.0 的时候，系统调用会调用到 store_targetN 函数，该函数首先遍历 CXL BUS 找到 decoder3.0 对应的设备，然后依次找到 CXL ROOT 和 CXL HOST BRIDGE, 然后依次遍历 CXL PORT.
• B: 首先遍历 CXL ENDPOINT PORT，此时会为其新建一个 cxl_region_ref 数据结构，然后将该数据结构指向 CXL REGION，然后将其添加到 CXL PORT 的 regions XARRAY 集合.
• C: 首先遍历 CXL SWITCH PORT，此时会为其新建一个 cxl_region_ref 数据结构，然后将该数据结构指向 CXL REGION，然后将其添加到 CXL PORT 的 regions XARRAY 集合.
• D: 首先遍历 CXL HOST BRIDGE PORT，此时会为其新建一个 cxl_region_ref 数据结构，然后将该数据结构指向 CXL REGION，然后将其添加到 CXL PORT 的 regions XARRAY 集合.
• E: 最后更新 CXL REGION 对应 struct cxl_region_params 的 nr_targets 统计数.

创建 CXL REGION 的第八步是将 CXL REGION HPA 信息写入到 CXL HDM DECODER 相应的寄存器，依次在查找 DPA 过程中，可以找到正确的路径，其在 CXL 架构里的处理逻辑如下:

• A: 首先在 region0 目录下找到 commit 节点，然后向其写入 1 发起设置，其通过系统调用最终调用到 commit_store 函数，该函数首先找到 CXL REGION 设备，然后遍历其所维护的 CXL HDM DECODER，并遍历所有的 CXL HDM DECODER，在遍历过程中找到对应的 CXL HDM DECODER 设备 decoder3.0 和 CXL MEMDEV 设备 mem0.
• B: 接着以此遍历所有的 CXL PORT，目的是找到对应的 CXL HDM DECODER 寄存器的位置，每个 CXL PORT 都将 HDM DECODER 寄存器维护在 cxlhdm->regs.hdm_decoder 里，接着从该寄存器里获得 CXL_HDM_DECODER0_CTRL_OFFSET 寄存器
• C: 接下来将 CXL REGION 的 HPA 基地址和长度信息写入到 CXL HDM DECODER 对应的寄存器里，写入完毕后调用 cxld_await_commit 确认写入成功，一旦成功 HPA 到 DPA 映射就有效.

创建 CXL REGION 的最后一步是为 CXL REGION 创建 CXL DAX REGION 设备和 DAX 设备，以此让 CXL REGION 可以作为多种模式进行使用, 其在 CXL 框架里的处理逻辑如下:

• A: 由于需要 CXL REGION 与多个设备进行绑定，因此向 “/sys/bus/cxl/drivers/cxl_region/bind” 文件写入 region0, 以此触发绑定操作，其会通过系统调用最终调用到 drv_attr_store 函数，该函数首先在 CXL BUS 上找到 region0 对应的 CXL REGION 设备，然后找到设备对应的 CXL REGION 驱动.
• B: 找到 CXL REGION 驱动之后，运行驱动的 PROBE 函数 cxl_region_probe, 该阶段主要调用 cxl_dax_region_alloc 函数创建一个新的 CXL DAX REGION 设备，其属于 CXL BUS，类型为 cxl_dax_region_type, 设备的名字设置为 dax_region0.
• C: 接下来是找到 CXL DAX REGION 设备对应的驱动，通过调用 device_add 函数会依次逻辑，最终找到驱动 “cxl_dax_region”, 以及驱动对应的 PROBE 函数 cxl_dax_region_probe.
• D: 找打 CXL DAX REGION 驱动之后，调用 cxl_dax_region_probe 函数进行初始化, 函数通过调用 alloc_dax_region 函数创建了 DAX REGION 函数，这里涉及到 DAX 框架. 函数对 DAX REGION 设备进行了简单初始化，并为其添加了多个属性.
• E: 创建完 DAX REGION 设备之后，函数调用 devm_create_dev_dax 函数为其创建 DAX 设备，该设备会在 /dev 目录下生成 daxX.Y 设备节点，将设备添加到 DAX BUS, 并将设备的类型设置为 dax_bus_type.
• F: 流程继续调用 device_add 函数为 DAX 设备查找驱动程序，找到对应的驱动程序 kmem, 以及对应的 PROBE 函数 dev_dax_kmem_probe
• G: 流程调用 DAX 驱动程序的 PROBE 函数，对 DAX 进行初始化之后，可以将其加入 DAX 体系, 之后系统可以然后 PAGE CACHE 直接访问 HPA.

通过上面的分析，在 BiscuitOS 启动之后，执行所有的 CXL REGION 步骤，可以看到创建了 “/sys/bus/cxl/devices/region0”、dax_region0、dax0.0 设备，以及 /dev/dax0.0 文件节点, 有了 CXL REGION 之后，接下来操作系统可以根据不同的模式对 CXL REGION 进行使用.

CXL REGION 是通过 CXL 协议管理的动态内存区域，能够灵活扩展系统内存或提供高性能直接访问, 根据使用场景的不同，CXL Region 可配置为 SYSTEM-RAM、DEVDAX 或 FSDAX 三种模式. 以下是每种模式的详细说明、应用场景及对比:

• SYSTEM-RAM: 将 CXL REGION 作为系统主内存(DRAM)的扩展，由操作系统统一管理. 透明扩展物理内存容量, 内存分配与本地 DRAM 无差异，应用程序无需修改即可使用. 操作系统通过 NUMA 节点管理 CXL 内存，可能引入稍高的访问延迟. 支持虚拟内存分页、交换机制，与本地内存行为一致. 其在大内存需求任务: 如虚拟化环境(VM 内存扩展)、内存数据库(如 Redis、SAP HANA), 也可以用于通用计算: 需要透明扩展内存的应用程序，无需针对 CXL 做特殊优化. 该模式无缝集成，无需修改应用程序，支持所有依赖系统内存的标准软件. 但该模式访问延迟可能略高于本地 DRAM(取决于 CXL 链路质量), 另外无法直接利用 CXL 的低延迟特性.
• DEVDAX: 将 CXL Region 映射为字符设备(如 /dev/daxX.Y)，允许应用程序通过 mmap 直接访问内存，绕过文件系统和页缓存. 提供极低延迟、高带宽的裸机内存访问, 支持持久化内存(若硬件支持)，数据在断电后保留. 该模式通过 ndctl 工具创建和管理 DAX 设备，支持原子操作和内存持久性原语(如 pmem_persist). 该模式的应用场景包括: 高性能计算(HPC), 如科学仿真、实时数据分析; 低延迟存储, 持久化内存数据库(如 MongoDB 持久内存引擎); 加速器交互, GPU/FPGA 直接访问 CXL 内存，减少 CPU 干预. 该模式的优点是接近本地内存的访问性能，支持直接内存操作，适合对延迟敏感的任务. 同时其缺点也存在，需要应用程序显式管理内存(无文件系统抽象), 持久化需硬件支持(如 CXL.mem 协议).
• FSDAX: 将 CXL REGION 格式化为支持 DAX 的文件系统(如 EXT4、XFS)，允许文件操作直接映射到内存，跳过传统块设备层. 该模式结合文件系统的易用性与直接内存访问的性能，支持内存持久化(若硬件支持). 在该模式下，文件系统元数据和用户数据均存储在 CXL 内存中，可通过 “mount -o dax” 挂载文件系统，应用程序通过标准文件 API 访问. 其应用场景包括: 高性能文件存储, 如内存文件系统，用于临时数据高速缓存; 持久化应用, 需要文件接口的持久内存应用(如 SQLite 持久内存模式); 混合工作负载, 同时需要文件系统管理和低延迟访问的场景. 该模式的优点包括: 兼容现有文件系统工具和 API, 平衡性能与易用性. 其也包括缺点: 文件系统元数据操作可能引入额外开销, 持久化依赖硬件和文件系统支持.