On 10/25/23 16:37, Ming Lei wrote:
You are talking about multi-lun case, and your change does affect
multi-lun code path, but your test result doesn't cover multi-lun, is
it enough?
I think that the results I shared are sufficient because these show the
worst possible performance impact of fair tag sharing. If there are two
active logical units and much more I/O is sent to one logical unit than
to the other, then the aggregate performance will be very close to what
I shared in a previous email.
At least your patch shouldn't cause performance regression on
multi-lun IO workloads, right?
If blk_mq_get_tag() can't allocate a tag, and if multiple threads are
waiting for a tag, the thread that called blk_mq_get_tag() first is
granted the first tag that is released. I think this guarantees fairness
if all requests have a similar latency. There will be some unfairness if
there are significant differences in latency per logical unit, e.g.
because all requests sent to one logical unit are small and because all
requests sent to another logical unit are large. Whether or not this
matters depends on the use case.
Thanks,
Bart.
