Dear all:
Thanks, again, for the very constructive decisions.
I am writing back with quite a few updates:
1. We have now included a detailed comparison of i10 scheduler with
Kyber with NVMe-over-TCP
(https://github.com/i10-kernel/upstream-linux/blob/master/i10-evaluation.pdf).
In a nutshell, when operating with NVMe-over-TCP, i10 demonstrates the
core tradeoff: higher latency, but also higher throughput. This seems to
be the core tradeoff exposed by i10.
2. We have now implemented an adaptive version of i10 I/O scheduler,
that uses the number of outstanding requests at the time of batch
dispatch (and whether the dispatch was triggered by timeout or not) to
adaptively set the batching size. The new results
(https://github.com/i10-kernel/upstream-linux/blob/master/i10-evaluation.pdf)
show that i10-adaptive further improves performance for low loads, while
keeping the performance for high loads. IMO, there is much to do on
designing improved adaptation algorithms.
3. We have now updated the i10-evaluation document to include results
for local storage access. The core take-away here is that i10-adaptive
can achieve similar throughput and latency at low loads and at high
loads when compared to noop, but still requires more work for lower
loads. However, given that the tradeoff exposed by i10 scheduler is
particularly useful for remote storage devices (and as Jens suggested,
perhaps for virtualized local storage access), I do agree with Sagi -- I
think we should consider including it in the core, since this may be
useful for a broad range of new use cases.
We have also created a second version of the patch that includes these
updates:
https://github.com/i10-kernel/upstream-linux/blob/master/0002-iosched-Add-i10-I-O-Scheduler.patch
As always, thank you for the constructive discussion and I look forward
to working with you on this.
Thanks Rachit,
Would be good if you can send a formal patch for the adaptive queuing so
people can have a look.
One thing that was left on the table is weather this should be a full
blown scheduler or a core block infrastructure that would either be
set on-demand or by default.
I think that Jens and Ming expressed that this should be something that
we should place this in the block core, but I'd like to hear maybe
Ming can elaborate on his ideas how to do this.
