这是一篇由密歇根大学的 Neha Agarwal 和 Thomas F. Wenisch, 发表在计算机系统顶会 ASLOS 的论文, Thermostat: Application-transparent Page Management for Two-tiered Main Memory. 一种双层存储结构的透明巨页内存管理机制.
随着科技的发展, 新的内存技术出现了, 它比普通 DRAM 更加密集和便宜, 并且已经重新引起了对两级主内存方案的兴趣. 我们知道, 把不经常访问的应用程序数据存放在这种内存方案中, 可以显著的节省成本. 过去对两层主内存的研究假定页面大小为 4KB, 然而, 在内存占用很大的云应用中, 尤其是在虚拟云环境中, 2MB 的巨页的性能非常关键, 其中嵌套分页急剧增加 4KB 页面管理的成本. thermostat 作为一种应用透明的海量页面感知机制, 将页面放置在双技术混合内存系统中, 同时实现了两层内存的成本优势和透明的海量内存的性能优势.
文章中主要完成的工作概括之后如下:
1. 提出了一种在线的低开销的机制, 用于处理由于在缓慢的内存中放置一个特定页面而导致的性能下降.
2. 使用这个机制在一个在线的热 / 冷页面分类系统, 只需要一个最大内存成本下降目标作为输入.
3. 提出了一种在线方法来检测和纠正错误分类, 从而最小化这种错误分类对应用程序吞吐量的影响.
4. 通过模拟软件中的缓慢内存, 最终证明了恒温器可以迁移到高达 50% 的云应用程序.
4. 通过模拟软件中的缓慢内存, 最终证明了恒温器可以迁移到高达 50% 的云应用程序. 他们提出了 thermostat, 这是一种对于应用透明的海量页面感知机制, 模拟了接近未来高密度内存技术的性能特性的慢内存, 并实验将 thermostat 迁移到应用程序的内存, 虽然性能下降限制 3%, 但是内存成本降低了 30%. 我对于这篇文章的分析主要集中在 thermostat 机制的实现. 首先, 如何有效, 透明地使用缓慢的内存来降低成本而不会造成大量的性能损失, 是一项挑战. 任何内存放置策略都必须估计与将给定的内存页放置, 所以在慢速内存中相关的性能会有一定的损失, 而且还需要一些方法来衡量页面访问速度. 当前 x86 硬件中缺乏准确的页面访问速率跟踪, 这使得这项任务具有挑战性. 此外, 我们将显示, 基于现有硬件维护的访问位将页面放置到缓慢内存的方法是不够的, 并可能导致严重的性能退化. 当前 x86 硬件中缺乏准确的页面访问速率跟踪, 这使得这项任务具有挑战性. 此外, 我们将显示, 基于现有硬件维护的访问位将页面放置
文章中提出了 thermostat, 这是一种对于应用透明的海量页面感知机制, 模拟了接近未来高密度内存技术的性能特性的慢内存, 并实验将 thermostat 迁移到应用程序的内存, 虽然性能下降限制 3%, 但是内存成本降低了 30%. 我对于这篇文章的分析主要集中在 thermostat 机制的实现.
首先, 如何有效, 透明地使用缓慢的内存来降低成本而不会造成大量的性能损失, 是一项挑战. 任何内存放置策略都必须估计与将给定的内存页放置, 所以在慢速内存中相关的性能会有一定的损失, 而且还需要一些方法来衡量页面访问速度. 当前 x86 硬件中缺乏准确的页面访问速率跟踪, 这使得这项任务具有挑战性. 此外, 我们将显示, 基于现有硬件维护的访问位将页面放置到缓慢内存的方法是不够的, 并可能导致严重的性能退化.
巨页, 概括起来, 就是在内核页面大小一定的情况下, 分配物理地址连续的多个页框, 模拟出一个大页面供用户态程序访问, 从而减少用户程序缺页次数, 提高性能.
thermostat 设置了透明的巨页, 内核试图尽可能的分配 hugepages, 如果 mmap 区域是 2MB 自然对其的, 那么任何 Linux 进程都将映射到 2MB 的页面. 主内核地址空间本身被映射为一张巨页, 从而降低了内核代码 TLB 的压力. 内核总是尝试使用 hugepages 来满足内存分配. 如果没有 hugepages 可用(例如, 物理连续内存不可用), 内核将返回到常规的 4KB 页面. 透明巨页也可交换, 这是通过将大页面拆分为较小的 4KB 页面来实现的, 然后正常交换. 但是为了有效地使用 Hugepages, 内核必须找到物理上连续的内存区域, 这些内存区域必须足够大以满足请求, 并且必须适当地对齐. 为此, 添加了一个 khugepaged 内核线程. 这个线程偶尔会尝试用一个巨大的页面分配来替换当前正在使用的较小的页面, 从而最大限度地提高 THP 的使用率.
热页面和冷页面是一项提高数据缓冲效率的技术. 这项技术对于每一个 CPU 的每一个管理区, 都会提供两个数据页队列: 热队列和冷队列. 热页面可以理解成经常访问的页面, 而冷页面对应的是不经常访问的页面. 他们可以在一个锁定的条件下对于多个数据页进行操作, 默认的情况是一次 16 个. 队列会存在一个高水位和一个低水位, 如果页面数小于低水位, 那么队列会重新充满, 如果高于高水位, 队列会被清空, 对于热队列来说, 一般值为 32~96, 而冷队列为 0~32. 热队列的管理是后进先出, 收集的是通过 free_pages()释放的内存页面. 冷队列收集的是 CPU 请求可是没有被马上使用的页面, 例如 DMA 操作一次读入的一些页面. 冷队列保留了热页面中有价值的页面以及一个缓冲行中暂时没有使用的页面, 这些页面来自 shrink_list(),shrink_cache()和 refill_inactive_zone().
通过模拟软件中的缓慢内存, 最终证明了恒温器可以迁移到高达 50% 的云应用程序. 他们提出了 thermostat, 这是一种对于应用透明的海量页面感知机制, 模拟了接近未来高密度内存技术的性能特性的慢内存, 并实验将 thermostat 迁移到应用程序的内存, 虽然性能下降限制 3%, 但是内存成本降低了 30%. 我对于这篇文章的分析主要集中在 thermostat 机制的实现. 首先, 如何有效, 透明地使用缓慢的内存来降低成本而不会造成大量的性能损失, 是一项挑战. 任何内存放置策略都必须估计与将给定的内存页放置, 所以在慢速内存中相关的性能会有一定的损失, 而且还需要一些方法来衡量页面访问速度. 当前 x86 硬件中缺乏准确的页面访问速率跟踪, 这使得这项任务具有挑战性. 此外, 我们将显示, 基于现有硬件维护的访问位将页面放置到缓慢内存的方法是不够的, 并可能导致严重的性能退化. 当前 x86 硬件中缺乏准确的页面访问速率跟踪, 这使得这项任务具有挑战性. 此外, 我们将显示, 基于现有硬件维护的访问位将页面放置
thermostat 由四个部分组成:
1. 一种抽样机制: 随机选择访问速率监视页面子集.
2. 一种监视机制: 在限制最大开销的同时计算访问抽样页面的次数.
3. 一种置换策略: 用于将页面放置在缓慢内存中的分类策略.
4. 一种内存机制: 监控和检测错误分类页面或行为更改, 并将页面迁移回传统的内存.
thermostat 必须解决的关键挑战是, 首先要以足够低的开销识别 2MB 页的访问速度, 同时仍然能够快速响应不断变化的负载行为. 其次, 如果经常访问页面, 跟踪页面的访问速度可能会非常昂贵. 所以, 为了约束访问速率监视的性能影响, 任何时候都只能监视应用程序占用空间的一小部分.
关于各部分的具体实现, 我的概括如下:
1. 首先要设计并实现页面抽样. 可以采样大量的巨大页面, 但是它可能导致高性能开销. 因为每个 TLB 错过 sam-pled 页面会导致操作系统错误处理的额外延迟. 为了严格控制应用程序性能放缓, 最终文章将巨大页面的随机样本分割为 4KB 页, 并且在每个采样间隔内只检测这些 4KB 页的一小部分.
具体的选择策略是: 对于某些固定的 K, 选择 K 随机 4KB 页面. 然而, 当一个巨大的页面中只有几个 4KB 的页面是热的, 由于相较于热页面的数量, K 值可能过大, 这种策略无法对它们进行采样, 从而认为整个巨大的页面具有较低的访问速度. 为了解决这个缺点, 文章将分两步监控页面访问速率. 首先, 依赖硬件维护的访问比特来监控所 4KB 的页面, 并识别那些具有非零访问速率的页面. 然后, 使用成本更高的软件机制监视这些页面的示例, 以准确估计 2MB 页面的总访问速率. 使用这种策略, 任何时候只有 0.5% 的内存被采样, 这使得由于采样 <1% 的性能开销.
2. 计算访问抽样页面的次数. 当前 x86 硬件不支持每页粒度的访问计数. 因此, 文章中设计了一个仅适用于软件的解决方案, 通过使用 PTE 预留位来跟踪开销非常低 (<1%) 的页面访问速率. 为了近似访问页面的次数, 测试人员使用 BadgerTrap, 拦截 TLB 错误的内核扩展. 当对访问计数的页面进行采样时, thermostat 通过设置保留位来用于计数, 然后从 TLB 获取数据, 刷新计数. 下一次访问该页面将导致硬件页面缺失, 然后触发保护故障, 最后由 BadgerTrap 截获. 通过计算 BadgerTrap 错误的数量, 可以估计 TLB 丢失到页面的次数, 将其作为内存访问次数的代理.
3. 之后实现将页面放置在缓慢内存中的分类策略. 基于用户输入的目标, 也就是最大可容忍的内存损失, 将页面分类为热或冷. 为了选择出冷页面, 文章中计算了一种访问巨页的访问率. 具体的计算过程如下, 首先假设用户设置的最低可容忍内存损失为 x%, 第 A 次访问内存,是访问到内存的时延,是访问内存需要的总时间. 所以最低可容忍内存损失, 可以理解成最低的内存访问率是, 然后对采样的海量页面进行排序, 使其估计的访问速率呈递增顺序, 然后将最冷的页面置于缓慢内存中, 直到总访问速率达到目标阈值.
这种简单的方法控制访问速度以减缓内存以避免用户指定的降级目标. 下图给出了缓存访问速度平均超过 30 秒, 假设 1us 缓慢内存访问延迟和 3% 可容忍最低内存损失, 我们观察到, thermostat 保持缓慢的内存访问速度接近目标 30K . 对于 Aerospike 和 Cassandra,thermostat 缓慢的内存访问速度暂时超过 30 K.
4. 最后一步是实现对于错误分类页面的更正策略.
由于仅根据少数 4KB 页面的访问率来估计一个大页面的访问率, 所以总是有可能一些热的大页面由于采样错误而被误归类为冷的. 这种错误分类对应用程序性能不利, 因为任何给定的大页面的连续采样间隔可能相当长.
为了解决这个问题, 文章中使用之前提到的软件机制跟踪访问每个冷的大页面的次数. 由于这些页面的访问速度在设计上很慢, 因此此监视的性能影响很低. 在每个采样周期中, 根据慢内存中的大页面的访问计数对其进行排序, 并将它们的总访问计数与慢内存的目标访问率进行比较. 然后, 最频繁访问的页面将被迁移回快速内存, 直到剩余冷页面的访问率低于阈值. 除了任何错误分类的页面之外, 此机制还标识随时间变热的页面, 适应应用程序热工作集的更改.
之后作者们对于 thermostat 进行了实现, 并测试了实际性能, 占了一半的篇幅.
随着 Intel/Micron 最近宣布推出 3D Xpoint 内存, 数据中心有机会降低内存成本, 提高容量和每比特成本. 但是, 由于这些新内存技术预计会有更高的访问延迟, 因此完全取代主内存 DRAM 技术是不可行的. 本文提出并评估了 thermostat, 一种基于应用程序透明的双层存储结构的透明巨页内存管理机制, 用于将页放置在双技术混合内存系统中, 同时实现两层内存的成本优势和透明大页的性能优势.
在内存占用较大的云应用程序中, 特别是在虚拟化云环境中, 需要在这两层内存系统中支持性能关键的巨大页面. 文章中针对此问题, 提出了一种新的热 / 冷分类机制来区分频繁访问的页面 (hot) 和不频繁访问的页面(cold).
最后, 作者们在 Linux 内核版本 4.5 中实现了恒温器, 并表明它可以透明地将冷数据移动到慢内存中, 同时满足 3% 的可容忍的速度减慢. 文章最终表明, 在线冷页识别机制不会产生明显的性能开销, 并且可以迁移到 50% 的应用程序, 同时将应用程序占用空间减少到 3%, 同时将性能下降限制在 3%, 从而将内存成本降低到 30%.
来源: https://www.cnblogs.com/yoyoyayababy/p/10603482.html