New i10 I/O Scheduler Proposed For Linux To Optimize Batching
A new Linux I/O scheduler has been proposed that is optimized for batching such as for MMC and TCP-based/remote storage.
The "i10" scheduler is the proposal for this new Linux I/O solution to amortize the remote access latency while increasing I/O throughput.
The i10 I/O scheduler proposal sent out by Rachit Agarwal explains that it "performs batching per hctx in terms of #requests, #bytes, and timeouts (at microseconds granularity). i10 starts dispatching only when #requests or #bytes is larger than a default threshold or when a timer expires. After that, batching dispatch would happen, allowing batching at device drivers along with "bd->last" and ".commit_rqs"...We have tested the i10 I/O scheduler with nvme-tcp optimizaitons and batching dispatch, varying number of cores, varying read/write ratios, and varying request sizes, and with NVMe SSD and RAM block device. For NVMe SSDs, the i10 I/O scheduler achieves ~60% improvements in terms of IOPS per core over "noop" I/O scheduler...While other schedulers may also batch I/O (e.g., mq-deadline), the optimization target in the i10 I/O scheduler is throughput maximization. Hence there is no latency target nor a need for a global tracking context, so a new scheduler is needed rather than to build this functionality to an existing scheduler."
The i10 scheduler was born out of research from Cornell University.
More details on the proposed i10 Linux I/O scheduler via the kernel mailing list.
The "i10" scheduler is the proposal for this new Linux I/O solution to amortize the remote access latency while increasing I/O throughput.
The i10 I/O scheduler proposal sent out by Rachit Agarwal explains that it "performs batching per hctx in terms of #requests, #bytes, and timeouts (at microseconds granularity). i10 starts dispatching only when #requests or #bytes is larger than a default threshold or when a timer expires. After that, batching dispatch would happen, allowing batching at device drivers along with "bd->last" and ".commit_rqs"...We have tested the i10 I/O scheduler with nvme-tcp optimizaitons and batching dispatch, varying number of cores, varying read/write ratios, and varying request sizes, and with NVMe SSD and RAM block device. For NVMe SSDs, the i10 I/O scheduler achieves ~60% improvements in terms of IOPS per core over "noop" I/O scheduler...While other schedulers may also batch I/O (e.g., mq-deadline), the optimization target in the i10 I/O scheduler is throughput maximization. Hence there is no latency target nor a need for a global tracking context, so a new scheduler is needed rather than to build this functionality to an existing scheduler."
The i10 scheduler was born out of research from Cornell University.
More details on the proposed i10 Linux I/O scheduler via the kernel mailing list.
3 Comments