Precise: collapse gerneric and server into one flavour

[Leann Ogasawara]

On Thu, 2011-10-13 at 11:13 -0700, John Johansen wrote:
> 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.

Thanks for the additional feedback.  Hypothetically, if we did decide to
go the route of folding -server into -generic, it might be a good idea
to first transition the -server flavor over to be identical to what we'd
be proposing if we folded into -generic.  That way we could give the
Ubuntu Server Team an opportunity to test early in the Precise dev cycle
and see what sort of fallout, if any, occurs.  It'd be a much easier
revert if we had to and we wouldn't have to deal with the secondary
issue of update/upgrade issues until we're certain we want to make that
change.

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

Indeed and Andy actually put together this very thing late in the
Oneiric cycle.  We now have a linux-image-extra-virtual package which
contains all the extra modules from -server which currently aren't in
-virtual. 

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

If using the same preempt model proves to be acceptable for both the
desktop/server experience AND if server isn't going to diverge more than
it currently is, then I would agree that we should merge them.

Thanks,
Leann

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