------- Comment From [email protected] 2016-03-18 04:35 EDT------- (In reply to comment #6) > The upstream defconfig value for this setting is pretty much exclusively > =y on all architectures and specifically for s390 is =y: > > arch/s390/defconfig:CONFIG_SCSI_SCAN_ASYNC=y
That's no longer the case for v4.5 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb14def6a9cae973ba6f702443c8fc589998279c Historically, it was turned on for defconfig by accident, the configuration options in the arch/s390/configs/ directory has never turned it on. > Examining the RHEL based host system that runs our KVM instances on our > local z-series system, those have the option set to =y as well: > > [root@s2lp7 ~]# grep CONFIG_SCSI_SCAN_ASYNC -r > /boot/config-3.10.0-123.20.1.el7_0.kvmibm.1* > /boot/config-3.10.0-123.20.1.el7_0.kvmibm.12.s390x:CONFIG_SCSI_SCAN_ASYNC=y > /boot/config-3.10.0-123.20.1.el7_0.kvmibm.12.s390x.kdump: > CONFIG_SCSI_SCAN_ASYNC=y > /boot/config-3.10.0-123.20.1.el7_0.kvmibm.15.s390x:CONFIG_SCSI_SCAN_ASYNC=y > /boot/config-3.10.0-123.20.1.el7_0.kvmibm.15.s390x.kdump: > CONFIG_SCSI_SCAN_ASYNC=y I will let the KVM team know and let them decide to keep this configuration option or not. > > Simiarly for the current debian s390x kernels: > > $ grep SCSI_SCAN_ASYNC X/boot/config-4.4.0-1-s390x > CONFIG_SCSI_SCAN_ASYNC=y > $ > > > Apart from testing, the reason why I suggest to change this setting goes > > back > > to a talk with the zfcp device driver maintainer. I stumbled over this > > setting as trying out FCP devices on a Debian s390 system. Tools are > > expecting that attached LUNs to an FCP device should be synchronously, that > > means, the requests should be synchronously processed by the FCP device and > > the SCSI layer on top. Asynchronous processing might cause problems in tools > > that expect synchronous behavior. Further, asynchronous handling makes it > > more harder to wait for the SCSI device becomes available (if it exists at > > all). Thus, tools have to actively wait for something to happen... and the > > worst thing is, that there is no tooling at all that waits for asynchronous > > processing to become completed (udevadm settle is useless here as there are > > no uevent for LUN attachment requests). > > This is a mischaracterisation of the effect of this configuration option. > The option does not make device discovery asynchronous with respect > to userspace. > > The primary consequence of enabling this option is that the system > does not wait for the devices to be found before moving on to other > cpu intensive initialisation. This improves boot time by allowing us Yes... I know that argument. At the end, you will be in the wait_for_device_probe() and sleep until the desired devices will appear or the initramfs fails due to a timeout. The scsi_debug kernel module no longer exist to wait until async processing is completed. > to go ahead and decompress the initrd in parallel with device discovery > utilising the otherwise idle CPU. Further, it does not change the order > in which discovered devices are numbered or indeed reported to userspace > via udev; at the end of discovery the events announcing devices are > emitted in the same order they would have been in a synchronous scan. > But most important all asynchronous discovery must complete before > we start the first userspace process (see wait_for_device_probe() in > prepare_namespace()) rendering it synchronous with respect to init. > > Given this has been the default model for all architectures for some > years, the asynchronous path is by far the path most travelled and most > tested. I am resistant to making s390x the only architecture that uses > the synchronous model. Especially as it is likely to increase image > boot times. The preferred setting from our team is to turn it off. Of course, the final decision is up to you. I am also going to reject this BZ at our side for now. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1557692 Title: s390/kconfig: do not set CONFIG_SCSI_SCAN_ASYNC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557692/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
