Methodology (1): Device state Measuring Samsung SSD RW - - PowerPoint PPT Presentation

Host-­‑SSD ¡Co-­‑Design: ¡ ¡

Some ¡Lessons ¡Learnt ¡and ¡Perspec7ves ¡

Philippe ¡Bonnet ¡– ¡phbo@itu.dk ¡ IT ¡University ¡of ¡Copenhagen ¡ ¡ Joint ¡work ¡with ¡Luc ¡Bouganim ¡(INRIA), ¡Niv ¡Dayan ¡(ITU), ¡Ma7as ¡Bjørling ¡(ITU), ¡Jesper ¡Madsen ¡(ITU) ¡ ¡ In ¡Collabora7on ¡with ¡Jens ¡Axboe ¡(Facebook), ¡David ¡Nellans ¡(Nvidia), ¡Zvonimir ¡Bandic ¡(HGST), ¡Qingbo ¡ Wang ¡(HGST), ¡Aviad ¡Zuck ¡(Tel ¡Aviv ¡Univ.), ¡ Michael ¡Wei, ¡Steve ¡Swanson ¡(UCSD), ¡Dennis ¡Shasha ¡(NYU), ¡Björn ¡Thòr ¡Jònsson ¡(RU) ¡

h[p://clyde.itu.dk ¡ A ¡project ¡funded ¡by ¡the ¡Danish ¡Council ¡for ¡Independent ¡Research ¡

Methodology ¡(1): ¡Device ¡state ¡

• Measuring ¡Samsung ¡SSD ¡RW ¡performance ¡ ¡

§ Out-­‑of-­‑the-­‑box ¡… ¡and ¡a`er ¡filling ¡the ¡device!!! ¡(similar ¡behavior ¡on ¡Intel ¡ SSD) ¡

0.1 1 10 100 100 200 300 400 500 IO number Response time (ms) rt Avg(rt) 0.1 1 10 100 100 200 300 400 500 IO number Response time (ms) rt Avg(rt)

Random Writes – Samsung SSD Out of the box Random Writes – Samsung SSD After filling the device

0.1 1 10 100 100 200 300 400 500 IO number Response time (ms) rt Avg(rt) Avg(rt) o-o-b 0.1 1 10 100 100 200 300 400 500 IO number Response time (ms) rt Avg(rt) Avg(rt) o-o-b

Luc ¡Bouganim, ¡Björn ¡Thòr ¡ ¡Jònsson, ¡Philippe ¡Bonnet ¡

Minimal ¡FTL: ¡Take ¡the ¡FTL ¡out ¡of ¡the ¡equa7on! ¡

• Pros ¡

– Maximal ¡performance ¡for ¡

• SR, ¡RR, ¡SW ¡
• Semi-­‑Random ¡Writes ¡

– Maximal ¡control ¡for ¡the ¡DBMS ¡

• Cons ¡

– All ¡complexity ¡is ¡handled ¡ by ¡the ¡DBMS ¡ – All ¡IOs ¡must ¡follow ¡C1-­‑C3 ¡

• The ¡whole ¡DBMS ¡must ¡

be ¡rewri[en ¡

• The ¡flash ¡device ¡is ¡

dedicated ¡ ¡

Flash ¡chips ¡ Block ¡mapping, ¡Wear ¡Leveling ¡ (C4) ¡

DBMS ¡

Constrained ¡Pa[erns ¡only ¡ (C1, ¡C2, ¡C3) ¡ ¡ ¡

(C1) ¡Write ¡granularity ¡ (C2) ¡Erase ¡before ¡prog. ¡ (C3) ¡Sequen7al ¡prog. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡within ¡a ¡block ¡ ¡ ¡ ¡ ¡ (C4) ¡Limited ¡life7me ¡

Minimal ¡flash ¡device ¡

Luc ¡Bouganim, ¡Philippe ¡Bonnet ¡

• Ma7as ¡Bjørling, ¡Jens ¡Axboe, ¡David ¡Nellans, ¡Philippe ¡Bonnet ¡

Linux ¡Block ¡Layer: ¡ ¡ Introducing ¡Mul9queue ¡SSD ¡Access ¡on ¡Mul9-­‑core ¡Systems ¡

CLyDE ¡Project ¡

• Exploring ¡the ¡design ¡space ¡for ¡Host-­‑SSD ¡co-­‑

design: ¡

– EagleTree ¡[Niv ¡Dayan] ¡ ¡

• Simulated ¡SSD/OS/apps ¡for ¡broad ¡explora7on ¡of ¡design ¡

space ¡(discrete ¡event ¡simula7on) ¡

• Insights ¡about ¡GC, ¡DB ¡indexing ¡
• h[p://github.com/ClydeProjects/EagleTree ¡ ¡

– LightNVM ¡[Ma7as ¡Bjørling] ¡

• Host-­‑side ¡SSD ¡management ¡to ¡experiment ¡with ¡actual ¡OS/

apps ¡(wall ¡7me ¡clock) ¡

• Linux ¡support ¡for ¡Open-­‑channel ¡SSDs ¡
• h[p://github.com/ ¡Ma7asBjorling/LightNVM ¡

New ¡Insights ¡ ¡about ¡GC ¡policies ¡

Flash memory array

LUN LUN LUN

…

LUN LUN LUN

…

LUN LUN LUN

…

LUN LUN LUN

…

Applications (Workload generator) Operating System (IO scheduler)

Exploring extended interface impact on applications Exploring the OS scheduling strategies Exploring HW design space

• Nb of channels
• Nb of LUNs / channel
• Chip configuration
• RAM / Safe RAM quantity
• etc…

Exploring the SSD controller design space

• IO scheduling strategies
• GC / WL strategies
• Handling extended interface
• etc…

Exploring cross-layer optimizations SSD Controller

• Mapping
• IO Scheduling
• Garbage Collection (GC)
• Wear Leveling (WL)

Closed-­‑form ¡equa7on ¡for ¡ ¡ write-­‑amplifica7on ¡ EagleTree ¡ h[ps://github.com/ClydeProjects/EagleTree ¡ ¡

More ¡Insights ¡about ¡GC ¡Policies ¡

• K-­‑modal ¡workload: ¡

– Data ¡grouped ¡based ¡on ¡update ¡frequency ¡ – Previous ¡work: ¡

• Each ¡flash ¡block ¡is ¡dedicated ¡to ¡a ¡single ¡group ¡

– Ques7ons: ¡

• 1. How ¡to ¡par77on ¡over-­‑provisioned ¡blocks ¡across ¡groups? ¡
• 2. How ¡to ¡deal ¡with ¡changing ¡update ¡frequencies? ¡

Par77oning ¡ ¡ Over-­‑provisioned ¡Blocks ¡ ¡

Q: ¡number ¡of ¡dis7nct ¡update ¡frequencies ¡in ¡the ¡workload ¡ LBA/PBA ¡= ¡0.7 ¡ ¡ Nb ¡of ¡groups ¡= ¡2 ¡

Adap7ng ¡to ¡Changing ¡Workloads ¡

WOLF: ¡

– dynamically ¡measures ¡update ¡frequency ¡ – adapts ¡the ¡number ¡of ¡groups ¡

• Too ¡few/many ¡groups ¡harm ¡GC ¡efficiency ¡

– triggers ¡garbage-­‑collec7on ¡aggressively ¡to ¡re-­‑distribute ¡over-­‑provisioned ¡ space ¡across ¡groups ¡(from ¡cooling ¡to ¡hea7ng ¡groups) ¡

Linux ¡Abstrac7ons ¡for ¡ ¡Open-­‑Channel ¡SSDs ¡

• Extensible ¡

– Single ¡level ¡of ¡mapping ¡ between ¡Applica7ons ¡and ¡ physical ¡storage ¡

• Modular ¡

– SSD ¡Management ¡ components ¡should ¡be ¡ replaceable ¡

• Low ¡overhead ¡

– Host-­‑side ¡SSD ¡ management ¡should ¡not ¡ get ¡in ¡the ¡way ¡of ¡ performance, ¡s7ll ¡provide ¡ consistency, ¡durability ¡

Open-Channel SSD NAND Controller Host Interface Channel Queue Channel Queue CPU CPU GPCPUs NAND Flash NAND Flash NAND Flash NAND Flash NAND Flash NAND Flash ... DRAM Controller NAND Flash NAND Flash DRAM Host interface Controller Shared Bus

LightNVM ¡Design ¡(1/3) ¡

Block-based FS Flash-

• ptimized FS

Key-Value Store API Object Store API Null device Key-Value Store Logic Object Store Logic VFS API COSL (Block alloc., Chnl. strategy, Flash mgmt., ...) Open-Channel SSDs SATA/SAS NVMe PCI-e/Other Kernel User-space Page Logic Block Layer

LightNVM ¡Design ¡(2/3) ¡

Block Health Mgmt. COSL Null device Generic COSL Interface SATA/SAS NVMe PCI-e/Other

COSL

Wrapper Wrapper Wrapper Address Space Manager Channel Manager Block Interface Target Key-Value Target ...

• ptimized FS

LightNVM ¡Design ¡(3/3) ¡

DRAM Get Page (e.g. RR)

Generic Page Target

Page GC (e.g. Cost- based) Get Block (e.g. RR) Address Lookup Page P2L Page L2P Read Write DRAM Block Health Manager

Block Target

Address Space Manager Channel Manager Block GC (e.g. Cost- based) Get Block (e.g. RR) Block P2L Block L2P Read Write Erase Block Lookup

• ptimized FS

LightNVM ¡ ¡ Performance ¡

LightNVM: ¡Next ¡Steps ¡

• More ¡research ¡... ¡

– New ¡Targets ¡(B ¡Forest, ¡...) ¡ – New ¡Open-­‑channel ¡SSDs ¡(Cosmos, ¡...) ¡ – SSD ¡Management ¡variants ¡(WOLF) ¡

• Open-­‑source ¡contribu7ons ¡

– Linux ¡

• Linux ¡Plumber ¡Workshop ¡on ¡Open-­‑channel ¡SSDs ¡ ¡
• Lower ¡RAM ¡occupa7on, ¡be[er ¡performance ¡

– Lightstor ¡founda7on ¡

• Joint ¡work ¡with ¡GS ¡Madhususan ¡at ¡IIT ¡Chennai ¡
• Contribu7on ¡to ¡RapidIO ¡
• h[p://github.com/ ¡Ma7asBjorling/LightNVM ¡ ¡

B-­‑Forest ¡

• Tree ¡Logarithmic ¡method ¡

for ¡database ¡indexing ¡

– Writes ¡grouped ¡in ¡chunks, ¡ updated ¡at ¡the ¡same ¡7me ¡ – Mul7way ¡merges ¡to ¡leverage ¡ SSD ¡parallelism ¡ – Bloom ¡filters ¡to ¡speed ¡up ¡ lookups ¡

WOLF ¡

• Garbage ¡Collec7on ¡

– Flash ¡blocks ¡par77onned ¡in ¡ groups ¡based ¡on ¡update ¡ frequency ¡ – Fixed ¡overprovisioning ¡per ¡ group ¡(and ¡local ¡GC ¡per ¡ group) ¡dominates ¡global ¡over-­‑ provisioning ¡(and ¡global ¡GC) ¡ – WOLF ¡block ¡manager ¡adapts ¡ to ¡changing ¡update ¡ frequencies ¡

• Aggressive ¡GC ¡for ¡cooling ¡

groups ¡to ¡re-­‑distribute ¡over-­‑ provisioning ¡across ¡groups. ¡ . ¡ A ¡variant ¡of ¡the ¡block ¡target ¡in ¡LightNVM ¡ A ¡variant ¡of ¡the ¡LightNVM ¡Adress ¡Space ¡ Manager ¡ ¡and ¡page-­‑based ¡GC ¡

Energy-­‑Propor7onal ¡ ¡ Transac7on ¡Management ¡

• SSDs ¡are ¡entering ¡the ¡microsecond ¡era. ¡ ¡
• SSDs ¡and ¡persistent ¡memories ¡require ¡a ¡profound ¡redesign ¡of ¡

system ¡so`ware. ¡ ¡

• With ¡Persistent ¡Memories, ¡persistence ¡is ¡no ¡longer ¡7ed ¡to ¡

secondary ¡storage. ¡ ¡

– How ¡can ¡the ¡OS ¡handle ¡Persistent ¡Memories: ¡ (1) ¡By ¡extending ¡virtual ¡memory ¡ ¡ (2) ¡By ¡providing ¡a ¡block ¡device ¡interface ¡for ¡such ¡memories ¡ (3) ¡By ¡designing ¡new ¡file ¡systems ¡tailored ¡to ¡their ¡ characteris7cs ¡

¡

Energy-­‑Propor7onal ¡ ¡ Transac7on ¡Management ¡

• Back ¡to ¡the ¡good-­‑old ¡single-­‑level ¡store: ¡

– durability ¡– ¡how/when ¡is ¡data ¡manipulated ¡in ¡the ¡virtual ¡address ¡ space ¡made ¡durable? ¡ – ¡concurrency ¡– ¡how ¡to ¡design ¡data ¡structures ¡that ¡can ¡perform ¡ efficiently ¡when ¡accessed ¡concurrently ¡ ¡ – security ¡– ¡how ¡to ¡enforce ¡access ¡control ¡but ¡also ¡integrity ¡for ¡a ¡given ¡ por7on ¡of ¡memory ¡or ¡storage? ¡ ¡

• LightNVM ¡common ¡services ¡extended ¡to ¡Persistent ¡Memories ¡
• Transac7onal ¡VMM ¡as ¡LightNVM ¡target ¡
• Now ¡with ¡energy ¡propor7onality ¡as ¡a ¡design ¡goal. ¡

Energy-­‑Propor7onal ¡ ¡ Transac7on ¡Management ¡

• We ¡conjecture ¡that ¡durability ¡can ¡be ¡achieved ¡

efficiently ¡with ¡steal/force ¡ ¡

– making ¡redo ¡log ¡obsolete ¡and ¡ensuring ¡that ¡the ¡synchronous ¡ random ¡writes ¡required ¡by ¡a ¡force ¡policy ¡are ¡compe77ve ¡with ¡ the ¡synchronous ¡sequen7al ¡writes ¡followed ¡by ¡asynchronous ¡ random ¡writes ¡that ¡characterize ¡legacy ¡write ¡ahead ¡logging ¡

• protocols. ¡

– Virtualized ¡storage ¡that ¡will ¡be ¡integrated ¡in ¡the ¡single-­‑level ¡ store ¡is ¡naturally ¡organized ¡as ¡a ¡journal, ¡thus ¡providing ¡the ¡ capabili7es ¡of ¡an ¡undo ¡log. ¡