| ▲ | marginalia_nu 2 hours ago | |||||||
If you submit 16 contiguous read requests the system will just merge them into one large read request. Modern SSDs tolerate moderate queue depths very well, but piling on the I/O queue also incurs tail latency jitter unless you're able to ensure the queue depth stays in the moderate range and never goes higher. All else being equal, fewer larger requests is better for I/O latency (though read amplification for the sake of reading more data obviously doesn't help anyone). Though in this scenario, we're mostly comparing the syscall overhead of a single preadv against io_uring bookkeeping for multiple preads, regardless of how you submit the reads they end up being the same operation. | ||||||||
| ▲ | vlovich123 an hour ago | parent [-] | |||||||
Doesn’t the Linux kernel automatically merge requests for contiguous regions into a single request? I’m not sure 16 read I/Os submitted to io_uring for a contiguous 64kib region will behave differently at the disk level than a single 64kib request. There’s a little bit extra work the kernel has to do to merge the requests but that should be negligible. In a poorly written micro benchmark test it’s possible the kernel will fail to coalesce all of them because your submissions aren’t visible all at once (ie it starts submitting requests and doesn’t have an opportunity to merge). Whether that actually is possible to happen requires digging a bit more into the Linux kernel source. | ||||||||
| ||||||||