[PATCH v8 00/10] nvme-multipath: introduce latency I/O policy
Randy Jennings
randyj at purestorage.com
Mon Sep 14 11:56:08 PDT 2026
> Randy, would it be possible for you folks to evaluate it as well? I will ask
> some folks on our side as well. I'm concerned that Nilay is the only one who
> has evaluated it in his lab.
Yes, absolutely, but there is going to be a time delay due to wrapping up
some current priorities. I'd say we'd get to it in more than 2 months but
less than 6. That is the best promise I can give right now. (Yes, it is
behind some work for stretched subsystems and CCR/CQT, which are
higher priorities for me.)
> Overall, I am perfectly fine with the approach this path selector is
> taking, but I worry
> that we are growing path-selectors that are slightly different in subtle
> ways...
Agreed.
> TBH, I still don't understand what use-cases this path selector is more
> appropriate than queue-depth, or vice-versa.
I had this question, too, and we talked about it in Zagreb. My
understanding from that discussion is that latency can handle
full queues better than queue-depth. When you have shallow
queues, you still get information to make a path decision on.
Sincerely,
Randy Jennings
More information about the Linux-nvme
mailing list