On 11/03/2021 00:58, Ming Lei wrote:
Indeed, blk_mq_queue_tag_busy_iter() already does take a reference to its
queue usage counter when called, and the queue cannot be frozen to switch
IO scheduler until all refs are dropped. This ensures no stale references
to IO scheduler requests will be seen by blk_mq_queue_tag_busy_iter().
However, there is nothing to stop blk_mq_queue_tag_busy_iter() being
run for another queue associated with the same tagset, and it seeing
a stale IO scheduler request from the other queue after they are freed.
To stop this happening, freeze and quiesce all queues associated with the
tagset as the elevator is exited.
I think this way can't be accepted since switching one queue's scheduler
is nothing to do with other request queues attached to same HBA.
This patch will cause performance regression because userspace may
switch scheduler according to medium or workloads, at that time other
LUNs will be affected by this patch.
Hmmm..that was my concern also. Do you think that it may cause a big
impact? Depends totally on the workload, I suppose.
FWIW, it is useful though for solving both iterator problems.
Thanks,
John
