On Fri, Nov 22, 2019 at 12:46:48PM -0800, Bart Van Assche wrote: > 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. The simplest policy could be to only maintain sdev->device_busy for HDD. Thanks, Ming
