Precise: collapse gerneric and server into one flavour

[Andy Whitcroft]

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