On Tue, 2018-10-16 at 01:19 -0400, Martin K. Petersen wrote: +AD4 Bart, +AD4 +AD4 +AD4 During the 2018 edition of LSF/MM there was a session about increasing +AD4 +AD4 SCSI disk probing concurrency. This patch series implements what has +AD4 +AD4 been proposed during that session, namely: - Make sure that the driver +AD4 +AD4 core is aware of asynchronous SCSI LUN probing. - Avoid unnecessary +AD4 +AD4 serialization between sd+AF8-probe() and sd+AF8-remove() because this could +AD4 +AD4 lead to a deadlock. +AD4 +AD4 I like it. +AD4 +AD4 What kind of testing have you done with +ACQ-BIGNUM devices? Got any numbers +AD4 to share? Hi Martin, For the following test: modprobe -r scsi+AF8-debug+ADs time modprobe scsi+AF8-debug delay+AD0-0 max+AF8-luns+AD0-256 I obtained the following time measurements: +ACo Kernel 4.15.0: 2.2s. +ACo Kernel 4.19-rc6 with this patch series applied: 2.3s. This is not what I had expected. I think this small increase is because the current sd code scans multiple LUNs associated with the same SCSI host concurrently while apparently the device core scans such LUNs sequentially. >From the driver core: void +AF8AXw-device+AF8-attach+AF8-async+AF8-helper(void +ACoAXw-dev, async+AF8-cookie+AF8-t cookie) +AHs +AFs ... +AF0 bus+AF8-for+AF8-each+AF8-drv(dev-+AD4-bus, NULL, +ACY-data, +AF8AXw-device+AF8-attach+AF8-driver)+ADs +AFs ... +AF0 +AH0 static int +AF8AXw-device+AF8-attach(struct device +ACo-dev, bool allow+AF8-async) +AHs +AFs ... +AF0 async+AF8-schedule(+AF8AXw-device+AF8-attach+AF8-async+AF8-helper, dev)+ADs +AFs ... +AF0 +AH0 Do you want me to look into modifying +AF8AXw-device+AF8-attach+AF8-async+AF8-helper() such that it calls +AF8AXw-device+AF8-attach+AF8-driver() concurrently instead of sequentially in case of multiple LUNs? Thanks, Bart.
