英语原文共 9 页
Android系统中的Linux页面错误分析
摘要
在现代智能手机中，系统性能与各种底层子系统紧密相关。特别是，多年来，内部存储变得至关重要，因为它被广泛用于访问与系统相关的内容，最终用于最终用户。为了理解它在商业Android智能手机中的作用并评估其对用户体验的影响，在实际使用的背景下，我们分析了Linux页面错误处理，这是一种对存储设备施加压力并可能导致的关键机制系统效率低下的机制。内核跟踪技术被设想用于商业智能手机上的Android应用程序和服务的实时测量。这项工作中提供的实验结果来源于在配备UNIX文件系统的存储子系统的64位Android智能手机上使用此内核跟踪。该研究的主要主题是主要的页面错误处理，这是许多最终用户行为背后的核心机制，在行业层面被认为是智能手机可能性能下降的根源。分析表明，主要的页面错误处理主要是对UNIX文件系统的读取访问（占总时间的30％到40％），并且相关的存储流量受Linux的文件预读机制的显着影响，这并不总是有效的。
1.介绍
多年来，移动操作系统、系统级芯片、外围设备、主存储器、嵌入式和可移动存储已经有了很大的发展（图1），并且经历了复杂性增长，以维持移动用例所需的性能水平。在这种情况下，存储子系统已成为满足最终用户期望的关键。在不到10年的时间里，移动存储特性得到了提升，可以提供更高的性能并支持以移动为中心的功能（例如，重放保护内存块、启动、各种保护模式、固件更新管理、断电）。就性能问题而言，一方面接口速度从52 MB / s（eMMC 4.41）增长到1.2GB / s（ufs 3.0） - 参见图2 - 提供适合多媒体用户的带宽。另一方面，命令排队已获得整个存储软件堆栈的支持，以增加由多个操作源到磁盘同时执行和生成的事务的数量。
图1三星Galaxy智能手机的嵌入式和可移动存储密度趋势（2010-2018）
图2三星Galaxy智能手机的嵌入式存储接口速度（2010-2018）
要了解它在商业Android智能手机中的作用，并在其背景下评估其对用户体验的影响。
作为一种实际用法，我们分析了Linux页面错误处理，这是一种对存储设备施加压力并可能导致系统效率低下的关键机制。Android活动的基础即Linux进程在尝试访问属于尚未加载到主内存中的页面缓存的内存映射文件的虚拟内存页时，可能会遇到严重的页面错误。 在这种情况下，Linux内核也将使用ReadAhead读取围绕所需页面的一组页面。
谷歌正式将此机制作为“与抖动相关的jank问题”的来源之一。由于主要页面错误导致对存储设备的内容访问可能会阻止最初需要访问的线程，如果它发生在UI呈现的关键路径上，则UX将受到影响（例如，通过延长应用程序启动和 应用程序切换或冻结显示屏上的框架）。 这种现象严格地与存储设备QoS（在不同条件下读取操作的短响应时间 - 空/满，新开箱即用/老化，非分段/分段）以及引入的开销有关。系统（例如，IO调度器处理时间，软件驱动程序复杂性，在某些条件下读取路径上的文件系统效率低）。
一些作品旨在表征存储性能，而不是专门检查页面错误处理程序，而其他人分析了这个主题，但没有在商业移动平台上。这项工作通过量化整个移动存储堆栈中的主要页面错误处理效果来填补这一空白，并且特别关注ReadAhead角色。
我们开发了一个实时内核跟踪，用于在实际使用过程中量化存储子系统在商用Android智能手机中起作用。此外，我们还定义了在Linux页面错误处理期间评估存储子系统性能的方法，最后在运行时执行测量。所提供的实时跟踪技术可用于观察非最佳资源使用（例如，页面错误的数量）、系统不足（例如，处理故障的时间）和权衡（例如，ReadAhead大小与使用的页面）。
在现实使用案例中，这项工作中的实验结果来源于我们的技术在配备ufs存储子系统的商用64位Android智能手机（三星Galaxy S6）上的应用（一种替代eMMC的解决方案[5] [6]作为首选的内部存储设备）。使用不同最大尺寸的ReadAhead缓冲区重复实验，以显示此预取技术如何影响存储子系统流量和性能，以及评估此解决方案在移动应用程序中的效率。
例如，结果显示了一个小的ReadAhead窗口大小如何减少处理页面错误的时间，但增加了它们的总数。它们还表明处理主要页面错误的时间部分是由于存储硬件（处理请求的总时间的30％到40％），而大部分时间是由操作系统来解决页面错误例程的各个阶段。最后，它们表明，就我们采用的用例而言，ReadAhead在调用者进程实际使用的预加载页数方面的效率约为30％。
本文的其余部分安排如下。第2节介绍了本研究在Android和Linux页面缓存和页面错误处理机制方面的背景。第3节中定义了采用的度量标准，第4节报告了在内核级别采用的用于测量度量标准的跟踪技术。第5节介绍了实验设置，第6节报告了跟踪结果。最后，第7节讨论了可能的系统级别的优化，第8节结束了论文。
2.背景
在本节中，我们将回顾一些与分析的适用环境和Linux内核内部相关的基本概念。
2.1 Android应用和终端用户的习惯
在过去几年中，智能手机的使用率呈指数增长。事实上，如今全球用户更喜欢使用移动设备而不是台式PC。此外，娱乐应用占据了移动设备上花费的时间份额（图3）。 这些类型的应用程序大大增加了存储子系统的压力。如果我们考虑典型的日常使用情况，那么从存储设备读取的数据会在最近的几代智能手机中大量增长（图4）。
图3共享移动应用类别时间
图4最近几代智能手机的平均每日流量读数
通过考虑最终用户的习惯，它看起来是存储日常读取数千兆字节的原因之一，用于执行应用的程序如图5所示，每天使用的应用程序数量如图6所示。长时间运行丰富的应用程序并在一天内多次切换它们可以确定对存储子系统的多个IO请求。在基于Linux的系统中，例如可能会给存储设备带来压力的基础设施之一的Android设备，是第2.3节中进一步描述的页面错误处理，并突出其在内存层次结构中的作用。
图5 2017年美国每日用户在移动设备上使用数字媒体所花费的时间
图6每天使用的平均应用数量（Q1-2017）
2.2页面缓存
页面缓存是一个实现Linux内核组件的磁盘缓存，用于内核和用户进程使用的文件（图7）。它是Linux虚拟内存管理中的主要参与者之一。
图7 android系统中的OS堆栈
此缓存的目标是通过存储数据来最小化磁盘I / O，否则需要存储访问的物理内存。该页面缓存由系统主存储器中分配的空间组成。文件访问的最小粒度与物理对齐内存页面大小（移动系统中为4kB）。 当一个过程执行时，可能会发生文件访问：相应的虚拟内存页面由进程本身和此操作引用可能会生成页面错误。
2.3页面错误
页面错误是处理页面缓存错误的内核机制。进程尝试访问时会触发页面错误，此情况存在于虚拟空间地址中但不存在于物理地址中的页面记忆。 Linux内核将页面错误作为例外进行管理。当用户进程触发页面错误时，内核将获得控制权检索丢失的页面并将其加载到主内存。根据丢失页面的位置，我们可以有一个次要页面错误或主要页面错误。
当缺少的页面存储在物理内存中时，就会发生轻微的页面错误，但它没有映射到虚拟内存中的记忆页面。 这种类型的页面错误称为次要错误，因为与主要页面错误相比，它们的延迟较低。
众所周知，主要页面错误是高延迟操作，可能会破坏性能。当缺失页面位于存储子系统中时，主要页面错误就会发生。要解决页面缓存错误，内核必须通过所有I / O堆栈来传输页面。
2.4 ReadAhead例程
ReadAhead（RA）例程是一种预取机制，它试图预测正在执行的进程将在通过页面错误实际请求的进程旁边引用哪些内存页面。引入它是为了最大限度地降低与未来页面错误相关的成本。与常规主要页面错误机制相比，即使是次要页面错误也可以触发RA。在这种情况下，生成页面请求而不实际阻止正在运行的进程。
除了请求的RA例程之外，RA例程从存储子系统读取的页数可以通过名为RA Window的参数来设置。它定义了可以预加载的页数的上限。我们已经进行了几项改变RA窗口大小的测试，以评估RA算法的有效性及其对存储性能的影响。
3.指标
在这项工作中使用了四个指标：页面错误频率，主要页面错误处理延迟，空间效率和读取流量。
3.1页面错误频率
页面错误频率用来计算测试会话中发生页面错误的数量，进一步详细说明如下：
bull;具有预读频率的主要页面错误 - 需要解决I / O访问的页面错误部分，以及触发RA例程;
bull;主要页面错误频率 - 需要I / O访问但未触发RA例程的页面错误部分。
3.2主要页面错误处理延迟
主要页面错误处理延迟用于测量内核解决任何类型的主要页面错误所需的时间，在页面错误处理期间其有助于发现各种类型的问题。延迟度量可以进一步分解，如图8所示，以识别可能的内核问题，或确定系统中的瓶颈。
图8主要页面错误延迟分解
为了定义延迟指标，已经考虑了主要页面错误处理过程的分类。每个delta标识以下两个事件之间的时间段：
bull;故障识别：从页面故障处理开始到识别故障类型（次要或主要）所需的时间;
bull;主存储器预留：在识别出主要故障后需要的时间，为一个或多个页面保留存储器;
bull;文件系统操作：在主存储器预留之后，从存储子系统获取页面所需的时间;
bull;I / O调度程序操作：在提交请求之后所需的时间，以安排读取操作并最终将请求与其他请求合并;
bull;硬件（HW） 软件驱动程序（SWD）操作：从存储设备获取页面所需的时间。它考虑了OS的存储软件驱动程序执行时间以及HW（主机控制器和存储设备）读取所请求数据所花费的时间;
bull;故障解决：获取一个或多个页面后允许内核进程恢复故障处理程序所需的时间;
bull;表更新：故障恢复后更新内存管理表所需的时间;
bull;故障关闭：更新内存管理表后关闭故障处理例程后所需的时间。
3.3空间效率
空间效率基于以下事实：只有由ReadAhead机制预先提取的页面的子集才会被进程使用。使用的页面与通过ReadAhead加载的页面之间的比率表示RA启发式的效率。低RA效率可以揭示预取算法是低效的。
3.4读取流量
读取流量表示从存储子系统传输到主存储器的数据量，它可能是一般的流量或由于页面错误而引起的流量传输，它可能受到RA机制的影响，并且它被分为五个系列：
bull;通用流量;
bull;RA的通用流量;
bull;RA的次要页面错误流量;
bull;主要页面错误流量;
bull;RA的主要页面错误流量。
4.内核跟踪
为了通过第3节中定义的度量来表征页面错误，已经进行了内核逆向工程以识别页面错误机制中涉及的内核函数。被测设备（三星Galaxy S6）的内核无法收集所有需要的数据。 为了克服这些限制，我们利用Linux跟踪实用程序ftrace（函数跟踪器）功能来添加根据我们的要求定制的自定义事件。在分析了设备内核源代码之后，我们发现了已定义的度量与Linux内核功能之间的关系;见表1。例如，内存管理模块中的内核函数“Filemap fault”识别页面错误类型（主要或次要）。因此，要计算测试会话中发生了多少页面错误并量化页面错误频率度量标准，需要在此类内核函数中使用自定义跟踪事件。
表1度量和相应的内核函数
已经仔细修改了已识别的内核函数，以在代码中插入所有需要的ftrace事件。 此修改的结果是新的ftrace事件，可帮助我们跟踪内核活动。
5.实验装置
在本节中，我们将介绍用于实时跟踪的智能手机，实验设计和建议的用例。
5.1被测设备
被测设备是三星Galaxy S6智能手机（国际版），其规格总结在表2中。该平台未经过任何硬件修改，操作系统是库存更新版本。
表2三星Galaxy S6的特色
5.2实验设计
为了表征页面故障机制和RA技术的相关影响，使用Galaxy S6 RA Window默认配置（256kB）并根据表3改变最大RA窗口参数来执行设备上的实验。
表3实验配置的设计
5.3用例
为了在页面缓存中同时具有标准文件I / O和存储器映射文件，并且为了刺激与存储设备的交互，已经构思了特定的使用模型。 在Google Play商店中，Android用户中一些最受欢迎的应用程序已被选中：Gmail，Facebook，Google日历和Google地图。
对于每个应用程序，已经定义了一组最常见的动作（例如，Facebook主页浏览或谷歌地图导航）。 该序列通过使用Android脚本工具来执行，以避免人为干扰并
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
