3.1. 虚拟内存管理#
3.1.1. cont pte#
Transparent Contiguous PTEs for User Mappings
使用contpte mappings, 连续设置pte的位
variable order, large folios for anonymouns memory
处理anon page faults时，申请大内存块，从而减少page fault, 批处理PTE和RMAP操作，较少lru list 长度等，减少内核开销。
映射连续的物理内存，后续可以使用硬件的TLB压缩("the contiguous bit" and HPA), 减少TLB 的压力。
猜测芯片的实现：MMU中，假设会检测内存虚拟地址是否属于64K大页。先将虚拟地址&64K的mask,这样得到 此64K大页的基地址（假设此page属于64K大页的范围），MMU遍历TLB，如果找到此基地址的entry, 继续 检测contiguous bit是否置位，如果置位则说明后面的连续物理页为大页的一部分。
3.2. 动态隔离与动态大页#
3.2.1. 竞品分析#
Cisco在关于SP业务边缘转型的材料中提到在基于K8s的虚拟化平台上支持动态大页分配的特性。
3.2.2. 背景#
随着硬件的飞速发展，服务器的内存越来越大，系统中使用的内存越多，管理该内存所需的资源也就越多。使用 大页内存取代传统的4K内存页面，可有效提高TLB缓存命中率，减少页表查询，提高内存访问性能。
大页内存在容器、网络IO、数据库等领域被广泛使用。
在容器场景中，实现对1G/2G两种大小的大页混合使用，可以有效提高产品性能，同时减少存储资源的浪费。 当前基于K8s的容器系统只能静态设置部署容器内使用的大页数量,重新部署需要重启服务器，不够灵活。
当前Linux系统中有两类大页：标准大页和透明大页。
3.2.3. 问题#
标准大页对用户可见，通过与分配的方式管理。用户主动申请使用。透明大页对用户不可见，用户申请使用后， 在触发内存分配时由系统决定是否使用。
标准大页预分配后，只能作为固定大小大页使用，使其他大小的页面内存变少，不够灵活。
透明大页由系统控制分配，可能造成严重的资源浪费，并且也存在内存延迟分配的性能问题。
当系统运行一段时间后，由于内存碎片化，存在内存很多但无法分配出大页的情形。
3.2.4. 解决方案#
基于分组的动态大页内存管理：以组为节点统一申请/释放，保证了使用前后不会造成严重的碎片化。
基于拆分/合并的物理页动态转换机制，可在组内进行不同大小的物理页间的相互转换，从而满足进程对 不同大小的物理也的需求。
在用户不感知的情况下，进行物理页的动态转换，满足用户对不同大小的物理页的需求。
与标准大页预分配的配置方案相比，动态大页配置方案更加灵活。
与透明大页的用户不感知的方式相比，动态大页的使用仍然需要用户主动申请，可控性更高，也符合当前用户的 使用方式。
3.2.5. 反向映射#
对于一个物理页，找到所有映射它的（虚拟地址空间+虚拟地址）的组合，主要目的有：
回收文件页时解除它的所有映射
回收匿名页时要将它的所有映射换成swap映射