Precise: collapse gerneric and server into one flavour

[John Johansen]

On 10/13/2011 08:48 AM, Leann Ogasawara wrote:
> On Wed, 2011-10-12 at 12:04 +0100, Tim Gardner wrote:
>> Leann - Given the few differences between amd64 server and generic 
>> flavours, I think its time to consider collapsing these 2 flavours into 
>> one. There are some server config options that could be set in generic 
>> without issue, and the I/O scheduler can be changed at runtime.
> 
> Aside from the scheduler changes, the other concern I would have is with
> regards to the preemption model differences between the two.  The
> -generic flavor selects CONFIG_PREEMPT_VOLUNTARY=y whereas the -server
> flavor selects CONFIG_PREEMPT_NONE=y.  The description of these are as
> follows:
> 
> 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.

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

At one point we wanted the virtual kernel to have certain devices builtin
so we could boot without an initrd but that isn't really an issue anymore
now that we use pv-grub on ec2.

>> At any rate, I think its time to investigate collapsing at least one of 
>> these flavours. I eagerly await your analysis prior to the first Precise 
>> kernel upload.
> 
> If we are able to support the proper update/upgrade path for i386 and
> amd64 virtual flavors and the size issue is not a big concern, I'd be
> more in favor of folding -virtual into amd64.server/i386.generic.
> 
If we could resolve the size issue folding -virtual into -server makes sense.
Folding -server back into -generic I think it might be nice to keep the split
as I can see the potential for them to diverge more than they are atm.  But
I will throw in the caveat that if they don't diverge more you should
seriously consider merging them.

> Stefan, since you are our server domain expert, do you have any strong
> opinion regarding the above?
> 
> Thanks,
> Leann
> 
>