Arbitrary Dimension Reed-Solomon Coding and Decoding for Extended RAID on GPUs Matthew Curry, H. Lee Ward, Anthony Skjellum, and Ron Brightwell University of Alabama at Birmingham Sandia National Laboratories November 17th, 2008 Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 1 / 11
The Need for More Reliable RAID Lack of Failure Prediction ◮ SMART ◮ MTTF Larger Disks ◮ Stagnating Speeds ◮ Bit-Error Rates Correlated Failures ◮ Batch-Correlated Failures ◮ Environment-Related Failures Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 2 / 11
Current Method: Nested RAID Stripe data over several RAID arrays ◮ RAID 1 + 0 : Stripe over multiple RAID 1 sets ◮ RAID 5 + 0 : Stripe over multiple RAID 5 sets ◮ RAID 6 + 0 : Stripe over multiple RAID 6 sets Reliability is marginally improved over non-“+0” variants, while requiring significantly more hardware. Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 3 / 11
Enabling RAID N+3 and Beyond Need a fast method of creating arbitrary amounts of parity Reed-Solomon Coding is an obvious solution, but performance is lacking On an x86-based CPU, performance is limited to approximately 90 MB/s per core to do n + 3 parity Main limitation: A lack of the ability to do parallel table lookups, a crucial optimization for Reed-Solomon coding Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 4 / 11
GPU Architecture Figure: G80 Architecture Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 5 / 11
Framing the Experiment Disk 0 Disk 1 Disk 2 Disk 3 ... Disk n+m Operating System Kernel Network Packet Network iScsi Request Block Buffer Buffer Cache Driver copies write request data to Disk Writeout accumulation Buffer Retire write buffers request and complete asynchronously Network Packet GPU Accumulate Network Driver GPU Operate iScsi Reply Buffer (Finish Buffer Buffer Request) Buffers rotate as GPU finishes operating Contents of on Operate Buffer Operate Buffer Transferred to GPU Memory GPU (Parity Calculation Performed) Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 6 / 11
Generation Performance Parity Generation Performance 1600 1400 1200 1000 Throughput (MB/s) 800 NVIDIA 260: 13+3 NVIDIA 260: 29+3 Core 2 Duo: 13+3 Core 2 Duo: 29+3 600 400 200 0 0 500 1000 1500 2000 Size of Input (KB) Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 7 / 11
Recovery Performance Data Recovery Performance 800 700 600 500 Throughput (MB/s) 400 NVIDIA 260: 13+3 NVIDIA 260: 29+3 Core 2 Duo: 13+3 Core 2 Duo: 29+3 300 200 100 0 0 500 1000 1500 2000 Size of Input (KB) Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 8 / 11
Percentage of Time in PCI Transfer Percentage of Time Performing PCI Transfer 0.4 0.35 0.3 0.25 Percentage 13+3 29+3 0.2 0.15 0.1 0.05 0 500 1000 1500 2000 Size of Input (KB) Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 9 / 11
Conclusions A $300 GPU can support the workload of a sizable RAID array that can support any three disks failing. ◮ 16-disk array at 100 MB/s per disk (vs. 7 for CPU) ◮ 32-disk array at 51 MB/s per disk (vs. 4 for CPU) PCI-Express transfers can be fully hidden by the computation when done in parallel Future work includes building a working RAID system which includes this component (which will be available soon). Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 10 / 11
Thank you. Matthew Curry curryml@cis.uab.edu Matthew Curry, et. al (UAB/SNL) GPU RAID November 17th, 2008 11 / 11
Recommend
More recommend
