On 11/22/19 10:26 AM, James Smart wrote:
On 11/22/2019 10:14 AM, Bart Van Assche wrote:
Thanks for having shared these numbers. I think this is very useful
information. Do these results show the performance drop that happens
if /sys/block/.../device/queue_depth exceeds .can_queue? What I am
wondering about is how important these results are in the context of
this discussion. Are there any modern SCSI devices for which a SCSI
LLD sets scsi_host->can_queue and scsi_host->cmd_per_lun such that the
device responds with BUSY? What surprised me is that only three SCSI
LLDs call scsi_track_queue_full() (mptsas, bfa, esp_scsi). Does that
mean that BUSY responses from a SCSI device or HBA are rare?
That's because most of the drivers, which had queue full ramp up/ramp
down in them and would have called scsi_track_queue_full() converted
over to the moved-queue-full-handling-in-the-mid-layer, indicated by
sht->track_queue_depth = 1.
Yes - it is still hit a lot!
Hi James,
In the systems that I have been working on myself I made sure that the
BUSY condition is rarely or never encountered. Anyway, since there are
setups in which this condition is hit frequently we need to make sure
that these setups keep performing well. I'm wondering now whether we
should try to come up with an algorithm for maintaining
sdev->device_busy only if it improves performance and for not
maintaining sdev->device_busy for devices/HBAs that don't need it.
Bart.
