Optimized kernel builds: the straight dope

[Matt Zimmerman]

On Mon, Aug 14, 2006 at 09:50:38PM -0500, Scott White wrote:
> Regardless this makes sense to me and I'm in favor of it.  Having run Ubuntu
> on several different architectures, Intel 686, Intel SMP + AMD64, I can't
> say I've seen any obvious difference.  My only question is that it doesn't
> seem that benchmarks were done in applications that wouldn't leverage many
> instructions opened up in recent architectures or applications (such as
> multimedia) or that are SMP driven such as MySql or high-end graphics work
> (even games).

The use of newer instruction sets by applications is irrelevant to this
test; you can still run i686 instructions regardless of which kernel you
use.  We are only measuring the impact of building the kernel differently,
not applications.  I would very much like to see similar data for that, of
course, but so far no one has taken up the challenge.

This test was also explicitly performed on uniprocessor systems.  There's a
very good reason for this, which is that what we currently call the -386
kernel can't support SMP because it contains some additional legacy drivers
which don't work with an SMP kernel.  It wouldn't be fair to compare these
kernels on a multiprocessor system.

So in addition, this test shows that there is no slowdown by using our
SMP-enabled kernel on uniprocessor systems, which is also great news.  This
means that in Edgy, we will support multiprocessor and dual-core desktop
systems out of the box, with no download and no performance penalty.  The
uniprocessor-only kernel with the legacy drivers will still be available on
the alternate CD.

So in a nutshell, we should be able to ship at most two variants of the
desktop i386 kernel, one omitting a few drivers (the default) and one for
uniprocessor only with all drivers (the alternate).  This is a big win both
for kernel maintenance and for end user simplicity; users will only seek out
the alternate kernel if they need it.

If we can resolve the SMP issues with those few drivers, then we can ship a
single optimal kernel for everyone, which will be even better still.  Ben is
collecting a list of the SMP-unfriendly drivers now.

-- 
 - mdz