Message ID | 1318884062.2155.228.camel@adamo |
---|---|
State | New |
Headers | show |
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
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