Precise: collapse gerneric and server into one flavour

[Leann Ogasawara]

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.

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

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

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

Thanks,
Leann