Re: [PATCH 4/4] scsi: core: don't limit per-LUN queue depth for SSD

Bart Van Assche
2019-11-22T20:46:52Z

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.