Overall Performance

在這一節中我們針對三種通道管理方法的最佳組合，調整各種參數來觀察整 體的表現。以下將針對獨立通道搭配 Cycle Stealing 以及同步運作通道兩個方法進 行實驗。為了更公平的比較，我們同時給予兩種運作機制 32KB 的緩衝區空間，

28

以及 Throttle 皆限制為 8。緩衝區的管理將以 page 為單位搭配簡單的 FIFO 來運 作。4.3.1 將觀察不同 workload 的影響，4.3.2 將觀察不同通道數量的影響，4.3.3 將觀察不同 overprovision 比例的影響，4.3.4 將觀察不同種類的快閃記憶體的影 響。

4.3.1 Effect of Workload

這一個小節我們將觀察不同 workload 所造成的影響。使用的硬體設定為四 個通道、2.5% overprovision、MLC 的快閃記憶體模組、32KB 的緩衝區空間及 Throttle 設定為 8。圖表 22 為四種不同 trace 針對獨立通道搭配 Cycle Stealing 以 及同步運作通道的實驗結果，縱軸為跑完整個 trace 所花費的時間。為了方便觀 察 其 平 行 度 ， 長 條 圖 將 分 為 使 用 者 request 寫 入 所 花 費 的 時 間 （ 包 含 read-modify-write 的 read）以及內部處理 GC 所花費的時間兩部分。

0

(a) Random trace

0

(b) Sequential trace

0

(d) Ubuntu trace 圖表 22: Effect of workload

29

在圖表 22 中，我們可以看到不管在哪一種 trace，獨立通道搭配我們提出的 三種管理方式都比同步運作通道效能還要好。使用者 request 寫入所花費的時間 由 Gating Buffer 來改善，內部處理 GC 所花費的時間由獨立通道搭配 Cycle Stealing 來改善。Gating Buffer 在獨立通道表現比較好，因為獨立通道可以同時平行寫入 不同的 request。同步運作的通道因為必須要寫入 super page 而無法平行寫入屬 於不同 super page 的 request。獨立通道搭配 Cycle Stealing 可以大幅改善 GC 效能 在 4.2.1 中有詳細的說明，主因為小資料隨機寫入造成浪費空間使 GC 觸發頻率 增加。在圖表 22 (b)中，因為大部分的 request 都是連續的寫入，兩者的效能幾 乎都一樣，但是其中還是會參雜一些小資料的隨機寫入，所以獨立通道搭配 Cycle Stealing 還是會比較好一點點。

圖表 23 中獨立通道搭配 Cycle Stealing 的效能會比同步運作通道來的好、時 間花得比較少。其時間減少可以分為使用者 request 寫入所花費的時間減少與內 部處理 GC 所花費的時間減少兩部分，圖表 23 將這兩部分畫成圓餅圖，由此來 觀察這兩部份的貢獻程度。在圖表 23 (a) Random trace 中，因為小資料隨機寫入 的原因，所以主要的貢獻為獨立通道改善浪費空間的問題。而在圖表 23 (c) WinXP 及(d) Ubuntu 這兩個正常使用的 trace 就可以發現 Gating Buffer 增加寫入平行度 有超過三分之一的貢獻。甚至在圖表 23 (b)複製大檔案時，因為 GC 的效益很高，

Gating Buffer 就成為了主要的貢獻。

(a) Random trace (b) Sequential trace

(c) WinXP trace (d) Ubuntu trace 圖表 23: Contribution of parallelism

4.3.2 Workload VS Channels

這一個小節我們將觀察提升通道數量對不同 workload 所造成的影響。使用 的硬體設定為 2.5% overprovision、MLC 的快閃記憶體模組、32KB 的緩衝區空間

30 間，還可以利用 Gating Buffer 收集不同通道的 request，以便於同時平行寫入。

同步運作的通道只有在大量連續資料寫入的情形下才會表現出多通道的優勢，而

1ch 2ch 4ch 8ch

IOPS

channels Random Trace

Synchronized Independent

(a) Random trace

0 100 200 300

1ch 2ch 4ch 8ch

IOPS

channels Sequential Trace

Synchronized Independent

(b) Sequential trace

0

1ch 2ch 4ch 8ch

IOPS

1ch 2ch 4ch 8ch

IOPS

channels Ubuntu Trace

Synchronized Independent

(d) Ubuntu trace 圖表 24: Effect of channels

31

4.3.3 Effect of Overprovisioning

這一個小節我們將觀察提升 overprovision 的比例所造成的影響。使用的硬體 設定為四個通道、MLC 的快閃記憶體模組、32KB 的緩衝區空間及 Throttle 設定 為 8。圖表 25 為不同通道數量在獨立通道搭配 Cycle Stealing 以及同步運作通道 的實驗結果，縱軸為 IOPS，橫軸為 overprovision 的比例。

在圖表 25 中，我們可以發現隨著 overprovision 的比例增加，效能會越來越 好。而且隨著 overprovision 的比例增加，四種 workload 效能增加的比例為 (a)>(c)>(d)>(b)。這是因為越多的 log 區域可以存放並收集越多屬於同一個 data block 的資料，然後在一起回收減少 GC 的負擔。所以小資料隨機寫入的比例越 多，增加 overprovision 比例就可以獲得越多的效益。

0

(a) Random trace

0

(b) Sequential trace

0

1.25% 2.50% 5.00% 10.00%

IOPS

1.25% 2.50% 5.00% 10.00%

IOPS

Overprovisioning Ubuntu Trace Synchronized Independent

(d) Ubuntu trace 圖表 25: Effect of overprovisioning

32

圖表 26 為四種 workload 在獨立通道搭配 Cycle Stealing 下增加 overprovision 比例所測量的結果。使用的硬體設定為四個通道、MLC 的快閃記憶體模組、32KB 的緩衝區空間及 Throttle 設定為 8。可以看到 Random trace 可以隨著 overprovision 的空間增加而大幅度上升效能，而 Sequential trace 上升的效果最為平緩。在一般 使用的 workload 中，一開始效能會有大幅度的增加，但是到 overprovision 比例 超過大約 10%之後，效能的提升就會漸趨平緩，而 Ubuntu trace 會比 WinXP trace 更早平緩。這就是因為小資料隨機寫入的比例越高，就需要越多的 log 區域，而 當 log 區域的空間超過所需之後就會漸趨平緩。

圖表 26: Benefit of overprovisioning

4.3.4 Effect of Geometry

這一個小節我們將觀察不同種類的快閃記憶體所造成的影響。使用的硬體設 定為四個通道、2.5% overprovision、MLC 的快閃記憶體模組、32KB 的緩衝區空 間及 Throttle 設定為 8。圖表 27 為不同種類的快閃記憶體在獨立通道搭配 Cycle Stealing 以及同步運作通道的實驗結果，縱軸為 IOPS，橫軸為 MLC（page size 4KB，

block size 512KB）及 SLC（page size 2KB，block size 128KB）。

在圖表 27 中，我們可以發現 SLC 的效能都會比 MLC 來的好，這主要的原因 是因為 MLC 寫入 4KB 需要 906 ms 而 SLC 寫入 4KB 只需要 306 X 2 = 612 ms 的原 因。另外也可以發現在 MLC 中獨立通道可以贏比較多，這是主要是因為 MLC 的 page 比較大，同步運作的通道會有比較大的 super page，所以在面對小資料隨機 寫入的時候會浪費更多的空間。

33

(a) Random trace

0

(b) Sequential trace

0

(d) Ubuntu trace 圖表 27: Effect of Geometry

34