On Fri, 2020-06-26 at 16:53 -0700, Anjali Kulkarni wrote:
> There is a loop in scsi_scan_channel(), which calls
> __scsi_scan_target() 255 times, even when it has found a
> target/device on a
> lun in the first iteration; this ends up adding a 2 secs delay to the
> boot
> time. The for loop in scsi_scan_channel() adding 2 secs to boot time
> is as
> follows:
>
> for (id = 0; id < shost->max_id; ++id) {
> ...
> __scsi_scan_target(&shost->shost_gendev, channel,
> order_id, lun, rescan);
> }
>
> __scsi_scan_target() calls scsi_probe_and_add_lun() which calls
> scsi_probe_lun(), hence scsi_probe_lun() ends up getting called 255
> times.
> Each call of scsi_probe_lun() takes 0.007865 secs.
> 0.007865 multiplied by 255 = 2.00557 secs.
> By adding a break in above for loop when a valid device on lun is
> found,
> we can avoid this 2 secs delay improving boot time by 2 secs.
>
> The flow of code is depicted in the following sequence of events:
>
> do_scan_async() ->
> do_scsi_scan_host()->
> scsi_scan_host_selected() ->
> scsi_scan_channel()
> __scsi_scan_target() -> this is called shost->max_id
> times
> (255 times)
> scsi_probe_and_add_lun-> this is called 255
> times
> scsi_probe_lun : called 255 times, each call
> takes 0.007865 secs.
What HBA is this? This code is for legacy scanning of busses which
require it, which is pretty much only SPI. The max_id of even the
latest SPI bus should only be 16, so where is 255 coming from?
James
