安卓平台IO特性分析

背景

测试环境：

测试设备：Nexus5，32GB SanDisk INAND eMMC 4.51，无外挂SD卡。

操作系统：Android v4.4

IO监控软件：作者自己搞的BIOtracer

测试内容：

    选取常用的14个软件，和4个系统功能。那么有18个应用场景和它们一些组合应用场景（电话、空闲和启动手机也简单认为是应用程序之一）。详细如下：

数据记录：

     命令请求的大小、类型、位置和响应时间、 service time, and inter-arrival time。和请求并行程度。

测试数据：

    A. eMMC吞吐量

     上图是从25种测试case中获取的数据的平均值。可以看到，请求数据大小对eMMC吞吐量有很大影响。因为Flash读操作比编程用时短，所以可以看到读的极限速度比编程写命令要高很多。

    B. 数据大小关联性

      表格项说明：

Data Size：所有命令请求数据总量

Number of Reqs：命令请求数

Max Size：单个请求最大数据包的大小

Write Reqs Pct：写操作占命令的百分比

Write Size Pct：写操作数据量大小占数据传输的百分比。

       规律：

1. 因为有packing command这个特性，所以数据请求大小可以超过Linux的限制512KB。

2. 命令平均请求长度一般在11KB到34.5KB之间。

3. 大部分使用场景下，写请求比较多。

特性1：绝大部分手机应用都是以写操作为主。

     18个应用的写操作大小分布如图4所示。可以看到小数据操作占了大部分，大数据请求占百分比很少。最后10个互联网应用的大小分布，命令请求大小；分布比较类似。

特性2：小数据请求占了所有请求的大部分。

    C. 时间相关性分析

Recording Duration：数据记录的时间

Arrival Rate：每秒种命令请求次数。

Access Rate：平均每秒钟数据请求量

NoWart  Req. Ratio：指那些被马上执行的请求的比率。意味着当时没有进行中的命令，这些命令可以被马上执行。

Mean Serv：命令平均服务时间

Mean Resp：命令平均响应时间

     待机、打电话和Youtute的data access rate很低。系统启动时，每秒请求量比较高，主要是读操作。程序安装，每秒请求次数和数据传输量都比较高。15个应用中，最低有63%的请求可以马上执行，其中有10个应用的80%请求可以马上执行。

    

特性3：大部分请求到达的时候可以被立刻执行。也就是说，很少请求会同时到达。

     从表格IV看到，手机待机、通话中、YouTube和微博这种平均一秒都还不发不到一条命令的应用，平均响应时间还更久。z这是因为eMMC在无操作一段时间后会进入低功耗模式，唤醒初始化到响应命令需要一段时间。

     特性4：在eMMC空闲时间超过阈值，eMMC会进入低功耗模式。因此有些周期性访问eMMC的设备，导致eMMC频繁在低功耗模式和正常模式间切换，这样会导致平均相应时间变慢。

     Spatial Locality（空间局部性）：顺序访问所占的比率。

     Temoral Locality（时间局部性）：重复存取同一个地址的比率。

     18个应用场景中，16个空间局部性比率是低于30%的，即使在所有应用场景中最多也是48%。时间局部性会普遍好点，18个应用场景中，11个处于于30.83%到52.9%的。总的来说，相对于服务器级别应用局部性原理的二八定律，上述测试的应用看起来不太符合。

     特性5：测试应用场景，局部性的特性不明显。其中空间局部性比时间局部性要低。

    

从表格5可以看出，大部分的命令都可以在2ms内完成，绝大部分在16ms内完成。我们发现响应时间分布和请求大小分布是有很强关联性的。可以发现相应时间大部分是取决于命令请求的大小。

     表格6显示各应用命令请求的时间间隔分布。看电影的时候大部分请求间隔都在1ms以内。从中也可以看到互联网应用的请求时间间隔分布是类似的。本地的一些应用，比如说“看电影”、“听音乐”等命令请求频率会比互联网应用要高。

     特性6：在大部分应用中，平均请求间隔均比较久。其中13个应用命令间隔大于200ms，另外10个应用中，超过20%的命令间隔大于16ms。

D. 同时运行多个应用的IO分析

    在大部分情况下，手机用户会在前台执行一个应用，后台同时有多个服务在进行。一种情况是，手机用户会在刷微博的同时听音乐，然后挂者微信或者QQ。另一种情况，客户可能在看朋友圈的时候来了短信，然后切换到短信中，看完短信又切回朋友圈。

    在此，作者收集7种应用组合的请求来进行IO分析。大致有{音乐，微博}、{音乐、短信}等比较常用的组合。

     图7分别表示7种组合应用请求大小分布、相应时间分布和命令请求间隔分    布。图7A的请求大小分布情况和图4相差不大。

     图7B所示，组合应用的相应时间和单个应用时间其实也相差不大，没有明显的增长。比如说Music/WB平均相应时间3.61ms，单个应用上Music、WB分别为3.45ms和5.2ms。

     图7C所示，组合应用的命令间隔普遍还增加了。7种应用组合命令间隔范围大概为44.8ms到164ms。

    

另外，由于Host资源的局限性，所以组合应用的每秒请求次数和每秒数据传输速度是比单个应用的值相加还要高。总的来说，多个应用同时执行的情况下，IO特性都比较稳定的。（PS:测试应用比较偏日常使用，没有很多数据密集型的应用）。

    表格4最后几项关于应用组合测试的，可以看到大部分请求都可以马上被执行，所以即使在多应用运行的情况下也是不需要并行处理机制的。

eMMC设计建议

     基于上篇和上面的分析情况，给eMMC的设计者一些建议。

建议1：

     在大部分应用情况下超过80%的请求都可以被立即执行，只有少量的并行请求。所以没必要在设备层提高并行性能（比如说使用SD卡），或者在系统层面提增加并行请求队列支持。外置SD卡性能较低，反而会降低的性能。

建议2：

     eMMC FTL需要根据平台IO特性来进行优化。例如之前实验中，发现应用命令间隔为200ms，FTL可以在这段间隔内进行垃圾回收，这样可以提高用户体验。

建议3：

     所有应用的测试结果显示时间局部性和空间局部性不明显，所以eMMC中一个大容量的ram缓存对性能的提高就不是特性明显了。(还是很有用的~)

建议4：

     由于局部性不明显，表示Host会对eMMC不同的地方都会进行访问，所以eMMC使用一个简单的磨损均衡方案就可以了。

建议5：

实验数据显示大部分应用一般的命令大小4K，快速处理4K请求会提高eMMC的整体性能。SLC Flash可以提供更加高效的读写命令(PS：道理我都懂，SLC贵啊)。

其它：

作者还虚拟了一种Flash 4KB和8KB，分别用于存放4K数据和较大的数据，从而减少写放大写系数。

                                                  

END