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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux