作者 硅格-JC
背景
测试环境：
测试设备：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。
