Re: [PATCH 1/1] hwmon: Driver for temperature sensors on SATA drives

[Bart Van Assche]

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.