对STARNUMA论文（StarNUMA: Mitigating NUMA Challenges with Memory Pooling）的各部分概括和解释，原文链接：
1.论文背景
大型多Socket（插槽）系统中，每一个Socket包括具有多个内核的CPU，以及本地内存DRAM，不同Socket之间通过相干链路互连（比如Intel的UPI，超路径互连）。下面是16-Socket系统的示意图：
分为4个机箱，每个机箱有4个Socket，每个Socket连接到机箱间互连ASIC（FLEX ASIC），机箱间的一致性链路称为 NUMALinks，每个机箱可以单跳访问另一个机箱。
在多socket系统中，每个处理器都能直接访问任何内存位置，但内存访问的延迟和带宽特性极大地取决于目标内存位置与访问处理器之间的距离。本地内存访问需要80ns，机箱内需要130ns，机箱间需要360ns。由此造成了非均匀内存访问（NUMA）效应，因此需要通过智能数据放置和迁移以最大限度减少远程内存访问，也就是将处理器需要的页面放到离处理器比较近的内存中。
但是部分页面共享程度高，因此其没有“home” （主）socket位置，也就是无论其放到哪个处理器附近，都无法避免远程内存访问，这种页面叫游离页。此外，由于共享程度高，其可能会在不同处理器之间不断迁移，产生了一定的代价。
如上图所示，78% 的页面有四个或更少的共享者，这表明智能迁移策略可以将页面访问控制在机箱内。然而，虽然只有 7% 的页面有 8 个以上的共享者，但 68% 的内存访问都集中在这些共享页面上，而所有 16 个Socket共享的 2% 页面占所有访问的 36%。这说明有相当一部分访问针对的是少数广泛共享的页面，而访问这些广泛共享的页面大概率需要机箱间通信。
简单地复制这些页面到不同的内存中需要很高的软件复杂性和开销来保持内存一致性，因为它们大部分是读写页。
2.STARNUMA设计
2.1 内存池
STARNUMA 通过 CXL 附加内存池扩展了多Socket系统，每一个Socket通过CXL链接连接到共享内存池，组成了一个星型结构。
由于 CXL 3.x 的底层物理层是 PCIe 6.0，因此一条 8 通道的 CXL 链路可为每个方向提供 64GB/s 的原始带宽，而实际带宽约为 40GB/s。
图3显示了访问共享内存池所需的时间，其中每个CXL端口需要25ns，重定时器（远程访问所需）20ns，链路上时间10ns，片上网络、内部仲裁逻辑和一致性目录的时间估计为 20ns，总共100ns。如果再加上在处理器上消耗的时间和DRAM访问的时间，则总时间为180ns，仍然比机箱间互连所需的360ns时间要短。
如果Socket数目继续增加，则需要CXL交换机，总时间可能来到了275ns。
STARNUMA一方面缩短了内存访问的时间（如果数据在池上，其访问延迟比机箱间访问延时小），另一方面由于提供了新的CXL链路使得系统总带宽增加了。
2.2 一致性
图4展示了因为目录一致性而产生的缓存块传输：
（1）假如socket（R）需要访问内存的某块数据，但该块数据所在的页的主节点是socket（H），因此需要先访问socket（H）。这个是由TLB决定的，该块数据的虚拟地址映射的物理地址在socket（H）的内存范围中。
但在此之前，可能另一个Socket（O）已经访问并占有了该块（通过向该块写入数据），因此需要让Socket（O）将最新的数据传输给Socket（R）。路径为红色R->H->O->R。
（2）假如该页的主节点在共享内存池上，则同样需要先访问socket（O），但并不是由socket（O）直接发送给socket（R），而是需要传输回内存池中，所以路径为蓝色R->H->O->H->R。
由于socket与内存池之间的链路是CXL，提供了更高的传输速率，所以即使看上去第（2）中情况路径更长，但实际传输延迟要小。（2）传输延迟为200ns，（1）为333ns。
2.3 内存访问监控和页面迁移
STARNUMA需要一种机制去检测游离页，也就是广泛共享的页面。
如图5所示，将内存分成了多个区域，每个区域包括多个页面。
每个区域都在内存中拥有一个元数据区域（metadata region），其包括两部分内容，一部分用于统计哪些socket访问了该区域的数据，另一部分是统计该区域总访问次数的计数器（一共i位）。当i为0时，即不关注访问次数，只关注该区域的共享程度。
TLB中也有i位的计数器附件，在完成 LLC（最后一级缓存）缺失（意味着需要访问内存）加载后，相应 TLB 附件条目的计数器会递增。
当 TLB 条目被删除时，PTW会将附件条目的值添加到内存元数据区域的相应计数器中。为了获取从未在 TLB 中被删除的热页面计数器，所有 TLB 附件条目都有一个标记位（即图中的periodic marker bit），每个迁移阶段（1s）定期设置一次。当访问已设置标记的 TLB 条目时，PTW 会将附件条目的值添加到相应的元数据区域位置，并重置标记。
图6是页面迁移的算法，这里Region_Trackers应该是按照i位计数器进行从高到低的排序。
当一个区域的访问次数超过阈值，就需要将该区域进行迁移。如果该区域共享者太多，就放到内存池中。如果目标的内存满了，就移出一个访问次数较低的区域（for循环遍历找到第一个访问次数低于阈值的即可，所以并不一定是访问次数最低的）。
另外，一个区域如果经常迁移，那么其处于ping-ponging状态，如果继续迁移下去，可能并不会提高多少效率，反而带来迁移开销。
总的迁移次数是有限的，并不是所有需要迁移的页面都会被处理。
迁移会导致物理地址发生变化，从而导致页表更新和TLB shotdowns，即使一个内核的TLB中没有需要删除的条目，但它也会收到来自处理迁移任务的内核的中断，内核接收中断进入内核模式需要几千个周期的时间。因此需要一种硬件支持，引入共享 TLB 目录，只向在其 TLB 中实际缓存了迁移页转换的必要内核发送 TLB shotdowns。同时设计还应包括最小内核扩展，允许完全在硬件中处理 TLB 条目失效，无需操作系统干预。具体的硬件处理方法并没描述，其它论文可能有该问题的解决方案。
区域的大小需要权衡，如果区域较小，那就需要很多区域，相应的元数据区域也会变多，内存占用增加，同时使用算法进行迁移时遍历元数据区域所需的时间也会增加，但小区域有着更高的跟踪精度，使得其包含的页面绝大多数都是被广泛共享的。
3.评估方法
3.1 基于采样的仿真
分为3个步骤：
（1）步骤A在真实机器上部署目标工作负载，并跟踪每个应用线程的执行情况，包括指令和内存访问跟踪。内存跟踪以10亿条指令为间隔记录，并将其称为一个阶段，此外还记录了每个阶段的前 1 亿条指令。
（2）步骤B利用步骤A的内存跟踪，在每一个阶段结束后根据页面访问的情况做出数据迁移决策（也就是2.3中的算法），将页面进行迁移，从而生成新的“页面-内存”映射。
（3）步骤C进行并行时序仿真，也就是每个阶段单独仿真。因为步骤B在每个阶段结束后迁移了页面，所以每个阶段都有自己的“页面-内存”映射（也就是页面在内存中的位置不一样）。在这种映射下，轻内核根据步骤A收集的内存访问情况发出内存访问请求，详细内核则运行步骤A收集的指令来发出内存请求，关于轻内核和详细内核见下一节。
这里的Baseline也会有页面迁移，只不过没有CXL共享内存池。
3.2 混合模式仿真
即使采用基于采样的方法，在周期级模拟整个多socket系统仍然非常困难，因此需要缩小socket规模。
只有一个socket的内核有完整的微架构细节（详细内核），它用来执行步骤A记录的1亿条指令，执行指令的时候会产生内存访问。其它socket里面的内核是轻内核，它们只根据步骤A的内存跟踪向系统注入内存请求就行了，注入速率根据模拟socket的IPC进行调节。
每个轻型socket都有一个 LLC 大小的高速缓存（高一级缓存是低一级缓存的子集，所以有LLC就已经足够了），用于支持一致性建模和过滤对内存的访问，还有一个详细的内存控制器模型，用于处理针对其内存范围的内存请求，同时准确捕捉内存调度和争用对性能的影响。在 LLC 和每个处理器的内存控制器之间有一个互连仿真模块，对插座间拓扑结构及其相关链路延迟和带宽限制进行建模，从而捕捉争用/排队效应。在收到新的内存访问请求时，通过查询步骤 B 生成的页面映射输入，确定目标插槽。然后，互连模块根据请求的源插槽和目标插槽，确定请求必须穿越的链路顺序。穿越互连后，请求要么进入目标插槽的内存控制器队列，要么根据需要触发一致性事件。
3.3 迁移开销建模
将 HI 门限设定为 20K，LO设置为1K，并在每个迁移阶段根据迁移次数限制对其进行动态调整。在页面迁移过程中，对该页面的所有内存访问都会停止，直到迁移完成。周期级时序仿真（步骤C）仅涵盖每个十亿条指令阶段的前 1 亿条指令。因此，在时序仿真中只对每个阶段前 10%的迁移进行建模，相当于运行部分指令来测试迁移后的效果。
3.4 系统配置
表1和表2对比了完整的16-socket系统和模拟系统之间的差异，这里将内存池允许的数据量限制为每个工作负载所用内存的 20%。
3.5 工作负载
图形分析：广度优先搜索 (BFS)、连接组件 (CC)、单源最短路径 (SSSP) 和三角形计数 (TC)。
高性能计算：分钟空间中的全文索引（FMI）和部分排序对齐（POA）。
数据服务： 使用Masstree 高性能 KeyValue 存储器，数据集为 100GB，密钥流行度分布均匀，读写比率为 50/50。
事务处理：在Silo 内存数据库管理系统上部署的带有 64 个仓库的 TPCC。
表里总结了工作负载的IPC和LLC MPKI（1000条指令中LLC缺失个数）。括号中为仅使用本地内存时的IPC，单插槽和 16 插槽执行之间 2-10 倍的 IPC 差距说明了 NUMA 效应对性能的影响。
4.测试结果
4.1 主要结果
图 8b 显示了测得的 AMAT（内存平均访问时间），分解为unloaded延迟以及插槽间和 CXL 链路竞争造成的延迟，unloaded延迟是没有任何竞争情况下的预期 AMAT，可以看到，排队和竞争会对性能造成一定的影响。
图8a显示了STARNUMA降低了AMAT，提高了IPC。STARNUMA 通过两种不同的方式减少延迟：(i) 直接减少unloaded延迟（平均减少跳数）；(ii) CXL 链路提供了额外带宽，减少争用，进而减少排队延迟。其中TC 和 FMI 属于计算密集型，LLC MPKI 较低，争用较少，主要利用(i)进行加速。而SSSP 和 BFS 受带宽限制，主要利用(ii)。其余工作负载利用了(i)和(ii)。POA所有访问都是本地访问，因此不会发生迁移，也不会将数据放入池中，只需要使用首次接触页面放置策略即可放置NUMA效应。另外T0虽然无法识别哪些区域访问次数最多，但其可以判断共享程度，也获得了获得了 T16 的大部分收益。
图 8c 显示了内存访问按类型划分的情况。STARNUMA 中的大多数 BT（一致性块传输） 都是通过池路径完成的，这比 3 跳套接字间传输平均快 30%，不过因更快的 BT 而减少的 AMAT 分数微乎其微。
表4强调了池作为一种新的数据放置选项的重要性，除 POA 外，大多数页面都被迁移到池中（这里应该是访问的页面位于池中占总访问页面的比例）。
4.2 与 Oracular 静态页面放置的比较
静态页面放置方法是根据每个工作负载访问模式的先验知识进行放置，运行时不再进行页面迁移。比如根据3.1步骤A的内存跟踪得到，某一页面在socket0中访问的最多，因此把它放在socket0的内存上。
图9对比了使用静态StarNUMA，和普通StarNUMA（首次接触放置+动态迁移），以及静态Baseline的性能。
静态初始页面放置和动态迁移差不多，甚至会优于动态迁移，因为其消除了迁移开销，而且说明页面的共享模式不会随着时间的推移而发生剧烈变化。
因为假如一个页面在阶段0-阶段1时被socket0大量访问，而后在阶段2-阶段10时被socket1访问，只不过从总访问量来说，socket0访问该页面次数大于socket1，因此静态方法将该页面放到socket0的内存上，导致阶段2-阶段10 socket1只能进行远程内存访问，相比之下，假如采取迁移策略，阶段2的结尾处会将该页面迁移到socket1的内存上，阶段3-阶段10 socket1就可以进行本地内存访问。从这个角度出发，静态页面放置策略应该会比动态迁移的效果要差，但图9与此相反，说明上面假设的情况很少出现，也就是共享模式不会发生剧烈变化，在这种情况下，迁移带来的效果不多，反而会造成了一定的开销导致IPC下降。
而静态Baseline不如动态迁移StarNUMA，这是因为游离页无论放在哪里都无法避免远程内存访问，放在共享内存池中才能提高效率。
4.3 内存池延迟的影响
图10假设了加上CXL交换机的延迟（90ns）对性能造成的影响，除了TC外（前面说过，TC主要靠减少延迟来提高速率），其余影响不是很大。
4.4 带宽可用性的影响
对比了3种配置：
（1）提高Baseline中UPI 和 NUMALink 的带宽，使得其总带宽与STARNUMA中的总带宽一致。
（2）直接将Baseline中UPI 和 NUMALink 的带宽增加一倍，增加的带宽远高于STARNUMA 16 个 CXL 链路带来的额外带宽。
（3）将 CXL 链路带宽减半至 20GB/s（即CXL通道个数减半）。
除了BFS工作负载外，其余的Baseline ISO-BW（配置1）和Baseline 2X BW（配置2）均没有超过StarNUMA的性能。BFS的Baseline 2X BW超过StarNUMA是因为前面提到，其工作主要受带宽约束，此外其均匀利用了机箱内和机箱间的链路，而StarNUMA因为将热门页面放到池上，使得内存访问的很大一部分集中在池的 CXL 链路上，而机箱内和机箱间的链路利用率低。
尽管池带宽减少了一半，但 STARNUMA Half-BW 性能也能比Baseline（虚线）高（除了BFS）。
因此，单纯提高机箱内和机箱间的链路带宽意义不大，解决池上的竞争问题更加重要（4.1的图8b）。
4.5 内存池容量的影响
前面内存池容量设置为工作负载内存占用的20%，现在把内存池的容量设置为与socket内存大小一致，此时内存池容量为每个工作负载内存占用容量的1/17。
除了FMI外，大多数工作负载对池的大小并不敏感，这表明大部分远程访问针对的是一小部分页面。
4.6 页面复制与内存池
页面复制带来了在软件中保持页面一致性的主要开销。只有在不担心内存容量浪费的情况下，只读共享页才是良好的复制候选页。
在BFS任务中，大多数访问都以共享读写页面为目标（图2），导致池目录平均每 50 个周期处理一次一致性操作。在这种情况下，复制和软件一致性会产生过高的开销。
图13中TC则与之相反，大多数内存访问都是对共享只读页面的访问，虽然不存在一致性问题，但复制会造成过大的内存容量压力。
其余工作负载的页面访问行为介于 BFS 和 TC 之间。
复制对于只读的流浪页面是有效的，因为这些页面所占的访问比例较高，占用的内存空间较小。页面复制和 STARNUMA 可以作为互补技术联合使用。
4.7 评估方法的影响
前面使用的是默认配置 [SC1]：每十亿条指令为一个阶段，每个内核在仿真的每个阶段只模拟其中1亿条指令。
而现在增加两组配置：
[SC2]：模拟3倍更详细的指令（每个阶段运行3亿条指令）。
[SC3]：系统规模翻倍（每个插槽8个内核，2倍内存/互连带宽，以及针对 内核数8 × socket数16 = 128 个线程的指令跟踪）。
图14表示即使是规模更大、成本更高的仿真配置（SC2 和 SC3）也证实了 STARNUMA 的潜力，产生了类似或更好的结果。
5. 写在最后
由于大多数内存访问的目标页面放在池上（4.1节表4），会导致排队和竞争，从而对性能造成影响（4.1节图b），同时由于访问池都需要用到CXL链路，出现机箱内和机箱间链路带宽闲置的现象（4.4节）。
虽然可以通过对只读的共享页面进行复制，缓解共享内存池的压力（4.6节），但是带宽闲置问题并没有给出合适的解决方案。其实可以通过适当减少内存池中的页面数量来平衡带宽，减轻池的压力，如4.5节中缩小池的容量。或者也可以考虑调整2.3节算法的共享数阈值来限制池中的页面数量，2.3的算法中当页面的共享者个数大于8（socket数的一半）时，即可放入池中，可以测试不同阈值情况下的性能。当然，也不是非得充分利用机箱内和机箱间的链路，还需要考虑池的排队和竞争延迟有没有超过CXL链路减少的延迟。
CC BY-NC-SA 4.0欢迎评论探讨
