[RFC] Precise: collapse gerneric and server into one flavour
Stefan Bader
stefan.bader at canonical.com
Tue Oct 18 12:45:33 UTC 2011
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 at canonical.com>
>> Date: Mon, 17 Oct 2011 13:09:53 -0700
>> Subject: [PATCH] UBUNTU: [Config] Transition -generic and -server to be identical
>>
>> Given the minimal set of differences between the existing -generic and
>> -server flavors, it's been proposed we consider merging the two. The
>> following config changes align the -generic and -server configs to be
>> identical. This is a transitional change to allow testing of the config
>> changes but leave us with an easy fallback scenario (ie revert this
>> commit) should testing prove unfavorable. Otherwise, we will proceed
>> with merging the -generic and -server flavors into a single flavor.
>>
>> https://lists.ubuntu.com/archives/kernel-team/2011-October/017413.html
>>
>> Signed-off-by: Leann Ogasawara <leann.ogasawara at canonical.com>
>> ---
>> debian.master/config/amd64/config.common.amd64 | 7 +++++++
>> debian.master/config/amd64/config.flavour.generic | 8 --------
>> debian.master/config/amd64/config.flavour.server | 18 +++++-------------
>> debian.master/config/amd64/config.flavour.virtual | 8 --------
>> debian.master/config/config.common.ubuntu | 1 +
>> debian.master/config/powerpc/config.common.powerpc | 1 -
>> debian.master/config/ppc64/config.common.ppc64 | 1 -
>> 7 files changed, 13 insertions(+), 31 deletions(-)
>>
>> diff --git a/debian.master/config/amd64/config.common.amd64 b/debian.master/config/amd64/config.common.amd64
>> index ae6c2a8..83ae858 100644
>> --- a/debian.master/config/amd64/config.common.amd64
>> +++ b/debian.master/config/amd64/config.common.amd64
>> @@ -203,6 +203,8 @@ CONFIG_SCSI_IPR=m
>> # CONFIG_SCSI_MVSAS_TASKLET is not set
>> CONFIG_SCSI_OSD_INITIATOR=m
>> CONFIG_SCSI_QLA_ISCSI=m
>> +CONFIG_SCSI_SPI_ATTRS=y
>> +CONFIG_SCSI_SYM53C8XX_2=y
>> CONFIG_SENSORS_AK8975=m
>> CONFIG_SERIAL_8250=y
>> CONFIG_SERIAL_8250_PCI=y
>> @@ -321,6 +323,11 @@ CONFIG_VIDEO_TVAUDIO=m
>> # CONFIG_VIDEO_TVP514X is not set
>> CONFIG_VIDEO_TVP5150=m
>> CONFIG_VIDEO_VPX3220=m
>> +CONFIG_VIRTIO=y
>> +CONFIG_VIRTIO_BLK=y
>> +CONFIG_VIRTIO_NET=y
>> +CONFIG_VIRTIO_PCI=y
>> +CONFIG_VIRTIO_RING=y
>
> Why are these builtin on any flavour again? I thought these were only
> needed on -virtual?
>
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 at canonical.com>
>
> I wouldn't let this either way hold up the first upload to precise
> however, if the compilers etc are in shove in what we have.
>
> -apw
>
More information about the kernel-team
mailing list