ACK: [RFC] Precise: collapse gerneric and server into one flavour
Stefan Bader
stefan.bader at canonical.com
Tue Oct 18 07:23:01 UTC 2011
On 17.10.2011 22:41, 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
> 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=y
> 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
Sounds like a workable step forward to me.
Acked-by: Stefan Bader <stefan.bader at canonical.com>
More information about the kernel-team
mailing list