[RFC] Precise: collapse gerneric and server into one flavour

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@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@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(-)

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@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@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@canonical.com>

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

On 18.10.2011 13:51, Andy Whitcroft wrote:
> 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@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@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?
> 
Since you can actually install any flavour in a vm it makes sense to have them
built-in. There have been some efforts under Xen to have the virtnet and
virtdisk driver be connected on a virtual xen bus. Though it did not seem to
work as expected, yet. But I think the kvm paravirt drivers have no such bus, so
they won't autoprobe. And it does not hurt to have them around. In fact I am
planning to propose to have the xen paravirt drivers built-in as well. At least
if it turns out to be as painful to get them present for a HVM install as in
Oneiric.

-Stefan

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

On Tue, 2011-10-18 at 12:51 +0100, Andy Whitcroft wrote:
> 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:
[...]
> > 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?

They were built in for -server and enabled as modules for -generic.
Since we're making config changes to the flavors, I'll enable these as
modules for now, we can discuss completely disabling during our UDS
config review.

[...]
> 
> Otherwise it looks sane enough to me.
> 
> Acked-by: Andy Whitcroft <apw@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.

I'll make the small config tweaks noted above, rebase to v3.1-rc10 and
then upload.

Thanks,
Leann

On Tue, 2011-10-18 at 08:19 -0700, Leann Ogasawara wrote:
> On Tue, 2011-10-18 at 12:51 +0100, Andy Whitcroft wrote:
> > 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:
> [...]
> > > 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?
> 
> They were built in for -server and enabled as modules for -generic.
> Since we're making config changes to the flavors, I'll enable these as
> modules for now, we can discuss completely disabling during our UDS
> config review.

Bah, I missed Stefan's response prior to writing the above.  Please
disregard and I'll just leave them built-in for now.  We can still table
further discussion for UDS.

> 
> [...]
> > 
> > Otherwise it looks sane enough to me.
> > 
> > Acked-by: Andy Whitcroft <apw@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.
> 
> I'll make the small config tweaks noted above, rebase to v3.1-rc10 and
> then upload.

Ok, so now I'm just rebasing to v3.1-rc10 and uploading.

Thanks,
Leann