背景
測試環境：
測試設備：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數據和較大的數據，從而減少寫放大寫係數。