On 11/10/2016 07:13 PM, Chris Leech wrote: > On Thu, Nov 10, 2016 at 05:22:44PM -0600, Mike Christie wrote: >> > On 11/07/2016 12:22 PM, Chris Leech wrote: >>> > > Currently the iSCSI transport class synchronises target scanning and >>> > > unbinding with a host level mutex. For multi-session hosts (offloading >>> > > iSCSI HBAs) connecting to storage arrays that may implement one >>> > > target-per-lun, this can result in the target scan work for hundreds of >>> > > sessions being serialized behind a single mutex. With slow enough >> > >> > Does this patch alone help or is there a scsi piece too? > > I had this tested when working a hung task timeout issue at boot, and > was told that it fixed the issue. The exact situation may be more > complex, I think it was only 128 sessions which is surprising that it > would hit a 2 minute timeout. But every backtrace was at this mutex. > I think you are also hitting a issue where the normal scan time is higher than usual and that might be a userspace bug. I am not sure how the mutex patch helps, but I have not thought about it. I think iscsid will scan the entire host during login. We only want iscsi_sysfs_scan_host to scan the specific target for the session we just logged into. In the kernel we are setting SCSI_SCAN_RESCAN for the scan and userspace did echo - - - > ..../scan for the entire host, so iscsi_user_scan is going to rescan every target that is setup. So once you get to 127 sessions/targets it could be a loonngg scan of all 127 of them, and target 128 is going to have to wait a loooonnggg time for that mutex and then also execute a long scan. If you have userspace do the single target scan, it should execute faster. I know that does not solve the serialization problem. You will still have lots of targets waiting to be scanned. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
