Hi Martin,

On Tue, Jan 28, 2020 at 12:24 PM Martin K. Petersen
[off-list ref] wrote:

Sumanesh,

quoted

Instead of relying on QUEUE_FULL and some complex heuristics of when
to start tracking device_busy, why can't we simply use "
track_queue_depth" ( along with the other flag that Ming added) to
decide which devices need queue depth tracking, and track device_busy
only for them?

Because I am interested in addressing the device_busy contention problem
for all of our non-legacy drivers. I.e. not just for controllers that
happen to queue internally.

Can we just do it for controllers without 'track_queue_depth' and SSD now?

quoted

I am not sure how we can suddenly start tracking device_busy on the fly,
if we do not know how many IO are already pending for that device?

We know that from the tags. It's just not hot path material.

In case of 'track_queue_depth', cost for tracking queue depth has to be paid,
which can be too big to get expected perf on high end HBA.

sbitmap might be used for this purpose, but not sure if it can scale well enough
for this purpose.


Thanks,
Ming Lei