lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 10 Dec 2019 11:10:33 -0500
From:   Bart Van Assche <bvanassche@....org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
        Chris Healy <cphealy@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 1/1] hwmon: Driver for temperature sensors on SATA drives

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ