High Performance Storage Devices in the Linux Kernel
9 likes4,953 views
Agenda: In this talk we will present the Linux kernel storage layers and dive into blk-mq, a scalable, parallel block layer for high performance block devices, and how it is used to unleash the performance of NVMe, flash and beyond. Speaker: Evgeny Budilovsky, Kernel Developer at E8 Storage https://www.linkedin.com/company/e8-storage
Ad
More Related Content
What's hot (20)
Similar to High Performance Storage Devices in the Linux Kernel (20)
Ad
More from Kernel TLV (20)
Ad
Recently uploaded (20)
High Performance Storage Devices in the Linux Kernel
- 1. 1 . 1 E8 STORAGE Come join us at [email protected] https://goo.gl/FOuczd
- 2. 2 . 1 HIGH PERFORMANCE STORAGE DEVICES IN KERNEL E8 Storage By /Evgeny Budilovsky @budevg 12 Jan 2016
- 3. 3 . 1 STORAGE STACK 101
- 4. 3 . 2 APPLICATION Application invokes system calls (read, write, mmap) on files Block device files - direct access to block device Regular files - access through specific file system (ext4, btrfs, etc.)
- 5. 3 . 3 FILE SYSTEM system calls go through VFS layer specific file system logic applied read/write operations translated into read/write of memory pages Page cache involved to reduce disk access
- 6. 3 . 4 BIO LAYER (STRUCT BIO) File system constructs BIO unit which is the main unit of IO Dispatch bio to block layer / bypass driver (make_request_fn driver)
- 7. 3 . 5 BLOCK LAYER (STRUCT REQUEST) Setup struct request and move it to request queue (single queue per device) IO scheduler can delay/merge requests Dispatch requests To hardware drivers (request_fn driver) To scsi layer (scsi devices)
- 8. SCSI LAYER (STRUCT SCSI_CMND) translate request into scsi command dispatch command to low level scsi drivers
- 9. 3 . 6 WRITE (O_DIRECT) # Application perf record g dd if=/dev/zero of=1.bin bs=4k count=1000000 oflag=direct ... perf report callgraph stdio # Submit into block queue (bypass page cache) write system_call_fastpath sys_write vfs_write new_sync_write ext4_file_write_iter __generic_file_write_iter generic_file_direct_write ext4_direct_IO ext4_ind_direct_IO __blockdev_direct_IO do_blockdev_direct_IO submit_bio generic_make_request
- 11. 3 . 8 3 . 9 WRITE (WITH PAGE CACHE) # Application perf record g dd if=/dev/zero of=1.bin bs=4k count=1000000 ... perf report callgraph stdio # write data into page cache write system_call_fastpath sys_write vfs_write new_sync_write ext4_file_write_iter __generic_file_write_iter generic_perform_write ext4_da_write_begin grab_cache_page_write_begin pagecache_get_page __page_cache_alloc alloc_pages_current
- 13. 3 . 10 4 . 1 HIGH PERFORMANCE BLOCK DEVICES
- 14. 4 . 2 CHANGES IN STORAGE WORLD Rotational devices (HDD) "hundreds" of IOPS , "tens" of milliseconds latency Today, flash based devices (SSD) "hundreds of thousands" of IOPS, "tens" of microseconds latency Large internal data parallelism Increase in cores and NUMA architecture New standardized storage interfaces (NVME)
- 15. 4 . 3 NVM EXPRESS
- 16. 4 . 4 HIGH PERFORMANCE STANDARD Standardized interface for PCIe SSDs Designed from the ground up to exploit Low latency of today’s PCIe- based SSD’s Parallelism of today’s CPU’s
- 17. BEATS AHCI STANDARD FOR SATA HOSTS AHCI NVME Maximum Queue Depth 1 command queue 32 commands per Q 64K queues 64K Commands per Q Un-cacheable register accesses (2K cycles 6 per non-queued command 9 per queued command 2 per command MSI-X and Interrupt Steering Single interrupt; no steering 2K MSI-X interrupts Parallelism & Multiple Threads Requires synchronization lock to issue command No locking Efficiency for 4KB Commands Command parameters require two serialized host DRAM fetches Command parameters in one 64B fetch
- 18. 4 . 54 . 6 IOPS consumer grade NVME SSDs (enterprise grade have much better performance) 100% writes less impressive due to NAND limitation
- 19. 4 . 7 BANDWIDTH
- 20. 4 . 8 LATENCY
- 21. 5 . 1 THE OLD STACK DOES NOT SCALE
- 22. 5 . 2 THE NULL_BLK EXPERIMENT Jens Axboe (Facebook) null_blk configuration queue_mode=1(rq) completion_nsec=0 irqmode=0(none) fio Each thread does pread(2), 4k, randomly, O_DIRECT Each added thread alternates between the two available NUMA nodes (2 socket system, 32 threads)
- 23. 5 . 3 LIMITED PERFORMANCE
- 25. 5 . 5 PERF 40% from sending request (blk_queue_bio) 20% from completing request (blk_end_bidi_request) 18% sending bio from the application to the bio layer (blk_flush_plug_list)
- 26. 5 . 6 OLD STACK HAS SEVERE SCALING ISSUES
- 27. 5 . 7 PROBLEMS Good scalability before block layer (file system, page cache, bio) Single shared queue is a problem We can use bypass mode driver which will work with bio's without getting into shared queue. Problem with bypass driver: code duplication
- 28. 6 . 1 BLOCK MULTI-QUEUE TO THE RESCUE
- 29. 6 . 2 HISTORY Prototyped in 2011 Paper in SYSTOR 2013 Merged into linux 3.13 (2014) A replacement for old block layer with different driver API Drivers gradually converted to blk-mq (scsi-mq, nvme- core, virtio_blk)
- 30. 6 . 3 ARCHITECTURE - 2 LAYERS OF QUEUES Application works with per- CPU software queue Multiple software queues map into hardware queues Number of HW queues is based on number of HW contexts supported by device Requests from HW queue submitted by low level driver to the device
- 31. ARCHITECTURE - ALLOCATION AND TAGGING IO tag Is an integer value that uniquely identifies IO submitted to hardware On completion we can use the tag to find out which IO was completed Legacy drivers maintained their own implementation of tagging With block-mq, requests allocated at initialization time (based on queue depth) Tag and request allocations combined Avoids per request allocations in driver and tag maintenance
- 32. 6 . 46 . 5 ARCHITECTURE - I/O COMPLETIONS Generally we want completions to be as local as possible Use IPIs to complete requests on submitting node Old block layer was using software interrupts instead of IPIs Best case there is an SQ/CQ pair for each core, with MSI-X interrupt setup for each CQ, steered to the relevant core IPIs used when there aren't enough interrupts/HW queues
- 33. 6 . 6 NULL_BLK EXPERIMENT AGAIN null_blk configuration queue_mode=2(multiqueue) completion_nsec=0 irqmode=0(none) submit_queues=32 fio Each thread does pread(2), 4k, randomly, O_DIRECT Each added thread alternates between the two available NUMA nodes (2 socket system, 32 threads)
- 34. 6 . 7 SUCCESS
- 35. 6 . 8 WHAT ABOUT HARDWARE WITHOUT MULTI QUEUE SUPPORT Same null_blk setup 1/2/n hw queues in blk-mq mq-1 and mq-2 so close since we have 2 sockets system Numa issues eliminated once we have queue per numa node
- 36. CONVERSION PROGRESS mtip32xx (micron SSD) NVMe virtio_blk, xen block driver rbd (ceph block) loop ubi SCSI (scsi-mq)
- 37. 6 . 97 . 1 SUMMARY Storage device performance has accelerated from hundreds of IOPS to hundreds thousands of IOPS Bottlenecks in software gradually eliminated by exploiting concurrency and introducing lock-less architecture blk-mq is one example Questions ?
- 38. 8 . 1 REFERENCES 1. 2. 3. 4. 5. 6. 7. Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems The Performance Impact of NVMe and NVMe over Fabrics Null block device driver blk-mq: new multi-queue block IO queueing mechanism fio perf Solving the Linux storage scalability bottlenecks - by Jens Axboe