kernel-packages team mailing list archive

[bugproxy <bugproxy@xxxxxxxxxx>]

------- Comment From brueckner@xxxxxxxxxx 2016-03-08 03:18 EDT-------
(In reply to comment #4)
> The requests below two keys are currently out of scope, with the generic
> kernel config policy for Ubuntu:
> CONFIG_PREEMPT_NONE
> CONFIG_SCSI_SCAN_ASYNC
>

This has been already discussed on the skipper mailing list. So for
CONFIG_SCSI_SCAN_ASYNC, I copy this again to this BZ:

> > # CONFIG_SCSI_SCAN_ASYNC is not set
>
> We have been using _ASYNC ordering since at least 14.04 iirc.  So far we
> have had no issues with that set in our s390x boots, but I would have to
> double check if we are using FCP devices to make that meaningful.

Please double check if you were already using FCP devices.  Of course, this
setting does not affect DASDs.

>
> Is this a real concern for known issues with asynchronous ordering or
> just that this has not been the official order in your testing up to
> now?  Async ordering should not affect ordering of device naming etc.

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

-- 
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/1543165

Title:
  kernel: update kernel configuration

Status in linux package in Ubuntu:
  Triaged

Bug description:
  == Comment: #0 - Hendrik Brueckner <brueckner@xxxxxxxxxx> - 2016-02-08 09:41:49 ==
  The below mentioned kernel configuration options are still not yet integrated into the Ubuntu kernel. In addition to the discussions on the skipper mailing list, hereby the bugzilla / launchpad to integrate and update the kernel configuration.

  > Short explaination for all requested changes:
  >
  > CONFIG_NUMA (and all related config options):
  > s390 gained fake NUMA support with kernel version 4.3. Performance
  > measurements did show that this helps for very large machines (lot's of
  > memory), and also doesn't hurt for small machines.  Therfore the config
  > option should be enabled.
  >
  > CONFIG_PREEMPT_NONE:
  > We only have performance numbers for non-preemptible kernels. While kernel
  > preemption generally should work from a functional point of view on s390,
  > we do not have numbers about the performance costs. Nor do we have any
  > production systems running with kernel preemption enabled currently.
  > Therefore let's please switch to PREEMPT_NONE which has proven to work.
  >
  > CONFIG_SCSI_SCAN_ASYNC:
  > Hendrik already requested to disable this config option.
  >
  > CONFIG_REGMAP,
  > CONFIG_NET_VENDOR_EMULEX,
  > CONFIG_BE2NET,
  > CONFIG_BE2NET_VXLAN,
  > CONFIG_NET_VENDOR_SYNOPSYS,
  > CONFIG_NVMEM:
  > Looks like all of these crept in with the kernel update to 4.3. None of
  > these are relevant to s390 and can be disabled.

  An updated config patch to the kernel version above will be added

  
  ====
  Kernel-Description: s390x -- clear out hardware related configuration item

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