kernel: update kernel configuration

Default Comment by Bridge

The following config changes will be fixed soon:
CONFIG_NUMA
CONFIG_REGMAP
CONFIG_NET_VENDOR_EMULEX
CONFIG_BE2NET
CONFIG_BE2NET_VXLAN
CONFIG_NET_VENDOR_SYNOPSYS
CONFIG_NVMEM

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

We ship PREEMPT_VOLUNTARY & CONFIG_SCSI_SCAN_ASYNC on all architectures (including ppc64, ppc64el, and s390x) and this is what we support and have shipped at least since lucid (6 years +). If you really want to escalate changes to these two config keys from what Ubuntu users expect on Ubuntu, please provide details of fundamental s390x architecture specific difference that result in worse generic performance when configured like we currently have; or for example why that's the wrong thing to do across all architectures. To me, both of those config keys are more-or-less architecture-agnostic and in general improve performance without significant performance impacts. BTW, IBM z/KVM appears to ship with CONFIG_SCSI_SCAN_ASYNC=y too.

Why are we diverging from other architectures ? There is nothing in this bug that describes any deleterious effects caused by these config settings.

------- Comment From <email address hidden> 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).

------- Comment From <email address hidden> 2016-03-08 03:20 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

And for disabling preemption:

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.

This bug was fixed in the package linux - 4.4.0-12.28

---------------
linux (4.4.0-12.28) xenial; urgency=low

  * Miscellaneous Ubuntu changes
    - reconstruct: Work around orig tarball packaging limitiations
      Fixes FTBS

 -- Tim Gardner <email address hidden> Tue, 08 Mar 2016 13:26:08 -0700

------- Comment From <email address hidden> 2016-03-15 06:38 EDT-------
(In reply to comment #9)
> This bug was fixed in the package linux - 4.4.0-12.28
>
> ---------------
> linux (4.4.0-12.28) xenial; urgency=low
>
> * Miscellaneous Ubuntu changes
> - reconstruct: Work around orig tarball packaging limitiations
> Fixes FTBS
>
> -- Tim Gardner <email address hidden> Tue, 08 Mar 2016 13:26:08 -0700

This release corrects the preemption kernel configuration only. The other requested kernel configuration settings have not been updated as suggested. I have opened further bugzillas/LPs to track these kernel configuration options.

Thanks.

For clarity it did also enable NUMA, though there are further corrections to be made there. It also disabled a number of redundant hardware options as requested. It did not change the ASYNC option which I will discuss in the newly opened bug.