On 12/9/19 2:20 PM, Guenter Roeck wrote: > On Mon, Dec 09, 2019 at 09:08:13AM -0800, Bart Van Assche wrote: >> How much does synchronously submitting SCSI commands from inside the >> device probing call back slow down SCSI device discovery? What is the >> impact of this code on systems with a large number of ATA devices? > > Interesting question. In general, any SCSI commands would only be executed > for SATA drives since the very first check in satatemp_identify() uses > sdev->inquiriy and aborts if the drive in question is not an ATA drive. > When connected to SATA drives, I measured the execution time of > satatemp_identify() to be between ~900 uS and 1,700 uS on a system with > Ryzen 3900 CPU. > > In more detail: > - Time to read VPD page: ~10-20 uS > - Time to execute SMART_READ_LOG/SCT_STATUS_REQ_ADDR: ~140-150 uS > - Time to execute SMART_WRITE_LOG/SCT_STATUS_REQ_ADDR: ~600-1,500 uS > - Time to execute SMART_READ_LOG/SCT_READ_LOG_ADDR: ~100-130 uS > > Does that answer your question ? > > Please note that I think that this is irrelevant in this context. > The driver is only instantiated if loaded explicitly, so whoever uses it > will be in a position to decide if the benefit of using it will outweigh > its cost. > > If instantiation time ever becomes a real problem, for example if someone > with a large number of SATA drives in a system wants to use the driver > and is concerned about instantiation time, we can make the second part > of its registration (ie everything after identifying SATA drives) > asynchronous. That would, however, add a substantial amount of complexity > to the driver, and we should only do it if it is really warranted. Hi Guenter, Thank you for having answered my question in great detail. I think this overhead is low enough to be acceptable. Bart.
