Precise: collapse gerneric and server into one flavour
leann.ogasawara at canonical.com
Thu Oct 13 18:43:22 UTC 2011
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
> >> 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
> 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.
> > Stefan, since you are our server domain expert, do you have any strong
> > opinion regarding the above?
> > Thanks,
> > Leann
More information about the kernel-team