[RFC] Precise: collapse gerneric and server into one flavour
Andy Whitcroft
apw at canonical.com
Tue Oct 18 11:51:26 UTC 2011
On Mon, Oct 17, 2011 at 01:41:02PM -0700, Leann Ogasawara wrote:
> On Fri, 2011-10-14 at 16:13 +0100, Tim Gardner wrote:
> > On 10/14/2011 03:28 PM, Andy Whitcroft wrote:
> > > On Thu, Oct 13, 2011 at 11:13:47AM -0700, John Johansen wrote:
> > >
> > >>> config PREEMPT_NONE
> > >>> bool "No Forced Preemption (Server)"
> > >>> help
> > >>> This is the traditional Linux preemption model, geared towards
> > >>> throughput. It will still provide good latencies most of the
> > >>> time, but there are no guarantees and occasional longer delays
> > >>> are possible.
> > >>>
> > >>> Select this option if you are building a kernel for a server or
> > >>> scientific/computation system, or if you want to maximize the
> > >>> raw processing power of the kernel, irrespective of scheduling
> > >>> latencies.
> > >>>
> > >>> config PREEMPT_VOLUNTARY
> > >>> bool "Voluntary Kernel Preemption (Desktop)"
> > >>> help
> > >>> This option reduces the latency of the kernel by adding more
> > >>> "explicit preemption points" to the kernel code. These new
> > >>> preemption points have been selected to reduce the maximum
> > >>> latency of rescheduling, providing faster application reactions,
> > >>> at the cost of slightly lower throughput.
> > >>>
> > >>> This allows reaction to interactive events by allowing a
> > >>> low priority process to voluntarily preempt itself even if it
> > >>> is in kernel mode executing a system call. This allows
> > >>> applications to run more 'smoothly' even when the system is
> > >>> under load.
> > >>>
> > >>> Select this if you are building a kernel for a desktop system.
> > >>>
> > >> This isn't necessarily bad for a server either. Its been a few years
> > >> since I really looked at the scheduler choices, so its worth looking into
> > >> again but voluntary preempt didn't have near as much overhead associated
> > >> with it as full preempt.
> > >
> > > Perhaps we could do some comparative testing with these two, we did some
> > > timings before for HZ IIRC. John was it you who did the HZ comparisons?
> > >
> > >>>> Please research the possibilities and let me know if I've overlooked any
> > >>>> reasons to _not_ do this. Note that there will be knock on effects in
> > >>>> meta packages, upgrade issues from 10.04 to 12.04, and upgrade issues
> > >>>> from 11.10 to 12.04.
> > >>>>
> > >>>> As an alternative we could drop the virtual flavour altogether and make
> > >>>> the appropriate changes to support virtual in the server flavour.
> > >>>
> > >>> We do keep getting requests to add support for drivers to the -virtual
> > >>> flavor which are already included in the -server flavor. So I could see
> > >>> us wanting to fold in the -virtual flavor to -server. One of the issues
> > >>> I do see here is with regards to size and what kinds of pushback we'd
> > >>> see because of it. Also, we support a -virtual i386 flavor which we'd
> > >>> have to fold into the -generic i386 flavor as there is no -server flavor
> > >>> for i386. My question here is are we able to support an arch-flavor
> > >>> specific update/upgrade path, ie virtual.amd64 -> server.amd64 but
> > >>> virtual.i386-> generic.i386?
> > >>>
> > >> Yeah size is the big concern. There are people trying to run some really
> > >> tiny VMs but at the same time we have the conflicting desire of people
> > >> always wanting more modules.
> > >>
> > >> In some way -virtual's requirements call out for split packaging, an
> > >> absolutely minimal kernel, and an extra modules package of some sort.
> > >
> > > We do now have the linux-image-extra-XXX-virtual package which holds the
> > > non-core modules. So I do think a split is helpful, and that is hard to
> > > achieve without a separate flavour for -virtual. As virtual is a
> > > separate flavour from -server obviouly that doesn't preclude commonising
> > > -generic and -server.
> > >
> > > -apw
> > >
> >
> > With the changes in scheduler we might be hard pressed to tell the
> > difference between preempt and voluntary. I think its worth a try to
> > commonize generic and server on amd64. Especially now that normal
> > developer workloads are isolated in their own cgroup.
>
> I'm proposing the following Precise 12.04 config changes so that we can
> eventually collapse the -generic and -server flavors into a single
> flavor should we decide to proceed with merging the two. These changes
> will result in identical -generic and -server flavors to allow for
> testing. Should testing prove satisfactory results for each, I'd
> propose we then merge the -generic and -server flavors in time for the
> Precise Alpha-2 release [1].
>
> I'd like to specifically point out two of the following changes which
> are being proposed:
>
> * Standardize on the CFQ I/O Scheduler. This means the -server
> flavor will transition from CONFIG_DEFAULT_IOSCHED="deadline" to
> CONFIG_DEFAULT_IOSCHED="cfq". Those wanting to stick with the
> Deadline I/O scheduler can do so at boot time by setting
> 'elevator=deadline'. A description of the CFQ I/O scheduler is
> as follows:
>
> config IOSCHED_CFQ
> tristate "CFQ I/O scheduler"
> # If BLK_CGROUP is a module, CFQ has to be built as module.
> depends on (BLK_CGROUP=m && m) || !BLK_CGROUP || BLK_CGROUP=y
> default y
> ---help---
> The CFQ I/O scheduler tries to distribute bandwidth equally
> among all processes in the system. It should provide a fair
> and low latency working environment, suitable for both desktop
> and server systems.
>
> This is the default I/O scheduler.
>
> Note: If BLK_CGROUP=m, then CFQ can be built only as module.
>
> * Standardize on the Voluntary Kernel Preemption model. This
> means the -server flavor will transition from
> CONFIG_PREEMPT_NONE to CONFIG_PREEMPT_VOLUNTARY. A description
> of the Voluntary Preemption model can seen above.
>
> Inlined below is the actual proposed config changes. I'd like to get
> some Ack's on this prior to applying and uploading.
>
> Thanks,
> Leann
>
> [1] https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
>
> From ff57db92a3865d938e2891cba1df4b0da9213cfd Mon Sep 17 00:00:00 2001
> From: Leann Ogasawara <leann.ogasawara at canonical.com>
> Date: Mon, 17 Oct 2011 13:09:53 -0700
> Subject: [PATCH] UBUNTU: [Config] Transition -generic and -server to be identical
>
> Given the minimal set of differences between the existing -generic and
> -server flavors, it's been proposed we consider merging the two. The
> following config changes align the -generic and -server configs to be
> identical. This is a transitional change to allow testing of the config
> changes but leave us with an easy fallback scenario (ie revert this
> commit) should testing prove unfavorable. Otherwise, we will proceed
> with merging the -generic and -server flavors into a single flavor.
>
> https://lists.ubuntu.com/archives/kernel-team/2011-October/017413.html
>
> Signed-off-by: Leann Ogasawara <leann.ogasawara at canonical.com>
> ---
> debian.master/config/amd64/config.common.amd64 | 7 +++++++
> debian.master/config/amd64/config.flavour.generic | 8 --------
> debian.master/config/amd64/config.flavour.server | 18 +++++-------------
> debian.master/config/amd64/config.flavour.virtual | 8 --------
> debian.master/config/config.common.ubuntu | 1 +
> debian.master/config/powerpc/config.common.powerpc | 1 -
> debian.master/config/ppc64/config.common.ppc64 | 1 -
> 7 files changed, 13 insertions(+), 31 deletions(-)
>
> diff --git a/debian.master/config/amd64/config.common.amd64 b/debian.master/config/amd64/config.common.amd64
> index ae6c2a8..83ae858 100644
> --- a/debian.master/config/amd64/config.common.amd64
> +++ b/debian.master/config/amd64/config.common.amd64
> @@ -203,6 +203,8 @@ CONFIG_SCSI_IPR=m
> # CONFIG_SCSI_MVSAS_TASKLET is not set
> CONFIG_SCSI_OSD_INITIATOR=m
> CONFIG_SCSI_QLA_ISCSI=m
> +CONFIG_SCSI_SPI_ATTRS=y
> +CONFIG_SCSI_SYM53C8XX_2=y
> CONFIG_SENSORS_AK8975=m
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_PCI=y
> @@ -321,6 +323,11 @@ CONFIG_VIDEO_TVAUDIO=m
> # CONFIG_VIDEO_TVP514X is not set
> CONFIG_VIDEO_TVP5150=m
> CONFIG_VIDEO_VPX3220=m
> +CONFIG_VIRTIO=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_VIRTIO_NET=y
> +CONFIG_VIRTIO_PCI=y
> +CONFIG_VIRTIO_RING=y
Why are these builtin on any flavour again? I thought these were only
needed on -virtual?
> CONFIG_VITESSE_PHY=y
> CONFIG_VME_BUS=m
> CONFIG_VME_CA91CX42=m
> diff --git a/debian.master/config/amd64/config.flavour.generic b/debian.master/config/amd64/config.flavour.generic
> index a3d1808..7480548 100644
> --- a/debian.master/config/amd64/config.flavour.generic
> +++ b/debian.master/config/amd64/config.flavour.generic
> @@ -5,17 +5,9 @@ CONFIG_DEFAULT_CFQ=y
> # CONFIG_DEFAULT_DEADLINE is not set
> CONFIG_DEFAULT_IOSCHED="cfq"
> CONFIG_INTEL_IDLE=y
> -# CONFIG_MEMORY_HOTPLUG is not set
> CONFIG_NR_CPUS=256
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> -CONFIG_SCSI_SPI_ATTRS=m
> -CONFIG_SCSI_SYM53C8XX_2=m
> -CONFIG_VIRTIO=m
> -CONFIG_VIRTIO_BLK=m
> -CONFIG_VIRTIO_NET=m
> -CONFIG_VIRTIO_PCI=m
> -CONFIG_VIRTIO_RING=m
> CONFIG_XEN_BLKDEV_FRONTEND=m
> CONFIG_XEN_NETDEV_FRONTEND=m
> CONFIG_XEN_XENBUS_FRONTEND=m
> diff --git a/debian.master/config/amd64/config.flavour.server b/debian.master/config/amd64/config.flavour.server
> index fa42131..25f0760 100644
> --- a/debian.master/config/amd64/config.flavour.server
> +++ b/debian.master/config/amd64/config.flavour.server
> @@ -1,21 +1,13 @@
> #
> # Config options for config.flavour.server automatically generated by splitconfig.pl
> #
> -# CONFIG_DEFAULT_CFQ is not set
> -CONFIG_DEFAULT_DEADLINE=y
> -CONFIG_DEFAULT_IOSCHED="deadline"
> +CONFIG_DEFAULT_CFQ=y
> +# CONFIG_DEFAULT_DEADLINE is not set
> +CONFIG_DEFAULT_IOSCHED="cfq"
> CONFIG_INTEL_IDLE=y
> -CONFIG_MEMORY_HOTPLUG=y
> CONFIG_NR_CPUS=256
> -CONFIG_PREEMPT_NONE=y
> -# CONFIG_PREEMPT_VOLUNTARY is not set
> -CONFIG_SCSI_SPI_ATTRS=y
> -CONFIG_SCSI_SYM53C8XX_2=y
> -CONFIG_VIRTIO=y
> -CONFIG_VIRTIO_BLK=y
> -CONFIG_VIRTIO_NET=y
> -CONFIG_VIRTIO_PCI=y
> -CONFIG_VIRTIO_RING=y
> +# CONFIG_PREEMPT_NONE is not set
> +CONFIG_PREEMPT_VOLUNTARY=y
> CONFIG_XEN_BLKDEV_FRONTEND=m
> CONFIG_XEN_NETDEV_FRONTEND=m
> CONFIG_XEN_XENBUS_FRONTEND=m
> diff --git a/debian.master/config/amd64/config.flavour.virtual b/debian.master/config/amd64/config.flavour.virtual
> index ed3931c..7d69a12 100644
> --- a/debian.master/config/amd64/config.flavour.virtual
> +++ b/debian.master/config/amd64/config.flavour.virtual
> @@ -5,17 +5,9 @@
> CONFIG_DEFAULT_DEADLINE=y
> CONFIG_DEFAULT_IOSCHED="deadline"
> # CONFIG_INTEL_IDLE is not set
> -CONFIG_MEMORY_HOTPLUG=y
> CONFIG_NR_CPUS=64
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> -CONFIG_SCSI_SPI_ATTRS=y
> -CONFIG_SCSI_SYM53C8XX_2=y
> -CONFIG_VIRTIO=y
> -CONFIG_VIRTIO_BLK=y
> -CONFIG_VIRTIO_NET=y
> -CONFIG_VIRTIO_PCI=y
> -CONFIG_VIRTIO_RING=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
> index f77c767..66cebe4 100644
> --- a/debian.master/config/config.common.ubuntu
> +++ b/debian.master/config/config.common.ubuntu
> @@ -2955,6 +2955,7 @@ CONFIG_MEGARAID_NEWGEN=y
> CONFIG_MEGARAID_SAS=m
> # CONFIG_MELAN is not set
> CONFIG_MEMORY_FAILURE=y
> +CONFIG_MEMORY_HOTPLUG
> CONFIG_MEMORY_HOTPLUG_SPARSE=y
> CONFIG_MEMSTICK=m
> # CONFIG_MEMSTICK_DEBUG is not set
> diff --git a/debian.master/config/powerpc/config.common.powerpc b/debian.master/config/powerpc/config.common.powerpc
> index 31e823c..c6fefd3 100644
> --- a/debian.master/config/powerpc/config.common.powerpc
> +++ b/debian.master/config/powerpc/config.common.powerpc
> @@ -117,7 +117,6 @@ CONFIG_MACH_NO_WESTBRIDGE=y
> CONFIG_MANTIS_CORE=m
> CONFIG_MARVELL_PHY=m
> CONFIG_MAX_RAW_DEVS=256
> -CONFIG_MEMORY_HOTPLUG=y
> # CONFIG_MEMORY_HOTREMOVE is not set
> CONFIG_MFD_JANZ_CMODIO=m
> # CONFIG_MFD_TMIO is not set
> diff --git a/debian.master/config/ppc64/config.common.ppc64 b/debian.master/config/ppc64/config.common.ppc64
> index c9f6401..fd932f9 100644
> --- a/debian.master/config/ppc64/config.common.ppc64
> +++ b/debian.master/config/ppc64/config.common.ppc64
> @@ -132,7 +132,6 @@ CONFIG_MANTIS_CORE=m
> CONFIG_MARVELL_PHY=m
> CONFIG_MAX_ACTIVE_REGIONS=256
> CONFIG_MAX_RAW_DEVS=8192
> -CONFIG_MEMORY_HOTPLUG=y
> CONFIG_MEMORY_HOTREMOVE=y
> CONFIG_MFD_JANZ_CMODIO=m
> # CONFIG_MFD_TMIO is not set
Otherwise it looks sane enough to me.
Acked-by: Andy Whitcroft <apw at canonical.com>
I wouldn't let this either way hold up the first upload to precise
however, if the compilers etc are in shove in what we have.
-apw
More information about the kernel-team
mailing list