TPP：面向 CXL 使能的分层内存透明页放置技术

摘要

超大规模应用对内存需求的持续增长，使得内存成为数据中心总体支出的重要组成部分。CXL（Compute Express Link）等一致性接口的出现，为内存扩展提供了有效解决方案，使主内存能够整合多种特性各异的内存技术。本文通过分析 Meta 服务器集群中各类数据中心应用的内存使用模式，证实了将冷页卸载到低速内存层的可行性。然而，若缺乏高效的内存管理机制，这类分层内存系统会严重降低性能。

为此，本文提出一种面向 CXL 内存的操作系统级透明页放置机制（TPP）。TPP 采用轻量级方法识别热页与冷页，并将其放置到合适的内存层，支持主动将本地内存中的页面降级到 CXL 内存，为新页面分配预留空间（新分配页面通常与请求处理相关，具有短生命周期和高热特性）。同时，TPP 能快速将滞留在低速 CXL 内存中的性能关键热页提升到高速本地内存，且最小化采样开销与不必要的页面迁移。TPP 无需应用特定知识，可作为内核版本全局部署。

在支持 CXL 1.1 的新型 x86 CPU 生产服务器集群中，通过多种内存敏感型工作负载对 TPP 进行评估。结果表明，TPP 使分层内存系统性能接近 “全本地内存” 的理想基准（性能差距 < 1%），相比现有 Linux 系统性能提升 18%，相比 NUMA Balancing、AutoTiering 等现有方案性能提升 5%-17%。目前，大部分 TPP 补丁已整合到 Linux v5.18 版本，剩余补丁正处于讨论阶段。

1 引言

数据中心应用对内存需求的激增，叠加 DRAM 成本上升与技术缩放挑战，使得内存成为超大规模数据中心基础设施支出的重要部分。非 DRAM 内存技术为构建分层内存子系统、以更低每 GB 成本扩展内存容量提供了可能，但这类技术通常延迟远高于主内存，若页面在内存层级中放置不当，会严重影响性能。此外，有效利用这些技术需提前掌握应用行为并进行精细调优，这在应用种类繁多且快速迭代的超大规模环境中，资源消耗极高。

CXL（Compute Express Link）通过提供介于 DRAM 与非 DRAM 之间的延迟水平、类 DRAM 带宽和缓存行粒度访问语义，缓解了上述问题。CXL 协议支持新的内存总线接口将内存连接到 CPU，从软件视角看，CXL 内存表现为无 CPU 的 NUMA 节点，其内存特性（带宽、容量、技术类型等）独立于直接连接 CPU 的本地内存，为内存子系统设计提供灵活性与细粒度控制。同时，CXL 内存的类主内存特性为透明页放置创造了条件。然而，Linux 内存管理机制基于同构 CPU 连接 DRAM 设计，在 CXL 内存系统中表现不佳 —— 由于不同内存层访问延迟存在差异，应用性能高度依赖高速内存服务的内存访问比例。

为验证分层内存的收益，需先分析现有数据中心应用的内存访问行为，包括特定时间段内内存的热、温、冷状态占比及页面生命周期长短。现有基于空闲页跟踪（IPT）的特性分析工具存在明显缺陷：需修改内核（生产环境中通常不可行）、持续的访问位采样与分析会带来过高 CPU 和内存开销（难以支持大规模工作集），且无法区分应用对不同类型页面（匿名页、文件页缓存、共享内存等）的敏感度差异。为此，本文开发轻量级用户态工具 Chameleon，利用 CPU 的精确事件采样（PEBS）机制分析应用内存访问行为，生成不同页面类型的内存使用热力图，为多内存层应用性能预测提供依据。

通过 Chameleon 对生产环境中不同服务领域的大规模内存密集型应用进行分析，得出以下关键发现：（1）应用工作集中存在大量可卸载到低速内存层且不影响性能的温页与冷页；（2）匿名页（用于程序栈、堆、mmap 调用）中热页占比显著高于文件备份页；（3）页面访问模式在较长时间内（分钟至小时级）保持稳定，为内核层页放置决策提供充足时间窗口；（4）页面分配与回收会导致物理页热度快速变化，静态页分配策略会严重降低性能。

基于上述发现，本文设计操作系统级透明页放置机制 TPP，实现热页在高速内存层、冷页在低速内存层的高效放置。TPP 包含三大核心组件：（a）轻量级回收机制，将冷页降级到低速 CXL 节点；（b）解耦多 NUMA 系统的分配与回收逻辑，在高速层预留空闲页空间；（c）反应式页提升机制，识别 CXL 内存中的热页并提升到本地内存。此外，TPP 支持基于页面类型的分配策略 —— 优先将敏感匿名页分配到本地内存，文件缓存分配到 CXL 内存，该策略能为特定访问模式的应用提供更优初始状态，加速性能收敛。

在支持 CXL 1.1 的系统中，对占服务器集群主要份额的四类生产工作负载进行测试。结果显示，TPP 使分层内存系统性能接近全本地内存水平，即使本地 DRAM 仅为系统总内存的 20%，部分工作负载仍能保持这一性能。TPP 将有效热内存全部迁移到本地内存，相比默认 Linux 系统性能提升最高 18%，相比 NUMA Balancing、AutoTiering 等主流分层内存方案性能提升 5%-17%。

本文的主要贡献如下：

开发轻量级用户态内存特性分析工具 Chameleon，用于理解工作负载内存消耗行为并评估超大规模数据中心分层内存的应用前景，已开源；
提出面向分层内存系统的高效内存管理机制 TPP，已开源，大部分代码已整合到 Linux 内核 v5.18，剩余代码正处于上游讨论阶段；
在支持 CXL 的分层内存系统中，通过真实生产工作负载对 TPP 进行长期评估，证实 TPP 使分层内存性能接近全本地内存水平，相比默认 Linux 提升最高 18%，相比 NUMA Balancing、AutoTiering 提升 5%-17%；
首次实现并评估可直接部署于超大规模数据中心的端到端 CXL 内存系统。

2 研究背景与动机

2.1 数据中心应用内存需求增长

为构建低延迟服务，内存计算已成为数据中心应用的常态，导致服务器集群内存需求快速增长。随着 CPU 与 DRAM 技术迭代，内存在机架级功耗与总拥有成本（TCO）中的占比持续上升（如图 3 所示），内存成本与功耗优化成为数据中心降本增效的关键。

2.2 同构服务器设计的扩展性挑战

当前服务器架构中，内存子系统设计完全依赖 CPU 支持的内存技术，存在诸多限制：（1）内存控制器仅支持单一代际内存技术，无法混合搭配不同成本、带宽与延迟特性的内存；（2）内存容量需按 2 的幂次扩展，难以实现细粒度容量配置；（3）每代 DRAM 的带宽 - 容量组合有限，为获取更高带宽常需过度配置内存容量。这种 CPU 与内存的强耦合限制了高效内存层级的设计，导致计算、网络、内存资源利用率低下。此外，现有支持内存扩展的总线接口多为厂商专有，跨 CPU 兼容性差，且延迟高、缺乏一致性，难以满足超大规模数据中心需求。

2.3 CXL 对分层内存系统的支撑作用

CXL 是基于 PCIe 的开放行业互联标准，支持主机处理器与设备（加速器、内存缓冲器、智能 I/O 设备等）之间的高速低延迟通信，同时扩展内存容量与带宽。CXL 提供字节可寻址内存空间，支持通过标准内存分配 API 进行透明分配，实现缓存行粒度访问与硬件维护的一致性。随着 PCIe 5.0 的普及，CPU 与 CXL 互联带宽将接近双路服务器跨插槽互联带宽，CXL 内存访问延迟与 NUMA 远程访问延迟相当（仅比普通 DRAM 高 50-100 纳秒）。这种类 NUMA 特性与类主内存访问语义，使 CXL 内存成为数据中心分层内存系统中低速层的理想选择。

目前，主流芯片厂商均在开发并集成 CXL 解决方案，支持 CXL 所需的工具、驱动与操作系统修改已开源，避免了对单一供应商的依赖。CXL 突破了传统内存子系统的限制，允许根据工作负载需求灵活设计内存子系统的带宽、容量与成本组合，实现计算与内存资源的独立扩展，提升闲置资源利用率。

2.4 CXL 分层内存系统的应用前景

数据中心工作负载极少持续使用全部内存，应用常分配大量内存但访问频率低。本文对 Meta 生产服务器集群中四类典型应用的分析显示，任意两分钟内，应用已分配内存中 55%-80% 处于空闲状态。将这些冷页迁移到低速内存层，可为主内存释放空间以容纳更多热页，提升应用性能，同时通过 “小容量高速本地内存 + 大容量低成本 CXL 内存” 的灵活服务器设计，降低总拥有成本（TCO）。

为简化表述，本文将直接连接 CPU 的内存称为 “本地内存”，CXL 连接的内存称为 “CXL 内存”（CXL 内存可采用 DRAM、NVM、LPDRAM 等任意技术）。

3 数据中心应用内存特性分析

为明确分层内存系统在超大规模应用中的适用场景，本文开发轻量级用户态内存访问行为分析工具 Chameleon。该工具需满足以下需求：可在现有生产服务器上部署，不干扰运行中应用，无需修改内核；性能开销低，不影响生产应用行为；能分析应用内存访问的关键特征（热 / 温 / 冷页占比、页面在各热度层的停留时间、访问频率等）。实际使用中，仅需在少量服务器上运行数小时，即可完成对某类应用的特性分析。

3.1 Chameleon 工具设计

Chameleon 包含 Collector（收集器）与 Worker（分析器）两个组件，分别运行于独立线程：

Collector（收集器）：利用现代 CPU 的 PEBS 机制，采集与内存访问相关的硬件性能事件，包括需求加载的末级缓存（LLC）缺失事件（MEM_LOAD_RETIRED.L3_MISS）与需求存储的 TLB 缺失事件（MEM_INST_RETIRED.STLB_MISS_STORES，受硬件限制，无精确的存储 LLC 缺失事件）。采样记录包含内存访问事件对应的进程 ID（PID）与虚拟内存地址。

采样率需在准确性与性能开销间权衡：高频采样提升准确性，但会增加应用线程开销与 Worker 线程 CPU 消耗。在 Meta 集群中，默认配置为每 200 个事件采样 1 次，实现开销与准确性的平衡。

为提升灵活性，Collector 将所有 CPU 核心划分为多个组，每次仅对一个或多个核心组启用采样，每 5 秒（默认 mini_interval）轮换核心组。这种 “轮循采样” 机制可进一步调节开销与准确性，还支持为不同核心组配置不同采样事件（如对延迟敏感应用采样半数核心，对存储密集型应用分核心组分别采样加载与存储事件）。

Collector 将采样数据写入两个哈希表之一，每 1 分钟（默认 interval）唤醒 Worker 处理当前哈希表数据，并切换到另一个哈希表存储下一时段采样数据。

Worker（分析器）：运行于独立线程，读取页面访问信息并生成内存访问行为分析结果。将采样记录中的地址视为虚拟页访问（页面大小由操作系统定义，支持 4KB 普通页、2MB/1GB 大页等）。为同时分析虚拟地址空间与物理地址空间的特性，Worker 会将采样虚拟页映射到对应的物理页；若应用工作集极大（如 TB 级），可禁用物理地址转换，仅分析虚拟地址空间访问模式。

对于每个页面，Worker 用 64 位位图记录其在各时间间隔内的活跃状态（活跃则置位），每个时间间隔结束后位图左移 1 位以记录新间隔状态。若需捕捉页面访问频率，可配置每个时间间隔占用多位，但会缩短历史记录长度。生成统计结果并报告后，Worker 进入休眠状态。

在生产环境中，Chameleon 仅在 CPU 与内存使用率低于 80% 的服务器上运行，未观察到对服务性能的影响，CPU 开销控制在单个核心的 3%-5% 以内。仅在内存带宽敏感且 CPU 核心饱和的合成工作负载中，因 Chameleon 与应用竞争 CPU 资源，性能损失约 7%。

3.2 生产工作负载概述

利用 Chameleon 对 Meta 生产服务器集群中四类长期运行、处理真实流量的内存密集型应用进行分析，这些应用覆盖不同服务领域，占服务器集群份额较大，具有代表性：

Web 服务：运行虚拟机处理 Web 请求，包括基于 HHVM 的 Web1 和基于 Python 的 Web2；
缓存服务（Cache）：分布式内存对象缓存服务，位于 Web 层与数据库层之间，提供低延迟数据查询；
数据仓库（Data Warehouse）：统一计算引擎，在计算集群上并行处理数据，协调执行长时间运行的复杂批处理查询；
广告服务（Ads）：计算密集型工作负载，读取内存数据并执行机器学习计算。

3.3 页面热度特征

数据中心应用的已分配内存中，大量页面在数分钟内保持冷态（如图 7 所示）。Web、Cache、Ads 服务虽占用系统 95%-98% 的内存容量，但在任意两分钟内，平均仅使用 22%-80% 的已分配内存；数据仓库作为计算密集型工作负载，虽占用服务器几乎全部内存，但两分钟内仅 20% 的被访问内存为热页。

结论：数据中心应用的被访问内存中，大量页面在分钟级时间内保持冷态，若页放置机制能将这些冷页迁移到低速内存层，分层内存系统将显著受益。

3.4 不同页面类型的热度差异

应用根据逻辑与执行需求使用不同类型页面，但匿名页（anon）的热页占比显著高于文件页（file）（如图 8 所示）。以 Web 服务为例，两分钟内匿名页热页占比为 35%-60%，而文件页热页占比仅为 3%-14%。

缓存服务使用 tmpfs 实现高速内存查询，匿名页主要用于查询处理，文件页占热内存比例较高，但 Cache1 的匿名页两分钟内访问占比为 40%，文件页仅为 25%；Cache2 在两分钟内匿名页与文件页访问占比接近，但一分钟内匿名页热页占比（43%）仍高于文件页（30%）。

数据仓库与广告服务的匿名页用于计算，文件页用于存储中间计算结果，因此热内存几乎全部为匿名页，文件页多为冷页。

结论：短时间间隔内，匿名页中热页占比显著高于文件页，页放置机制需考虑页面类型差异。

3.5 页面类型使用的时间稳定性

Web 服务启动时，需将虚拟机二进制文件与字节码加载到内存，此时文件缓存占内存比例较高；随着运行时间增加，匿名页占比逐渐上升，文件缓存被回收以释放空间（如图 9a 所示）。

缓存服务主要使用文件缓存进行内存查询，文件页占已分配内存的 70%-82%；若匿名页需求增长，文件页会被回收以容纳新匿名页（如图 9b、9c 所示）。

数据仓库的匿名页占已分配内存的 85%，文件页占 15%，且两类页面占比在运行期间保持稳定（如图 9d 所示）。

结论：尽管匿名页与文件页占比可能随时间变化，但应用的页面类型使用模式总体稳定，页放置机制需结合页面类型动态调整策略。

3.6 页面类型对性能的影响

内存密集型应用的吞吐量随内存利用率提升而增加，但不同工作负载对页面类型的敏感度存在差异（如图 10 所示）。例如，Web 服务吞吐量随匿名页利用率提升而显著增长；Cache1 的匿名页使用量在生命周期内固定，因此匿名页与文件页利用率对吞吐量无明显影响；Cache2 的高吞吐量对应较高的匿名页利用率；数据仓库的文件页使用量固定，匿名页利用率达到峰值时吞吐量最高。

结论：工作负载对不同页面类型的敏感度存在差异，且随时间变化，页放置机制需动态适配这种敏感度差异。

3.7 冷页重访问时间特征

冷页可能在后续时间被重新访问，不同工作负载的冷页重访问时间差异显著（如图 11 所示）。Web 服务的冷页中，80% 在十分钟内被重新访问，表明 Web 服务常复用早期分配的页面；缓存服务的冷页也有大量在十分钟内重访问，随机卸载冷页会影响性能；数据仓库的热文件页中，仅 20% 在十分钟内被重新访问，其余为新分配页面。

结论：不同工作负载的冷页重访问时间差异大，页放置机制需主动将重访问的冷页（变为热页）迁移到高速内存层，避免高访问延迟。

综上，数据中心应用存在大量冷页且访问模式稳定，分层内存系统具有广阔应用前景，而高效的页放置机制是发挥分层内存优势的关键。

4 TPP 设计原则

随着 CXL 技术的普及，超大规模数据中心开始采用 CXL 使能的异构分层内存系统，不同内存层性能特性差异显著。为优化这类系统性能，需设计透明页放置机制（TPP），实现不同热度页面在对应内存层的高效放置。设计 TPP 需解决三个核心问题：TPP 的实现层级、页面热度检测方法、CXL 内存的抽象方式。本节将阐述这些设计选择的依据与权衡。

4.1 实现层级选择

透明页放置机制可在用户态或内核态实现：

用户态实现：可基于 Chameleon 类工具检测页面热度，通过move_pages()等用户态 API 实现 NUMA 迁移。但该方式存在明显缺陷：用户态与内核态上下文切换带来额外开销；需在用户态管理页面历史信息，增加处理开销；页面信息存储的内存开销随工作集规模增长而扩大，难以支持大规模场景。因此，用户态实现仅适用于短时间、小范围的性能分析，无法满足全生产集群的持续运行需求。
内核态实现：内核态实现无需上下文切换，可直接利用内核现有内存管理组件（如 LRU 链表），开销更低、复杂度更小、性能更优。因此，TPP 选择在内核态实现。

4.2 页面热度检测方法

页面热度检测有多种候选技术，需结合可行性、开销与兼容性综合选择：

PEBS（精确事件采样）：PEBS 可在硬件层面采集内存访问事件，但存在明显局限：不同 CPU 厂商的 PEBS 计数器不兼容，难以实现跨硬件平台的通用内核级热度检测；CPU 支持的性能计数器数量有限，且通常需暴露给用户态；即使优化后，PEBS 采样在高压力工作负载中仍存在较高开销，不适合作为 TPP 的常驻组件。
页面中毒（Page Poisoning）：通过对内存区域中的部分页面进行采样与 “中毒” 跟踪访问事件，是检测热页 / 冷页的常用方法。基于 IPT（空闲页跟踪）的页面中毒技术需频繁清除页面访问位并刷新 TLB，导致严重性能下降；Thermostat 通过 2MB 大页粒度采样优化性能，但仅适用于大页场景，而 TPP 需支持任意页面大小（生产环境中应用常使用 2MB/1GB 大页存储代码、静态数据等热数据，需避免其被降级到 CXL 内存）。
NUMA Balancing（AutoNUMA）：NUMA Balancing 支持任意页面大小，通过采样页面访问生成次要页错误来判断页面热度。但对高频访问页面频繁触发页错误会带来过高开销。TPP 对该技术进行优化：仅将次要页错误作为 CXL 内存的热度检测机制（CXL 内存主要存储温页与冷页，采样开销低）；本地内存的冷页检测则复用 Linux 现有 LRU 老化机制（轻量级且高效）。

实验证实，结合 LRU 与 NUMA Balancing 的热度检测方法可有效识别 CXL 内存中的热页，且开销接近零。

4.3 CXL 内存的抽象方式

CXL 内存可通过现有内存交换机制（如 zswap）作为交换空间存储冷页，但该方式存在关键缺陷：会丧失 CXL 的核心优势 —— 缓存行粒度的加载 / 存储访问语义。交换空间抽象下，访问交换页面需触发主要页错误并读取整个页面，导致有效延迟远超 200 纳秒，使 CXL 内存失去竞争力。

因此，TPP 选择将 CXL 内存视为常规内存而非交换空间，应用可通过加载 / 存储指令直接访问 CXL 内存中的温页与冷页，避免页错误开销。需注意的是，基于交换的内存管理机制（如 TMO）与 TPP 并非竞争关系，而是互补：TMO 运行于用户态，通过反馈驱动回收内存；TPP 运行于内核态，优化本地内存与 CXL 内存间的页放置，二者可协同工作。

5 TPP 机制设计

高效的页放置机制需实现：将冷页卸载到 CXL 内存，将 CXL 内存中的热页提升到本地内存；支持异构内存技术，适应 CXL 内存的无 CPU NUMA 节点特性；避免分配因回收缓慢而停滞，同时考虑应用对页面类型的敏感度。基于此，TPP 设计包含四大核心模块：轻量级 CXL 降级机制、分配 - 回收解耦、CXL 热页提升、页面类型感知分配。

5.1 轻量级 CXL 降级机制

Linux 默认将页面分配到进程运行 CPU 的本地内存节点，当本地内存节点满时，通过交换（swap）回收页面。在 NUMA 系统中，若本地内存回收缓慢，新分配页面会被分配到 CXL 节点，导致性能下降。

TPP 的降级机制优化：本地内存触发回收时，不执行交换，而是将回收候选页面加入独立降级列表，异步迁移到 CXL 节点（迁移速度远快于交换）。降级候选页面通过 Linux 现有 LRU 机制选择，优先选择非活跃页面，降低热页误降级风险。若 CXL 节点内存不足导致迁移失败，再 fallback 到默认交换回收机制；CXL 节点本身仍使用默认交换回收（CXL 节点性能敏感度低）。

若系统存在多个 CXL 节点，根据 CPU 到各 CXL 节点的距离选择降级目标（距离越近延迟越低）。该静态距离策略虽简单，但在实验中表现出良好有效性。

5.2 分配与回收解耦

Linux 为每个内存节点的内存域维护三个水位线（min、low、high）：当空闲页低于 low 水位线时，触发回收；直到空闲页回升到 high 水位线，才允许新分配。在高分配速率场景下，回收速度难以跟上分配速度，导致本地内存频繁停止分配，新页面被分配到 CXL 节点，性能下降。

TPP 通过解耦 “回收停止条件” 与 “分配允许条件”，在本地节点主动维持空闲页余量：

回收逻辑：本地节点的回收持续运行，直到空闲页达到 “降级水位线”（demotion_watermark）；
分配逻辑：只要空闲页达到 “分配水位线”（allocation_watermark），即可允许新分配。

其中，降级水位线始终高于分配水位线与 low 水位线，确保本地节点预留充足空闲页。该设计的优势在于：（1）突发分配（通常与请求处理相关，短生命周期、高热）可直接分配到本地内存；（2）本地内存有充足空间接收从 CXL 节点提升的热页。

为适应不同应用特性，TPP 提供用户态 sysctl 接口（/proc/sys/vm/demote_scale_factor），控制本地节点触发回收的空闲页阈值，默认值为 2%（即空闲页低于本地节点容量的 2% 时启动回收）。管理员可结合工作负载监控工具动态调整该值：若应用分配需求高且冷页占比大，可提高阈值以增强回收积极性；若应用热页占比超过本地节点容量，需降低阈值避免热页频繁迁移。

5.3 CXL 热页提升机制

本地内存压力可能导致新页面被分配到 CXL 节点，且降级到 CXL 节点的页面可能重新变为热页。若缺乏提升机制，这些热页会长期滞留 CXL 节点，严重影响性能。TPP 通过增强 Linux NUMA Balancing 实现高效热页提升。

5.3.1 面向 CXL 的 NUMA Balancing 优化

原生 NUMA Balancing 会采样所有内存节点的页面，对远程访问页面进行提升，但该机制在 CXL 系统中存在冗余：（1）本地内存的热页无需采样，采样会增加不必要的页错误开销；（2）无需将本地内存热页提升到其他节点。因此，TPP 将 NUMA Balancing 采样范围限制为 CXL 节点，仅分析 CXL 节点页面的访问情况。

提升 CXL 节点热页时，TPP 忽略本地节点的分配水位线检查，通过增加本地节点内存压力，触发冷页回收以容纳提升的热页。若系统存在多个本地节点，优先选择进程当前运行的本地节点；若应用跨多个本地节点，选择内存压力最低的节点作为提升目标。

5.3.2 避免 “乒乓效应” 的热页识别

原生 NUMA Balancing 在检测到页面访问时立即提升，未考虑页面活跃状态，导致低频访问页面被误提升到本地节点。这些页面随后可能因本地内存压力被降级回 CXL 节点，形成 “乒乓效应”，浪费带宽与 CPU 资源。

TPP 通过页面 LRU 状态判断页面活跃度，避免误提升：

若 CXL 节点的采样页面处于非活跃 LRU 链表，不立即提升（可能为低频访问页）；
仅当页面处于活跃 LRU 链表时，才将其视为提升候选。

但 CXL 节点通常内存压力较低，回收不频繁，非活跃 LRU 链表中的页面可能无法自动迁移到活跃链表，导致热页被遗漏。为此，TPP 补充优化：当采样到非活跃 LRU 链表中的页面访问时，立即将页面标记为 “已访问” 并迁移到活跃 LRU 链表；若该页面在后续采样中再次被访问（此时已处于活跃链表），则执行提升。

该设计为页面提升增加 “滞后性”，结合 Linux 为匿名页与文件页维护独立 LRU 链表的特性，使不同类型页面按自身活跃度独立调整提升速率，加速热页在内存层间的收敛。

5.4 页面类型感知分配

上述页放置机制对页面类型无差别处理，但部分应用可通过类型感知分配进一步优化性能。例如，应用预热阶段常进行大量文件 I/O，生成的文件缓存多为冷页，若这些文件缓存占据本地内存，会导致匿名页被分配到 CXL 节点，后续需频繁提升，增加迁移开销。

TPP 支持可选的 “页面类型感知分配” 策略：

匿名页：优先分配到本地内存（匿名页通常为热页，对性能敏感）；
文件缓存（含 tmpfs）：优先分配到 CXL 节点（文件缓存多为冷页，对延迟敏感度低）。

当该策略启用时，应用生命周期内生成的文件缓存初始分配到 CXL 节点；若文件缓存变为热页并被 NUMA Balancing 采样到，再提升到本地内存。该策略使小容量本地内存 + 大容量 CXL 内存的系统能高效支持文件缓存密集型应用，同时保持高性能。

5.5 TPP 可观测性设计

为评估 TPP 有效性并排查生产环境问题，TPP 引入多组统计计数器，通过/proc/vmstat接口暴露给用户态，主要包括：

降级统计：成功降级的匿名页与文件页数量、降级失败次数及原因；
提升统计：CXL 节点页面采样数、提升尝试次数、成功提升的匿名页与文件页数量；
乒乓效应跟踪：通过页面标志位（PG_demoted）标记降级页面，统计降级后被提升的页面数量（该值过高表明存在乒乓效应）；
提升失败分类：按失败原因（本地节点内存不足、页面引用异常、系统级内存紧张等）统计提升失败次数，辅助定位问题。

6 评估

本节通过生产环境工作负载对 TPP 进行全面评估，验证其在 CXL 分层内存系统中的性能表现，主要回答三个问题：（1）TPP 在内存层间页面分布与性能提升方面的有效性；（2）TPP 各组件的贡献；（3）TPP 与现有主流方案的性能对比。

6.1 实验环境

硬件平台：采用支持 CXL 1.1 的预生产 x86 CPU，搭配 FPGA-based CXL 内存扩展卡，CXL 内存以无 CPU NUMA 节点形式呈现。当前 FPGA 卡的延迟比目标产品高约 250ns，用于功能验证；主流 x86 CPU 厂商确认，最终产品的 CXL 内存访问延迟将接近双路服务器的远程 NUMA 访问延迟。
系统配置：基于双路服务器构建模拟 CXL 系统，配置 1 个含活跃 CPU 核心的本地内存节点与 1 个 CXL 节点；基准环境（全本地内存）通过禁用一个 CPU 插槽的内存与核心，仅保留单个本地节点实现。
内存配置：采用两种内存容量比例：（1）2:1（本地内存：CXL 内存）：模拟当前生产环境，本地内存可容纳全部热页；（2）1:4：模拟内存受限场景，本地内存仅能容纳部分热页，测试 TPP 的极限性能。
工作负载：选择 Web1、Cache1、Cache2、Data Warehouse 四类生产工作负载，覆盖不同服务领域，均处理真实流量。
对比方案：默认 Linux 系统、NUMA Balancing、AutoTiering、TMO（Transparent Memory Offloading）。
性能指标：应用吞吐量（核心指标）、本地内存访问占比（底层支撑指标），实验中均关闭磁盘交换，系统内存充足。

6.2 TPP 有效性评估

6.2.1 默认生产环境（2:1 配置）

Web1：Web1 启动时需加载大量文件到内存，默认 Linux 的回收速度比 TPP 慢 44 倍，导致本地内存很快被文件缓存占满，新匿名页被分配到 CXL 节点且无法提升。默认 Linux 的本地内存访问占比仅 22%，吞吐量比基准低 16.5%。TPP 通过主动降级冷文件页，释放本地内存空间，使 92% 的匿名页分配到本地内存，本地访问占比提升至 90%，吞吐量仅比基准低 0.5%（如图 14a 所示）。
Cache1：Cache1 的匿名页与文件页占比稳定，匿名页初始分配到本地内存。默认 Linux 中，仅 8% 的热页滞留 CXL 节点，性能接近基准（吞吐量损失 3%）；TPP 通过提升所有滞留热页，使本地访问占比进一步提高，吞吐量损失降至 0.1%（如图 14b 所示）。
Cache2：Cache2 的匿名页虽多分配到本地内存，但两分钟内仅 75% 的匿名页为热页。TPP 可识别并降级冷匿名页，释放空间以提升热文件页，本地访问占比从默认 Linux 的 78% 提升至 91%，吞吐量损失从 2% 降至 0.4%（如图 14c 所示）。
Data Warehouse：数据仓库的文件页多为冷页，仅 1/3 匿名页为热页，默认 Linux 已能将大部分热页保留在本地内存，因此 TPP 与默认 Linux 性能接近（吞吐量损失均为 0.5%-0.7%）。但 TPP 通过优化匿名页与文件页分布，使本地匿名页占比从 67% 提升至 94%，本地访问占比提高 4%（如图 14d 所示）。

6.2.2 大规模 CXL 扩展（1:4 配置）

该配置模拟 “小本地内存 + 大 CXL 内存” 的低成本场景，仅对 Cache 服务进行评估（Web 与数据仓库在该配置下不具生产实用性，但 TPP 仍能使其性能接近基准）。

Cache1：默认 Linux 中，文件页占据几乎全部本地内存，85% 的匿名页滞留 CXL 节点，吞吐量比基准低 14%。TPP 通过高效提升，将 97% 的 CXL 匿名热页（一分钟内访问）迁移到本地内存，同时降级冷文件页，使本地访问占比稳定在 85%，吞吐量损失仅 0.5%（如图 15a 所示）。
Cache2：默认 Linux 的吞吐量损失达 18%，本地匿名页占比仅 14%。TPP 将 80% 的 CXL 匿名热页提升到本地内存，尽管 41% 的内存访问仍来自 CXL 节点（文件缓存），但吞吐量损失降至 5%（如图 15b 所示）。

6.2.3 不同 CXL 延迟下的 TPP 表现

为验证 TPP 对 CXL 延迟变化的适应性，在 2:1 配置下，为 Cache2 设置不同 CXL 延迟（220ns-300ns）。结果显示（如图 16 所示）：

无论 CXL 延迟如何，TPP 仅允许 4%-5% 的热页留在 CXL 节点，而默认 Linux 的 CXL 热页占比为 22%-25%；
默认 Linux 的平均内存访问延迟比 TPP 高 7 倍，吞吐量损失是 TPP 的 2.2-2.8 倍。

这表明 TPP 的热页识别与提升机制不受 CXL 延迟变化影响，始终能将热页高效迁移到本地内存。

6.3 TPP 组件贡献评估

以 Cache1 的 1:4 配置为例，分析 TPP 各核心组件的作用。

6.3.1 分配 - 回收解耦的影响

若关闭该特性，本地节点的回收触发延迟，高内存压力下，TPP 无法及时为提升页面预留空间，新分配页面也只能被分配到 CXL 节点：

分配速率：无 decoupling 时，本地节点分配速率受回收速率限制，波动较大；有 decoupling 时，本地节点分配速率在 95 百分位提升 1.6 倍（如图 17a 所示）；
提升速率：无 decoupling 时，本地节点内存频繁不足，提升几乎停滞；有 decoupling 时，提升速率稳定在 50KB/s，峰值达 1.2MB/s（99 百分位），确保 CXL 热页及时迁移，吞吐量损失从 12% 降至 0.5%（如图 17b 所示）。

6.3.2 活跃 LRU 热页识别的影响

仅将活跃 LRU 页面作为提升候选，可有效减少不必要的提升：

提升速率降低 11 倍，降级后再提升的页面数量减少 50%；
尽管降级速率降低 4%，但本地节点空闲页利用率提升，提升成功率提高 48%；
本地内存访问占比提高 4%，吞吐量提升 2.4%；
性能收敛时间仅增加 5 分钟，对整体性能影响可忽略（如图 18 所示）。

6.3.3 页面类型感知分配的影响

启用该策略后，Web 与 Cache 服务在小本地内存配置下仍能接近全本地性能（如表 2 所示）：

Web1（2:1）：本地访问占比 97%，吞吐量损失 0.5%；
Cache1（1:4）：本地访问占比 85%，吞吐量损失 0.2%；
Cache2（1:4）：本地访问占比 72%，吞吐量损失 1.5%。

该策略通过初始分配优化，减少后续迁移开销，为特定应用提供更优性能基线。

6.4 与现有方案的性能对比

6.4.1 TPP vs. NUMA Balancing & AutoTiering

Web1（2:1 配置）：
- NUMA Balancing：回收速度比 TPP 慢 42 倍，提升速率慢 11 倍，本地访问占比仅 20%，吞吐量损失 17.2%，且因冗余采样，CPU 开销比 TPP 高 2%；
- AutoTiering：虽回收速度较快，但分配 - 回收耦合导致预留缓存很快耗尽，CXL 访问占比达 70%，吞吐量损失 13%；
- TPP：吞吐量损失仅 0.5%，显著优于两种方案（如图 19a 所示）。
Cache1（1:4 配置）：
- NUMA Balancing：本地内存压力下停止提升，本地访问占比仅 46%，吞吐量损失 10%；
- AutoTiering：无法在 1:4 配置下运行（预热后查询阶段频繁崩溃）；在 2:1 配置下，TPP 的本地访问占比比 AutoTiering 高 10%，吞吐量提升 7%（如图 19b 所示）。

6.4.2 TPP vs. TMO

TMO 通过监控应用资源 stall 情况，基于压力 stall 信息（PSI）将冷页卸载到交换空间，但该机制在 CXL 系统中存在局限：

内存利用率：TMO 仅能利用 CXL 内存的 45%（Web1）、61%（Cache1）、7%（Data Warehouse），而 TPP 能利用 83%、92%、87%；
性能开销：TMO 的交换机制需页错误触发页面加载，导致频繁 stall，而 TPP 无此开销。

TPP 与 TMO 可协同工作：TMO 通过交换释放系统级内存，为 TPP 的页面迁移提供更多空间，降低迁移失败率。例如，Web1（2:1 配置）中，TPP+TMO 的迁移失败率从 20 页 / 秒降至 5 页 / 秒，CXL 访问占比从 3.1% 降至 2.7%（如表 3 所示）；同时，TPP 将 TMO 的交换转化为 “降级 - 交换” 两阶段过程，减少 TMO 的进程 stall（从 70% 降至 40%），内存节省提升 3%（如表 4 所示）。

7 讨论与未来工作

TPP 为第一代 CXL 分层内存系统的生产部署提供了可行方案，但随着技术发展，仍有以下方向值得探索：

7.1 多租户云环境的分层内存

在多租户云环境中，TPP 需支持不同租户对内存层的竞争性共享。若本地内存占比高，现有机制可满足需求；但当租户具有不同优先级与 QoS 需求时，TPP 的无差别策略可能导致性能次优。未来需在 TPP 基础上集成 QoS 感知的内存管理，根据租户优先级分配本地内存资源，确保高优先级租户的性能保障。

7.2 面向带宽扩展的分配策略

对于内存带宽密集型应用，CPU-DRAM 带宽常成为瓶颈。CXL 的额外带宽可通过将部分带宽敏感、延迟不敏感的页面分配到 CXL 内存，实现带宽扩展。未来需研究如何识别这类页面，确定最优分配比例，甚至探索硬件支持以提升识别精度，实现 “延迟 - 带宽” 双维度的页放置优化。

7.3 硬件辅助的页放置优化

硬件特性可进一步提升 TPP 性能：（1）CXL ASIC 上的内存侧缓存与预取器，可降低 CXL 内存的有效延迟；（2）硬件支持的页面迁移，可减少 CPU 参与的迁移开销。当前 TPP 的迁移带宽为 4-16MB/s（1-4K 页 / 秒），远低于 CXL 链路带宽，CPU 开销可忽略；但对于 “极小本地内存 + 极大 CXL 内存” 的极端配置，硬件辅助迁移将成为关键优化点。

8 相关工作

8.1 分层内存系统

随着低延迟非 DRAM 技术的发展，异构内存系统成为研究热点，已有大量工作探索利用 NVM 扩展主内存。CXL 技术的出现，为分层内存系统提供了介于 DRAM 与 NVM 之间的中间层，实现灵活且高性能的服务器设计，主流厂商均在推进 CXL 分层内存系统的研发与部署。

8.2 分层内存的页放置技术

现有页放置技术可分为三类：

硬件辅助：依赖特定硬件特性实现页热度检测与迁移，但跨平台兼容性差，难以大规模部署；
应用引导：需应用修改代码或提供内存访问信息，增加开发成本，无法适配现有应用；
透明页放置：通过分析物理或虚拟地址空间的访问模式识别热页，但常因 TLB 失效、中断等导致高开销。

TPP 与现有透明页放置技术的核心差异在于：（1）复用 Linux 现有 LRU 机制与 NUMA Balancing，无需额外硬件支持，开销低；（2）解耦分配与回收逻辑，确保本地内存预留充足空间；（3）结合页面类型感知，优化初始分配与迁移策略。

基于交换的内存管理（如 TMO）将 CXL 内存视为交换空间，需页错误触发页面加载，而 TPP 将 CXL 内存视为常规内存，支持直接访问，避免页错误开销。AutoTiering 等方案虽也采用背景迁移与 NUMA Balancing 优化，但缺乏分配 - 回收解耦与页面类型感知，在高压力场景下性能劣于 TPP。

8.3 内存解聚

内存解聚技术将远程主机的内存作为共享资源池，主要基于 RDMA 网络，延迟远高于 CXL（微秒级 vs 纳秒级），其内存管理机制与 TPP 正交 —— 可将 CXL 内存与远程解聚内存作为不同内存层，分别通过 TPP 与解聚管理方案优化。

9 结论

本文通过轻量级用户态工具 Chameleon，分析数据中心应用的内存使用模式，证实了 CXL 分层内存系统的应用前景。基于分析结果，设计操作系统级透明页放置机制 TPP，实现热页在本地内存、冷页在 CXL 内存的高效放置。TPP 无需应用特定知识，通过轻量级降级、分配 - 回收解耦、精准热页提升与页面类型感知，最小化性能损失与开销。

在支持 CXL 的生产服务器集群中，通过多种工作负载评估表明：TPP 使分层内存系统性能接近全本地内存（差距 < 1%），相比默认 Linux 提升 18%，相比 NUMA Balancing、AutoTiering 提升 5%-17%。大部分 TPP 代码已整合到 Linux 内核，为超大规模数据中心的 CXL 分层内存部署提供实用解决方案。

ASPLOS·23 '25 TPP