PACT: A Criticality-First Design for Tiered Memory¶

论文链接

一句话总结¶

PACT 的核心观点很直接：分层内存中的页放置不能只看访问频率，而应该看这个页到底让 CPU 卡了多少时间。 为此，论文提出了 PAC（Per-page Access Criticality）这一在线页级性能关键性指标，并围绕它设计了一个 criticality-first 的 tiered memory 系统。

这篇论文在解决什么问题？¶

这篇论文要解决的是分层内存系统里一个很常见、但一直没被真正解决好的问题：哪些页应该放在快内存（DRAM），哪些页可以留在慢内存（NUMA / PMem / CXL）？

现有方案大多依赖“热度”——也就是页访问频率、访问次数、访问新近性等指标。直觉上这似乎合理：访问更频繁的页就更应该放在快内存里。但论文指出，这其实是一个长期存在的错位假设：

访问频繁，并不一定意味着这个页真的影响性能；
有些页虽然访问次数不高，但一旦访问就会强烈拖慢 CPU；
性能代价真正取决于访问模式、访存延迟、以及 memory-level parallelism（MLP）等因素，而不是频率本身。

因此，PACT 想解决的不是“如何更准确地找热点页”，而是：

如何在线、页粒度地量化每个页对应用性能的真实影响，并据此决定 tiered memory 中的迁移和放置策略。

背景¶

随着 DRAM 扩展变慢、工作负载越来越吃内存，数据中心里越来越多系统采用分层内存：

快层是 DRAM；
慢层可能是 NUMA 远端内存、持久内存，或者 CXL 扩展内存；
CXL 又进一步推动了 memory disaggregation 和 memory pooling 的使用。

但慢层内存通常要比 DRAM 慢很多。论文提到，CXL 访问延迟常常仍然有 2–3× 的差距。于是问题就变成：

快内存容量有限；
慢内存容量更大但延迟高；
必须把“真正关键”的页放进 DRAM，才能保证性能。

这件事如果只用 hotness 去做，常常会产生两个问题：

把高频但不关键的页放进 DRAM，浪费快内存空间；
把真正会拖慢 CPU 的页留在慢层，导致 stall 时间居高不下。

论文认为，tiered memory 应该从“hotness-first”转向“criticality-first”，也就是从“谁访问多”转向“谁更伤性能”。

核心思路¶

PACT 的核心设计可以概括成三层：

定义一个页粒度性能关键性指标：PAC；
在线估计每个页的 PAC，而不是离线分析；
让页迁移策略完全围绕 PAC 来设计，而不是围绕热度。

PACT 不是在现有 hotness-based 方案上“补一个 criticality hint”，而是把 criticality 上升为一等设计原则。论文认为，只有这样，分层内存的页迁移策略才真正和应用性能目标对齐。

关键机制 / 方法细节¶

1. PAC：Per-page Access Criticality¶

论文提出的 PAC，本质上是一个问题：

某个页上的访问，到底给 CPU 带来了多少 stall 成本？

这和 page hotness 的差别非常大。Hotness 只看“访问了多少次”，而 PAC 想衡量“这些访问是否真的阻塞了 CPU 的执行”。

作者给出的洞察是：

访问频率相同的两个页，可能性能影响完全不同；
比如 pointer-chasing 场景下，访问串行、MLP 低，一个慢访问就可能直接暴露成 CPU stall；
而数组流式访问虽然次数很多，但由于并行度高、预取充分，延迟可能被摊薄，对性能影响反而小得多。

论文在动机实验里给出了很直观的结果：同样访问频率的页，stall cost 可以相差 4× 到 65×。这基本直接判了“频率 = 关键性”这个假设死刑。

2. 关键不是“有多少 miss”，而是“miss 的 stall 代价”¶

PACT 并不是简单把 LLC miss 次数换个名字，而是明确引入了 per-tier stall modeling。

作者发现，可以把 CPU stall 大致建模为：

LLC miss 数量
每层内存的访问延迟
对应层次下的 MLP

之间的组合关系。

直觉上就是：

miss 多，不一定糟；
如果这些 miss 能并行发出去，单次 stall 会被摊薄；
真正糟的是：慢层访问 + 低 MLP + 高暴露延迟。

PACT 试图做的，就是把这部分 stall 成本归因到具体页上。

3. 在线 profiling：只用 4 个标准 CPU counters 做 PAC 估计¶

这篇论文一个很强的地方在于，它不是停在概念上，而是给出了一个无需额外硬件修改的在线估计方法。

作者声称：

只使用 4 个标准 CPU performance counters；
结合 per-tier 的 MLP 分解；
就能在线估算某页访问对 stall 的贡献。

这一点很重要，因为很多 criticality-aware 设计最后都输在“实现成本过高”。PACT 这里试图证明：

不需要专门加新硬件支持；
也不必做粗粒度离线 profiling；
只要建模做得对，就可以在线、页粒度地追踪 performance criticality。

4. 相比 SoarAlto / TMO 一类工作的差异¶

论文在 related work 里反复强调：过去有些工作已经开始注意“criticality”而不是单纯 hotness，但它们仍有明显限制。

比如：

SoarAlto 虽然使用了 cost-aware 思路，但偏向离线 profiling，而且粒度偏粗（对象级）；
TMO 等系统利用 stall 信号，但更多是系统级 pressure indicator，而不是每页、每层可解释的核心抽象。

PACT 的不同点是：

它强调在线；
强调 page-granularity；
强调 per-tier stall attribution；
并且策略层也彻底围绕 PAC 重构。

所以它并不是“已有 hotness 方案的一个补丁”，而是更像一次设计哲学的切换。

5. PAC-centric migration policy¶

即使能估计 PAC，另一个问题仍然存在：怎么迁？

论文认为，criticality-aware 设计必须同时解决：

哪些页该 promotion；
哪些页该 demotion；
迁移要多激进；
如何避免过多迁移把收益吃掉。

为此，PACT 提出了两个关键策略：

eager demotion¶

先主动把不那么关键的页从快层挪出去，为真正高 PAC 页腾空间。

这个设计的重点不只是“淘汰冷页”，而是为高 criticality 页的及时上移创造条件。也就是说，它的 demotion 逻辑不是围绕“最近少访问”，而是围绕“相对性能价值低”。

adaptive promotion¶

在 promotion 时，PACT 不做昂贵的全局排序，也不依赖固定阈值，而是通过轻量统计采样和 adaptive binning 去找真正值得升到 DRAM 的高 PAC 页。

这能带来两个好处：

降低 runtime 管理开销；
更适应 PAC 分布高度偏斜的情况。

论文特别指出，PAC 分布通常是 highly skewed，这意味着真正“必须放进 DRAM”的页只是一小部分。如果策略不考虑这一点，就很容易迁移过多无关紧要的页。

实验与结果¶

PACT 的实验结果很漂亮，而且不只是“略优于 baseline”，而是显著领先。

论文的主要结果包括：

在 13 个 workload 上测试；
覆盖 graph analytics、HPC、in-memory caching、ML 等多类内存密集场景；
对比了 7 个 state-of-the-art 的 tiering 设计，包括：
SoarAlto
Memtis
Colloid
Nomad
TPP
Linux NUMA Balancing Tiering 等
在不同快慢层容量比例下，PACT 最高获得：
61% 的性能提升（相对第二好的系统）
同时迁移次数可减少：
最高 50×

这个组合结果非常关键。

因为很多 tiering 论文会出现一种常见局面：

性能提升有一点；
但迁移非常频繁；
最终系统成本、带宽消耗和稳定性都变差。

PACT 的亮点是，它不仅把真正关键的页找得更准，还显著减少了“无效迁移”。这说明它的 policy 设计和指标设计是相互支撑的，而不是单点优化。

这篇论文真正的贡献¶

我认为这篇论文真正的贡献有四个层次。

贡献 1：明确否定了“hotness 足够”的设计前提¶

这是这篇论文最根本的价值。它不是简单说 hotness 不够好，而是通过动机实验和整体设计明确指出：

频率并不是性能关键性的可靠代理。

这会直接影响很多现有 tiered memory 设计的基本假设。

贡献 2：把 criticality 做成了在线、页级、可用于决策的指标¶

很多系统工作都知道“criticality 更重要”，但真正难的是把它变成一个：

能在线算；
能页级算；
能低成本算；
能拿来直接驱动 policy 的指标。

PACT 的 PAC 做的就是这件事。

贡献 3：把 per-tier stall attribution 引入页迁移决策¶

PACT 的精髓不只是“算 stall”，而是“把 stall 和 tier 绑定起来，再把它和 page 绑定起来”。

这对于 tiered memory 很关键，因为系统最终要回答的是：

这个页继续留在慢层的代价是多少？
如果把它升到快层，能省下多少 stall？

PACT 是在回答这个真正和 placement 相关的问题，而不是泛泛地讨论内存压力。

贡献 4：证明 criticality-first 在工程上是可落地的¶

论文最有说服力的一点是，它没有要求一个巨大而不可部署的系统改造，而是利用现有 CPU counter 和在线分析，把方案落到了实践层。

这使得它不只是“一个漂亮的理论方向”，而更像一个有实际采用潜力的系统设计。

局限与问题¶

虽然我认为这篇工作很强，但它也不是没有边界。

1. PAC 仍然是模型，不是直接真值¶

PACT 虽然比 hotness 更接近真实性能代价，但它本质上仍然是基于 counter 和 analytical model 的在线估计，而不是直接观测“这个页如果在另一层会怎么样”的真值。

这意味着：

模型准确性对最终效果影响很大；
一旦 workload 或硬件行为超出建模假设，可能会出现误差。

2. 实验规模仍然属于研究原型级别¶

13 个 workload 和多个配置已经不错，但离真实大规模数据中心还有距离。

特别是在 CXL 环境里，真实部署可能还涉及：

多租户干扰
带宽争用
更复杂的 NUMA/CXL 互连结构
长时间运行下相位波动

这些都可能影响 PAC 的稳定性和迁移策略收益。

3. 实现依赖对 stall / MLP 的精细理解¶

PACT 的优势来自它对 stall 和 per-tier MLP 的细致建模。但这也意味着：

模型设计和实现复杂度比 hotness-based 方案高；
调试与验证门槛也更高。

换句话说，这篇论文是“更聪明的系统”，但也天然更难实现和维护。

4. 没有真正解决更高层对象语义问题¶

PACT 仍然是 page-granular 的系统。对于很多更上层的对象（例如 graph partition、KV item、tensor shard），页只是它们的物理承载单位，不一定是语义上最自然的优化单位。

所以从长远看，它也许还可以和 object-level placement 或 application hint 结合，进一步提升效果。

和相关工作的关系¶

这篇论文可以放在三条脉络里看。

与传统 hotness-based tiering 相比¶

PACT 最大的区别是：

传统方案问“谁访问得多？”
PACT 问“谁更拖慢 CPU？”

这是一个目标函数层面的变化，而不是采样精度上的小改进。

与 SoarAlto 一类 criticality-aware 工作相比¶

PACT 更进一步地把 criticality 做到了：

在线
页级
per-tier
policy-driven

因此它更像是从“criticality 是一个分析视角”走向了“criticality 是系统设计中心”。

与 stall-pressure / memory pressure 驱动方案相比¶

PACT 不只是感知“系统现在很卡”，而是试图定位：

到底是哪一批页让系统卡
把哪一批页升上去最值

这让它更适合做细粒度的 fast-tier 预算分配。

对研究者的启发¶

这篇论文给我的最大启发是：

启发 1：指标必须和最终优化目标对齐¶

如果目标是提高性能，就应该尽量直接测量“性能代价”，而不是拿访问次数做代理。PACT 展示了一个非常典型的系统设计原则：

代理指标如果离目标太远，后续 policy 再怎么精修也补不回来。

启发 2：tiered memory 不只是容量管理，更是 stall 管理¶

很多分层内存工作把它看成容量扩展问题，但 PACT 让人更明确地看到：

真正决定用户体验和吞吐的，不只是页放哪；
而是这些页访问如何映射到 CPU stall 上。

启发 3：page placement 应该和 MLP 深度绑定¶

PACT 再次说明，在内存系统里，单次访问延迟没有意义，暴露给 CPU 的有效延迟才有意义。而这个有效延迟高度依赖 MLP。以后做 page placement、CXL placement、甚至 heterogeneous memory scheduling，都值得沿这个方向继续深入。

我的评价¶

我对这篇论文的评价是：很强，而且是“方向上很对”的强。

它最打动我的地方不是结果数字本身，而是它把 tiered memory 的核心问题重新定义得更准确了：

不是“如何更准地找热点页”；
而是“如何更准地找真正影响性能的页”。

这一步定义上的转向非常重要。

从论文质量看，它有几个很突出的优点：

动机非常扎实，例子一眼能看懂；
PAC 这个抽象既有直觉，又有工程可实现性；
policy 设计与指标设计是统一的，不是拼凑式系统；
实验结果强，而且“性能更高 + 迁移更少”这一点很有说服力。

如果要挑毛病，我会说：

它仍然高度依赖建模质量；
在更复杂、更大规模的真实 CXL 环境下是否还能保持同样收益，还需要更多验证。

但总体上，我认为它是 tiered memory / CXL memory management 方向一篇非常值得认真读的论文。

适合继续追的问题¶

这篇论文之后，很自然会延伸出这些研究问题：

PAC 是否能扩展到对象级 / 子页级 placement？
在真实 CXL disaggregated memory 环境中，PAC 建模还能否保持稳定？
PAC 与应用语义 hint、编译器 hint、对象生命周期信息能否结合？
PACT 是否能与安全机制结合，比如把 criticality 与数据敏感性一起纳入 placement？
是否可以把类似 criticality-first 的思想推广到缓存管理、prefetch、甚至任务调度层？

Takeaway¶

PACT 最重要的贡献，不只是又提出了一个更好的页迁移策略，而是把 tiered memory 的决策基准从“访问热度”重新拉回到了“性能代价”。在 DRAM 与 CXL/慢层内存共同存在的时代，这种从 hotness-first 到 criticality-first 的转向，很可能会成为下一代内存管理设计的主线。

论文核心PAC算法完整详细拆解¶

PAC（Per-page Access Criticality，页面级访问关键性）是这篇ASPLOS 2026论文的核心创新根基，也是PACT分层内存系统区别于所有传统热度驱动方案的核心。它是一套在线、页面粒度、仅依赖通用CPU硬件计数器、无专用硬件依赖的算法，核心目标是精准量化单个内存页面对CPU执行停顿的真实性能贡献，彻底替代传统“访问频率（热度）”这一不准确的代理指标。

一、PAC算法的核心定位与要解决的核心挑战¶

1.1 核心定义¶

PAC是一个量化指标，其数值直接对应一个内存页面在运行过程中引发的CPU停顿周期总数，而非页面的访问次数。PAC值越高，代表该页面的性能关键性越强，放到高速DRAM层能带来的性能收益越大；反之，PAC值越低，哪怕访问频率很高，放到低速CXL/NUMA层也不会对性能造成明显影响。

1.2 算法要解决的核心行业难题¶

传统CPU的性能计数器存在根本性的粒度缺陷：

CPU暴露的停顿相关计数器是核粒度的，只能统计一个CPU核的总停顿，无法区分停顿来自哪个内存层（DRAM/远端NUMA/CXL），更无法归因到具体的内存页面。
现有方案只能通过“访问频率”间接推断页面的性能影响，完全忽略了MLP（内存级并行度）、访问模式带来的巨大性能差异，导致调度决策完全偏离真实性能需求。

PAC算法的核心突破，就是解决了无专用硬件支持下，把核粒度的CPU总停顿，精准拆解到每个内存层、每个4KB/巨页粒度的内存页面这一核心难题。

1.3 算法的核心设计目标¶

在线实时计算：无需离线剖析，随应用运行周期性更新，适配动态变化的负载相位；
页面级细粒度：支持4KB标准页和2MB透明巨页（THP），匹配操作系统页面迁移的最小粒度；
极低开销：仅依赖4个通用CPU性能计数器，内存开销仅0.6%，CPU开销可忽略；
硬件普适性：无需定制硬件，主流x86处理器（Intel/AMD）均可适配；
精准量化性能影响：直接和CPU停顿挂钩，而非间接的访问频率，从根源上匹配分层内存的调度需求。

二、PAC算法成立的核心理论前提（论文关键洞察）¶

PAC算法不是凭空设计的，它完全建立在论文通过96个负载大规模实证分析得出的4个核心洞察之上，这也是算法逻辑成立的底层基础：

洞察1：分层CPU停顿可通过极简公式精准建模¶

每个内存层引发的CPU停顿，和该层的LLC（最后一级缓存）缺失数、MLP呈严格的线性关系，公式如下：

\[LLC-stalls = k × \frac{LLC-misses}{MLP}\]

\(LLC-stalls\)：该内存层的LLC缺失引发的CPU总停顿周期数（直接对应性能损失）；
\(k\)：层级相关系数，由该内存层的访问延迟、硬件架构特性决定，同硬件下跨负载高度稳定；
\(LLC-misses\)：该内存层的LLC缺失总数；
\(MLP\)：该内存层的内存级并行度，即CPU能并行处理的该层内存请求平均数。

论文验证：该公式在3种延迟配置、96个负载下，和真实CPU停顿的皮尔逊相关系数超过0.98，拟合精度远高于仅用LLC缺失数的传统方案。

洞察2：分层MLP可通过通用CPU硬件计数器在线测量¶

Intel CPU的CHA（Caching and Home Agent）/TOR（Table Of Requests）队列，是CPU核心与内存控制器之间的请求调度单元，所有LLC缺失后的内存请求都必须经过该队列，且队列计数器天然按内存层隔离。

队列的占用率计数器，可直接量化该内存层的平均在飞请求数，也就是该层的MLP；
无需定制硬件，Intel Xeon可扩展处理器全线支持该计数器。

洞察3：MLP具备强相位稳定性¶

应用的执行呈现明显的相位特征，在数十毫秒的短时间窗口内，MLP的值几乎保持稳定，仅在秒级的相位切换时才会发生明显变化。这一特性是PAC算法的核心支撑：在稳定的窗口内，该内存层单次LLC缺失带来的CPU停顿成本是固定的，为页面级的比例归因提供了理论基础。

洞察4：稳定窗口内，比例归因可精准实现页面级停顿拆解¶

在MLP稳定的短窗口内，该层的总CPU停顿，可按每个页面的LLC缺失访问次数的占比，等比例分配到每个页面，从而得到单个页面引发的CPU停顿数。论文验证：该归因方式在20ms窗口内，和真实页面级性能影响的匹配度极高，完全满足分层内存调度的精度需求。

三、PAC核心算法完整流程与伪代码解析¶

PAC算法是一套周期性运行的两阶段流水线，论文默认运行周期为20ms（兼顾精度、开销与MLP相位稳定性），完整对应论文中的Algorithm 1: PAC Sampling。

3.1 算法整体框架¶

每个20ms的采样窗口内，算法分为两个串行执行的核心阶段：

阶段1：分层总停顿建模：采集硬件计数器，计算目标低速层的总CPU停顿周期\(S\)；
阶段2：页面级停顿归因与PAC更新：通过PEBS采样获取页面级访问数据，把总停顿\(S\)分配到每个页面，迭代更新每个页面的PAC值。

3.2 算法依赖的硬件计数器¶

算法仅需4个通用CPU性能计数器，完全对应论文中的Table 1，无任何专用硬件需求：

计数器类型	寄存器名称	核心作用
PEBS采样	MEM_LOAD_L3_MISS_RETIRED	捕获低速层的LLC缺失读访问，记录访问的虚拟地址、页面访问次数
T1（TOR计数）	TOR_OCCUPANCY	累计记录TOR队列每个周期的在飞请求总数（周期数×单周期在飞请求数）
T2（TOR周期）	TOR_OCCUPANCY_COUNTER0	累计记录TOR队列非空的CPU周期总数
层级缺失计数	OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.REMOTE_DRAM	统计低速层的LLC总缺失数

3.3 算法伪代码与逐行深度解析¶

论文中PAC算法的核心伪代码如下，下文逐行拆解计算逻辑与设计原理：

Algorithm 1: PAC Sampling (every 20ms)
Input: 硬件计数器、PEBS采样数据
Output: 所有采样页面的更新后PAC值
1  Measure slow-tier metrics: LLC-misses, MLP ← ΔT1/ΔT2
2  Estimate slow-tier stalls: S ← k · (LLC-misses / MLP)
3  Sample page accesses using PEBS:
4      Record per-page (p) info: vaddr, access count (Aₚ)
5  Update total accesses: Aₜ ← Σₚ Aₚ
6  foreach sampled page p do
7      Attribute stalls to page: Sₚ ← S · (Aₚ / Aₜ)
8      Update PAC: PAC[p] ← α · PAC[p] + Sₚ  α∈[0,1]

第1行：低速层核心指标采集与MLP计算¶

这一行是算法的硬件数据输入环节，核心是计算低速层的MLP：

窗口增量计算：在20ms窗口的起始和结束时刻，分别读取T1（TOR_OCCUPANCY）、T2（TOR_OCCUPANCY_COUNTER0）、低速层LLC总缺失数，计算窗口内的增量ΔT1、ΔT2、LLC-misses，避免累计值的干扰。
分层MLP计算：\(MLP = \Delta T1 / \Delta T2\)
物理含义：ΔT2是窗口内TOR队列非空的总周期数，ΔT1是窗口内TOR队列所有周期的在飞请求数累加。二者的比值，就是该低速层在队列活跃时，平均每个CPU周期的并行在飞请求数，也就是该层的平均MLP。
论文验证：该方式计算的TOR-MLP，和Intel官方的L2_MLP系统级指标趋势完全一致，且具备分层隔离的核心优势。

第2行：低速层总CPU停顿计算¶

这一行是算法的核心建模环节，基于洞察1的公式，计算窗口内低速层访问引发的CPU总停顿周期\(S\)：

公式：\(S = k × (LLC-misses / MLP)\)

参数说明：

\(k\)是该低速层的硬件校准系数，由内存延迟、架构决定，同硬件下仅需一次离线校准，跨负载稳定不变；
\(LLC-misses\)是窗口内低速层的总LLC缺失数；
\(MLP\)是第1行计算的该层窗口内平均MLP。

核心逻辑：MLP作为分母，直接决定了单次LLC缺失的性能成本——MLP越高，单次缺失带来的停顿越小，完美区分了高MLP流式访问和低MLP指针追踪访问的性能差异。

第3-5行：页面级访问数据采集与统计¶

这一行是算法的页面粒度数据输入环节，基于Intel PEBS（处理器事件基于采样）硬件实现低开销的页面访问跟踪：

PEBS采样配置：仅采样低速层的MEM_LOAD_L3_MISS_RETIRED事件（LLC缺失的读访问），默认采样率为1/400（每400个事件采样1次），在精度和开销间达到最优平衡；
页面级数据记录：对每个采样到的页面\(p\)，记录其虚拟地址vaddr，以及窗口内的采样访问次数\(A_p\)；
总访问数统计：累加所有采样页面的访问次数，得到窗口内总采样访问数\(A_t = \sum_p A_p\)。

论文设计细节：仅采样低速层的读访问，原因是CXL/NUMA链路为全双工，写操作的性能影响极小；且仅需低速层访问数据即可指导页面提升决策，快层页面的降级可复用Linux内核LRU机制，进一步降低开销。

第6-7行：单页面停顿比例归因¶

这一行是算法的核心拆解环节，把核粒度的总停顿\(S\)，精准分配到每个页面：

公式：\(S_p = S × (A_p / A_t)\)
物理含义：窗口内页面\(p\)引发的CPU停顿周期数\(S_p\)，等于低速层总停顿\(S\)，乘以该页面的访问次数占总采样访问数的比例。
合理性支撑：基于洞察3的MLP相位稳定性，窗口内单次LLC缺失的平均停顿成本固定，因此页面的总停顿和其访问次数呈严格正比，完美实现了页面级的停顿归因。

第8行：PAC值的迭代更新¶

这一行是算法的输出环节，完成每个页面PAC值的最终更新：

公式：\(PAC[p] = \alpha × PAC[p] + S_p\)