kernel-packages team mailing list archive

[Andy Whitcroft <apw@xxxxxxxxxxxxx>]

> The kernel configuration, CONFIG_SCSI_SCAN_ASYNC, is still set. Please
> do not enable this kernel configuration for s390x.
>
> Background why you shall disable this option:
> 
> The long-term default "sync" is probably well-tested. Experiences with async
> are rare. To be more frank here, sync is also used by other Linux distributions
> on z. For s390, the defconfig as well as our other upstream kernel
> configurations have or will have this being set to sync (again).

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

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

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
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.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1557692

Title:
  s390/kconfig: do not set CONFIG_SCSI_SCAN_ASYNC

Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Hendrik Brueckner - 2016-03-15 06:29:41 ==
  The kernel configuration, CONFIG_SCSI_SCAN_ASYNC, is still set.  Please do not enable this kernel configuration for s390x.

  Background why you shall disable this option:

  The long-term default "sync" is probably well-tested.  Experiences with async
  are rare.  To be more frank here, sync is also used by other Linux distributions
  on z.  For s390, the defconfig as well as our other upstream kernel
  configurations have or will have this being set to sync (again).

  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557692/+subscriptions