System and Algorithmic Adaptation for Flash

Size: px

Start display at page:

Download "System and Algorithmic Adaptation for Flash"

Eustacia Melina Stone
5 years ago
Views:

1 System and Algorithmic Adaptation for Flash The FAWN Perspective David G. Andersen, Vijay Vasudevan, Michael Kaminsky* Amar Phanishayee, Jason Franklin, Iulian Moraru, Lawrence Tan Carnegie Mellon University and *Intel Labs

2 Context: Datacenter Energy Hydroelectric Dam 2

3 Approaches to saving power Infrastructure Efficiency Dynamic Power Scaling Computational Efficiency Power generation Power distribution Cooling Sleeping when idle Rate adaptation VM consolidation FAWN Goal of computational efficiency: Reduce the amount of energy to do useful work 3

()* %&' +,-#. 1.6Ghz single/dual Intel Pineview ()* %&' +,-#.

4 FAWN Fast Array of Wimpy Nodes Improve computational efficiency of data-intensive computing using an array of well-balanced low-power systems. 34-5"6"78-, 9&4:&4 ()* ()* ()* ()*!"#$ %&' +;1< ()* %&' +,-#. ()* %&' +,-#. 1.6Ghz single/dual Intel Pineview ()* %&' +,-#. ()* %&' +,-#. ()* %&' +,-#. ()* %&' +,-#. ()* %&' +,-#. ()* %&' +,-#. atom 2GB DRAM AMD Geode 256MB DRAM 4GB CompactFlash Intel X25-m/e SSD /

5 Towards balanced systems 1E+08 1E+07 Disk Seek Rebalancing Options Nanoseconds 1E+06 1E+05 1E+04 1E+03 1E+02 1E+01 Wasted resources DRAM Access 1E+00 CPU Cycle 1E Year Today s CPUs Array of Fastest Disks Slower CPUs Fast Storage Slow CPUs Today s Disks 5

6 Targeting the sweet-spot in efficiency 2500 Speed vs. Efficiency Fastest processors exhibit superlinear power usage Instructions/sec/W in millions Custom ARM Mote XScale 800Mhz Atom Z500 Xeon7350 Fixed power costs can dominate efficiency for slow processors FAWN targets sweet spot in system efficiency when including fixed costs Instructions/sec in millions (Includes 0.1W power overhead) 6

7 Targeting the sweet-spot in efficiency Instructions/sec/W in millions FAWN Today s CPU Array of Fastest Disks Slower CPU Fast Storage Slow CPU Today s Disk 7 Instructions/sec in millions XScale 800Mhz Custom ARM Mote Atom Z500 Xeon7350 More efficient

8 Case 1: A high-performance, persistent key-value store ~20 byte keys byte values Very small writes Irregular size objects Very random access The FTL is not our friend. 8

9 Using Berkeley DB on CF Platform: 500Mhz AMD Geode, 256MB DRAM, 4GB Compact Flash Card Insert 7M 200-byte entries into DB BDB FAWN-KV 0.07 MB/s 20 MB/s

10 Using Flash for K-V Write sequentially within an erase block Can do this concurrently to several, iff the FTL lets you (Duplication w/filesystem...) Use system memory efficiently Otherwise, why use Flash at all? :)

11 From key to value KeyFrag!= Key Potential collisions! Low probability of multiple Flash reads 160-bit key DRAM Hashtable Hash Index Flash Data region Log Entry Key Len Data KeyFrag Valid. { 12 bytes per entry Offset (a) 11

12 Just one log is painful With flash, not restricted to one -- maybe Write Speed in MB/s Sandisk Extreme IV Memoright GT Mtron Mobi Number of FAWNDS Files (Log-scale) 12 Intel X25-M Intel X25-E

13 FAWN-DS Lookups System QPS Watts Our FAWN-based system over 6x more efficient than 2008-era traditional systems 13 QPS Watt Alix3c2/Sandisk(CF) Desktop/Mobi (SSD) MacbookPro / HD Desktop / HD

14 Ongoing work DRAM limits amount of Flash that can be used. FAWN-KV: 12 bytes per entry Our ongoing work gets this down to ~1 byte DRAM per key-value entry (but must re-write data once), or 3 bits if can read flash on table miss BufferHash (NSDI 2010) provides similar benefits, though wastes 50% of flash space 14

15 And then we moved to Atom + SSD 1.6Ghz single-core Pineview, 2GB DRAM, x25-m SSD 2.8Ghz 4-core i7, 2GB DRAM, 6x (x25-m SSD) dual 2.8Ghz 4-core Xeon, 8GB DRAM, FusionIO 15

16 512 b random reads Platform 2x 4-core xeon + FusionIO i7 + single X25-m i7 + 4x X25-m Atom-1core + X25-m Reads / Second ~150 K ~60 K ~115 K ~23 K 16

17 SATA... Need I say more? Couldn t get more than ~120k IOPS over the onboard SATA bus, no matter what we tried 17

18 Slow wimpies Prior results: Wimpies dominated in efficiency What s happening here? 23k vs 60k add_disk_randomness(rq->rq_disk); 23,000 interrupts/second tester program called gettimeofday Fixed these, new interrupt coalescing: 37k and rising 18

19 Sorting Similar results using NSort But flash-aware can clobber NSort (talk Sort Efficiency Comparison offline) 3.5 Sort Efficiency (MBpJ) MB sorted / Joule Atom x25-e Atom+X25E i7-desktop+4-x25e 19 Sort Efficiency i7 4x x25e i7-svr+fusionio 2x xeon FusionIO

20 Data structures One idea you ve seen: mutable bits through re-programming; Rivest punch-cards 82, Grupp, Yaakobi, Mitz, more Can do even better for particular data types... Flash should be an ideal add-only Bloom filter (Set membership with one-sided error: Will tell you if X is in set, may lie and say it is) Caching works poorly for Blooms (random access) Very important for data-mining, etc. But all need bit-level access to Flash... 20

21 Where we re going (?) (PCM??) + Bandwidth + Latency + Power ---- Capacity Requires even more mem-efficient systems 21

22 The FAWN Perspective Pretending Flash is disk or DRAM misses opportunities Making Flash look like disk or DRAM hides opportunities Today s kernels handle high block IOPS poorly (... and we need to fix this) Algorithms exploiting re-programmability, semirandom writes can win big But want to leave the system usable and abstractions manageable 22

FAWN. A Fast Array of Wimpy Nodes. David Andersen, Jason Franklin, Michael Kaminsky*, Amar Phanishayee, Lawrence Tan, Vijay Vasudevan

FAWN. A Fast Array of Wimpy Nodes. David Andersen, Jason Franklin, Michael Kaminsky*, Amar Phanishayee, Lawrence Tan, Vijay Vasudevan FAWN A Fast Array of Wimpy Nodes David Andersen, Jason Franklin, Michael Kaminsky*, Amar Phanishayee, Lawrence Tan, Vijay Vasudevan Carnegie Mellon University *Intel Labs Pittsburgh Energy in computing