移动设备页缓存优化

更多精彩文章：页缓存优化 | 桃花猿记

预读算法

预读模式提高了Linux系统的读性能，但是在Android上直接使用传统的预读方案并不完全适用。
移动设备上的请求大小和页面缓存大小要小很多，可能导致降低预读效率，从而损害用户体验，比如很多预读的页面没有被使用，导致频繁的页面缓存回收，导致额外的延迟。
根据论文实验数据显示，传统的预读方案直接移植到移动设备，当预取100个页面到页面缓存时，平均大约有75个页面没有使用。

在当前的Linux内核中预读算法的不足：当一个请求属于顺序读操作时，将执行预读操作，预取大小为该读请求的2或4倍的页面。如果达到预读操作，预取页面的大小将增加上一次预读操作的2倍，直到达到预读的最大大小(默认128KB)。这种激进的预读方案会很快填满页面缓存。

预读算法主要功能和任务：

• 批量：把小I/O聚集为大I/O，改善利用率，提升系统的吞吐量
• 提前：对应用程序隐藏磁盘的I/O延迟，以加快程序的运行
• 预测：预读算法的核心，前两个功能的达成都依赖于准确的预测能力

文件预读算法的关键要点：

• 读数据是按页为单位进行，不需要考虑从页面内的偏移量，仅考虑文件的访问页面部分。
• 只要进程不断顺序读数据，预读可能逐渐递增。
• 当前的访问与前面的访问不是顺序时(即随机访问)，预读必须缩小或停止
• 当进程不断访问文件同一个页面时(仅访问文件的一小部分)，或者文件的所有页面均已在cache中时，必须停止预读。

Linux页缓存涉及的重要数据结构与函数如下：

以ext4读操作为例，函数调用流程如下：

预读算法的设计权衡：

• 预读大小对I/O性能有很大影响，在确定预读大小值时，必须在吞吐量和延迟、预读命中率之间、page cache利用率进行权衡。

• 针对冷热文件数据，优化数据预取，将热数据尽可能地预读到page cache中，会大大提高page cache的命中率，相对于冷数据角度而言也提高了page cache的利用率。如果尽可能地预读热数据文件页，由于移动设备上的请求大小和页面缓存大小要小很多，可能有很有很多热数据页没有用到，反而降低了page cache的利用率。

回收算法

直接回收

空闲空间不够当前分配时触发，同步回收，停止内存分配。可能触发数据回写操作，系统开销大。

kswapd周期回收

异步回收，可与内存分配同时进行空闲页数量低于阈值时回收。最大的回收可能达到几千页。

1. 内存回收方案与手机应用的特性不匹配。表现在以下两个方面：

• 回收的尺寸太大，尺寸是指每个回收操作释放的页数。

• 快速回收

• 直接回收
  空闲空间不够当前分配时触发。可能触发刷新操作。系统开销大。

• kswapd
  空闲页数量低于阈值时回收。最大的回收可能达到几千页。

• 有限的回收区域加重了这种惩罚。回收区域指回收操作释放的页面区域，例如inactive_file_lru链表中的页面。
  根据页面类型分类的lru链表还有：
  LRU_INACTIVE_ANON：不活跃匿名页面链表
  LRU_ACTIVE_ANON：活跃匿名页面链表
  LRU_INACTIVE_FILE：不活跃文件映射页面链表
  LRU_ACTIVE_FILE：活跃文件映射页面链表
  LRU_UNEVICTABLE：不可回收页面链表

1. 缺页产生的原因

• 第一次读取某个页，并没有分配物理内存。
• 读取一个错误的页，进程会被杀死。
• 读取一个被回收的页，请求的页面一直在内存中，但是被回收算法回收了。页面二次缺页率表示在被回收的所有页面中重新发生缺页的比例。

1. 影响性能的因素

• 二次缺页
  二次缺页受可用内存的大小影响。

• 直接回收

在页面分配过程中，当没有足够的可用空间来满足系统需求时会触发该方案。一旦触发直接回收，Android系统需要暂停分配过程，导致额外的性能下降。

直接回收取决于可用内存大小和后台异步回收的延迟。

• 后台应用程序不会对用户体验产生影响，但也在继续申请空闲空间。
  由于匿名页包含与进程关联的堆信息，因此这些匿名页被认为比文件页对进程更重要。大多数情况下，ACTIVE_ANONAME列表中的页面不会被逐出，即使它们属于后台应用程序。因此，后台应用程序的许多匿名页保留在存储器中，而来自前台应用程序的文件页被逐出。这些从前台应用程序逐出的文件页面可能很快会再次被访问，从而导致大量页面重新错误。此外，后台应用程序的匿名页面会占用空闲空间，从而影响直接回收的频率。

• kswapd后台回收通常大于32个页，而Android系统申请页通常小于16个页。最终为每个小的分配进行较大的回收，导致回收十分激进。较大的回收大小会延长后台回收的延迟，进而影响直接回收的频率，此外回收较大的粒度会导致更多不必要的refault。

1. 解决思路

• 在回收文件页之前考虑先回收后台进程使用的匿名页，因为前台进程在用户体验上来说比后台进程要重要。
• 降低伙伴算法的阶数，移动设备最大的请求阶数为8，可以将order降低到9。降低拆分大空间的操作的次数。

PS：前往公众号“知书码迹”，可以查看最新内容！关注即可免费领取面试&Linux技术书籍！