Making Dynamic Page Coalescing Effective on Virtualized Clouds——论文泛读
问题
在现代计算机系统中，转换后备缓冲器（TLB）容量不能与存储器容量相同的速率进行扩展[1，2]。地址转换开销已成为许多大内存工作负载的主要性能瓶颈[3-19]。在虚拟化云中，用硬件支持的嵌套分页支持内存虚拟化（例如，Intel的扩展页表[20]和AMD的嵌套页表[21]）。对于嵌套分页，为了解决TLB未命中问题，处理器需要遍历两层页表（即二维页面遍历），其成本可能是本地系统上TLB未中时遍历一层页表的6倍[12，20]。
大页是减少大内存工作负载的地址转换开销的主流方法，TLB条目可以缓存大页的页表条目（PTE），用于增加翻译地址数据量（例如，大页PTE的2MB与基本页面PTE的4KB）。显著增加了TLB覆盖范围，从而减少了TLB未命中，还可以减少页面遍历的步骤和页面遍历引起的内存读取。
为了创建大页，系统软件通常使用页面合并方法来动态组合连续的基本页，但它们在虚拟化平台上的有效性却受到了严重损害，因为需要二维页表遍历。本文发现，只有由主机大页支持的访客大页，才能有效地减少地址转换开销。现有的页面合并方法仅增加每层的大页，而没有考虑对大页对齐的跨层要求。当访客大页得到主机大页的支持时，称为对齐大页，可以充分发挥大页性能。当访客大页和主机大页未对齐时，称为错位大页，此问题可使性能降低67%。
本文方法
本文提出Gemini，设计为一个跨层解决方案，用于指导访客和主机中大页的形成和分配。一层的内存管理会感知到另一层的大页，并仔细管理与这些大页对应的内存区域。指导页面合并和大页分配时，首先考虑这些区域，然后再考虑其他内存区域。由于大页优先从这些区域形成和分配，而较少从其他区域分配，因此可以增加由主机大页支持的访客大页，而不会加剧大页带来的不利影响。
基于Linux/KVM和各种现实应用程序（如键值存储、web服务器和AI工作负载）中的原型实现的广泛评估表明，与最先进的页面合并方法相比，Gemini可以将TLB未命中率降低83%，并将应用程序性能提高126%。
实验
实验环境：DELLTM PowerEdgeTM T630，具有两个2.1GHz Intel Xeon E5-2620处理器，128GB DRAM，一个1.6TB SSD，一个Intel I350千兆网卡。每个处理器有8个物理核心，每个核心具有用于4KiB/2MiB页面的1536个L2 TLB条目，用于1GiB页面的4个数据TLB条目，用于4KiB页面64个数据TLB条目，用于2MiB/4MiB页面8个指令TLB条目，用于4KiBs页面64个指令TLB条目。
数据集：web服务器、数据库服务器、键值存储、人工智能工作负载、科学应用程序
实验对比：吞吐量、延迟、尾延迟、页面对齐数量、TLB缺失率
总结
针对虚拟化云场景，在主机端和访客端有不同的TLB，当二者的页面无法对其时会显著降低TLB性能。本文提出Gemini，用于指导访客和主机中大页的形成和分配。一层的内存管理会感知到另一层的大页，并仔细管理与这些大页对应的内存区域。指导页面合并和大页分配时，首先考虑对应区域，然后再考虑其他内存区域。由于大页优先从这些区域形成和分配，因此可以增加由主机大页支持的访客大页，而不会加剧大页带来的不利影响。
原文地址：https://blog.csdn.net/qq_36159989/article/details/136395696
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！