2.5.13 动态内存扩展AME

最后更新2021/08/01

AME技术目的是压缩内存中的数据，因此减少物理内存使用量，从某种意义上提升系统IO性能。个人看来，这是个有毒无用的功能，因为AME的基础是用CPU的部分算力，尽管可以是额外的晶体管实现，不会占用原有指令处理能力，但毕竟CPU单位成本要远高于内存。换句话说，内存性能之所以滞后于CPU，并不是内存做不到高性能，而是基于成本考虑，用高成本的CPU芯片集成去满足稍低成本的内存需求，显然有些得不偿失。如果单独为了内存压缩，我想IBM Power CPU的设计者不会搞不清成本，其实AME只是一个更重要功能的附带产品，这个功能就是内存加密，实现真正端到端的信息保密（但现在还没有在Power/AIX架构上正式推出产品，只在IBM Mainframe上有实现），也就是说通过内存加密，只有CPU当前访问的特定指令和数据页面的数据是明码，即使另外一个获得OS授权的另一个内核线程可以访问这部分数据，如果没能拿到访问密钥，其获得的数据都是密文，这算是IBM Power CPU在拓展自己能力的时候的一个试探吧。

CPU、物理内存和系统总线是计算机系统中最主要的电子元件，他们一直在遵循摩尔定律，持续稳定地提升速度、提高容量，但这三者进化的速度之间是有差异的。目前，早些时候，CPU的速度提升显然快于内存容量提升，更快于总线速度提升。为应对系统总线速度提升缓慢的问题，Power CPU很早之前就设计了内置多级Cache和Cache控制器技术，而AME技术又创新式地拓展了Cache的使用方式——内存（包括Cache）中的数据可以通过CPU进行实时、动态的压缩、解压缩。由于CPU仅仅对当前需要处理的内存数据进行压缩、解压缩，虽然增加了CPU的额外工作量，但如果总体负荷并不大，更重要的是所有工作都对CPU执行的程序透明，除了分区启动参数设置，无需任何额外操作。另外，AME以分区为单位进行设置，可以只应用于特定的分区。因为我们知道，对于进行高强度数学运算的应用、经常进行图像编码/解码的应用，此功能可能会起反作用，因为前者数据量较小而CPU繁忙，后者数据的数据通常已经进行过压缩，不能再进一步压缩。

某个分区设置了AME动态内存扩展功能之后，当分区启动激活profile时，会根据相关参数设定自动开启压缩、解压缩功能，而被压缩的内存的数量则根据CPU负载和分区参数由操作系统自动调节。OS把所有的“物理内存”存放在两个内存管理池中：

• Compressed pool压缩池
• Uncompressed pool非压缩池

OS根据数据使用情况在两个池之间移动数据。当前使用的数据内存块一定在非压缩池中，而未使用的数据内存块则保存在压缩池中。当应用程序需要访问的数据内存块位于压缩池中的时候，Power架构会产生“数据访问中断”，此过程与OS的vmm paging space管理方式相同，所不同的是触发的动作不同。如果是由于数据位于压缩池而产生的数据访问中断，OS会调用AME数据移动功能，将数据内存块（如果激活使用AME功能，AIX只能使用4KB大小的内存块）解压缩并由压缩池“移动”到非压缩池，解压缩动作由CPU自动完成，OS仅仅需要发出控制指令；如果是由于数据不在物理内存（注意：无论是压缩池还是非压缩池中的数据内存块都在物理内存中）而引起的数据访问中断，则由OS触发文件系统数据读入或者Paging Space数据读入操作，完成磁盘到内存的数据移动。

随着应用程序使用到的内存增多，非压缩池中的数据内存块也越来越多，当非压缩池容量达到极限时，OS根据数据内存块最后使用情况，将非压缩池中的不常用数据“移回”到压缩池中，同时完成数据压缩过程。压缩池和非压缩池的大小（比例）由分区参数设定，如<图 270 AME参数示意>所示，图中内存扩展参数(Memory Expansion Factor)为1.5，则实际分配物理内存1GB，但OS动态扩展出1.5倍，即1.5GB。
图 286 AME参数示意

使用AME功能只需要设置一个参数，即Memory Expansion Factor内存扩展比。AIX自动以此参数乘实际分配给分区的物理内存所得的总量作为显示给应用程序的“真实”物理内存量。如果设定Factor为2，而分区分配的物理内存是20GB，则AIX显示给应用程序的总“物理”内存数量为20×2=40GB。内存扩展比参数也可以动态调整，使用HMC的DLpar功能即可，调整之后AIX“显示”的内存数据会根据计算结果会根据LMB大小圆整到最接近的数值。

内存扩展比只是参考值，在实际运行中不一定实现。如果内存数据可以大幅压缩，扩展比超过设定值，我们无需关心这个问题，因为只要能够达到压缩目标，剩余的数据可以不压缩，CPU可以早一点休息。我们需要考虑的是内存数据扩展比达不到目标的情况，既“Memory Deficit内存赤字”情况。例如设定扩展比为1.5，而物理内存为20G，则扩展的目标是30GB，然而实际上数据压缩不了这么高，只实现了1.4，即压缩了15GB数据之后就已经填满了10GB真正的物理内存，无法继续进行扩展（压缩），同时所有的内存数据都是压缩后的数据（在压缩池中），应用程序也无法继续执行，因为应用程序只能使用非压缩池中的数据，每次应用访问的数据在压缩池中，就会引起CPU中断，非压缩池中的数据量太少（实际情况不可能为0），会频繁导致中断产生，系统运行效率大大降低。

实际上，AIX有内置的参数95%作为压缩池的极限，即如果压缩池填充到物理内存的95%依然没能实现扩展比目标AIX也不会继续压缩数据。20GB的95%为18GB，剩余2GB，也就是说在本例设定中，只要非压缩池大小小于2GB，扩展比目标即使没有实现，AIX也不会继续进行内存压缩，以避免发生内存压缩抖动（类似paging space trash情况）。

同时，应用程序可用物理内存大小为： 2GB+18GB×1.4=27.2GB，而不是理想中的30GB，中间有2.8GB的“赤字”，如<图 271 AME示例>所示。当系统总物理内存使用量达到27.2GB则会触发paging space交换。当然，如果应用对物理内存的使用低于27